BTW, generating a jstack gives :
20145: Unable to open socket file: target process not responding or HotSpot VM not loaded
The -F option can be used when the target process is not responding
Using the -F option generates a lot of those exceptions :
sun.jvm.hotspot.debugger.UnalignedAddressException: Trying to read at address: 0x0074004300510051 with alignment: 4
at sun.jvm.hotspot.debugger.DebuggerUtilities.checkAlignment(DebuggerUtilities.java:57)
at sun.jvm.hotspot.debugger.macosx.MacOSXDebuggerLocal.readCInteger(MacOSXDebuggerLocal.java:399)
at sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:454)
at sun.jvm.hotspot.debugger.macosx.MacOSXDebuggerLocal.readOopHandle(MacOSXDebuggerLocal.java:271)
at sun.jvm.hotspot.debugger.macosx.MacOSXAddress.getOopHandleAt(MacOSXAddress.java:100)
at sun.jvm.hotspot.oops.Oop.getKlassForOopHandle(Oop.java:237)
at sun.jvm.hotspot.oops.ObjectHeap.newOop(ObjectHeap.java:378)
at sun.jvm.hotspot.runtime.JavaThread.getThreadObj(JavaThread.java:329)
at sun.jvm.hotspot.runtime.JavaThread.getCurrentParkBlocker(JavaThread.java:377)
at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:82)
at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39)
at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:52)
at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45)
at sun.jvm.hotspot.tools.JStack.run(JStack.java:60)
at sun.jvm.hotspot.tools.Tool.start(Tool.java:221)
at sun.jvm.hotspot.tools.JStack.main(JStack.java:88)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at sun.tools.jstack.JStack.runJStackTool(JStack.java:118)
at sun.tools.jstack.JStack.main(JStack.java:84)
Can't print deadlocks:Trying to read at address: 0x0074004300510051 with alignment: 4
Thread ..9943: (state = BLOCKED)
- java.lang.Object.wait(long)..ci=0 (Interpreted frame)
- org.eclipse.core.internal.jobs.WorkerPool.sleep(long)..ci=52, line=185 (Interpreted frame)
- org.eclipse.core.internal.jobs.WorkerPool.startJob(org.eclipse.core.internal.jobs.Worker)..ci=77, line=217 (Interpreted frame)
- org.eclipse.core.internal.jobs.Worker.run()..ci=326, line=50 (Interpreted frame)
> We are finally moving from WOLips 3.3 to 3.6 (yay!). So we installed Eclipse and WOLips with Golipse, and everything's fine, except one thing. Our core framework have 12 models with 196 entities total. If "Automatically run EOGenerator" is set to true, the core frameworks starts building but after 5 minutes, we are getting heap space errors, even if we give 1 GB of RAM to Eclipse. If we uncheck "Automatically run EOGenerator" and call manually EOGenerator on each .eogen files, we don't have the problem. If we build/clean another framework that have only one model, EOGenerator in automatic mode works fine too.
>
> So, does anyone have this problem with frameworks with more than one model?
>
> --
> Pascal Robert
> prober..acti.ca
>
> AIM/iChat : MacTICanada
> LinkedIn : http://www.linkedin.com/in/macti
> Twitter : pascal_robert
>
This archive was generated by hypermail 2.0.0 : Mon Nov 01 2010 - 17:43:42 UTC