On 09.04.2010, at 11:28, nicolas geoffray wrote:> VMKit runs multiple threads (for example for GC, finalization, etc), > so I need the back trace of other threads as well :)Here it comes: Thread 4 (process 14442 thread 0x2003): #0 0x950be44e in __semwait_signal () #1 0x950e93e6 in _pthread_cond_wait () #2 0x950e8dcd in pthread_cond_wait$UNIX2003 () #3 0x000be2d2 in mvm::Cond::wait (this=0x20526a4, l=0x2052670) at ctlock.cpp:151 #4 0x00092275 in mvm::VirtualMachine::enqueueStart (th=0x20200000) at Object.cpp:109 #5 0x000bea10 in mvm::Thread::internalThreadStart (th=0x20200000) at ctthread.cpp:275 #6 0x950e8155 in _pthread_start () #7 0x950e8012 in thread_start () Thread 3 (process 14442 thread 0x1703): #0 0x950be44e in __semwait_signal () #1 0x950e93e6 in _pthread_cond_wait () #2 0x950e8dcd in pthread_cond_wait$UNIX2003 () #3 0x000be2d2 in mvm::Cond::wait (this=0x2052614, l=0x2052630) at ctlock.cpp:151 #4 0x00092154 in mvm::VirtualMachine::finalizerStart (th=0x20100000) at Object.cpp:73 #5 0x000bea10 in mvm::Thread::internalThreadStart (th=0x20100000) at ctthread.cpp:275 #6 0x950e8155 in _pthread_start () #7 0x950e8012 in thread_start () Thread 2 (process 14442 thread 0x313): #0 0x95193136 in __semwait_signal_nocancel () #1 0x95192d1b in nanosleep$NOCANCEL$UNIX2003 () #2 0x9518c013 in usleep$NOCANCEL$UNIX2003 () #3 0x951a3685 in abort () #4 0x955eb005 in __gnu_cxx::__verbose_terminate_handler () #5 0x955e910c in __gxx_personality_v0 () #6 0x955e914b in std::terminate () #7 0x955e9261 in __cxa_throw () #8 0x000130ae in j3::JavaThread::throwException (this=0x20000000, obj=0x1bcfc00) at JavaThread.cpp:73 #9 0x0002352b in j3::Class::initialiseClass (this=0x20e5c60, vm=0x20525a8) at Jnjvm.cpp:249 #10 0x000242e5 in j3::Jnjvm::loadBootstrap (this=0x20525a8) at Jnjvm.cpp:1134 #11 0x000243f1 in j3::Jnjvm::mainJavaStart (thread=0x20000000) at Jnjvm.cpp:1246 #12 0x000bea10 in mvm::Thread::internalThreadStart (th=0x20000000) at ctthread.cpp:275 #13 0x950e8155 in _pthread_start () #14 0x950e8012 in thread_start () Thread 1 (process 14442 local thread 0x2e03): #0 0x950be44e in __semwait_signal () #1 0x950e93e6 in _pthread_cond_wait () #2 0x950e8dcd in pthread_cond_wait$UNIX2003 () #3 0x000be2d2 in mvm::Cond::wait (this=0x20527c4, l=0x2052790) at ctlock.cpp:151 #4 0x00020137 in j3::Jnjvm::waitForExit (this=0x20525a8) at Jnjvm.cpp: 1225 #5 0x00001cf6 in main (argc=4, argv=0xbffff070, envp=0xbffff084) at Main.cpp:47 In the meantime I installed VMKit under Linux, where it works perfectly well for most applications I tried. However, I managed to crash it once: > j3 -cp clojure-1.1.0.jar clojure.main Stack overflow in VM code or in JNI code. If it is from the VM, it is either from the JIT, the GC or the runtime. This has to be fixed in the VM: VMKit makes sure that the bottom of the stack is always available when entering the VM. Segmentation fault There is no JNI code involved, so the stack overflow happens in the VM. Is this a bug in VMKit or just an indication that I need to change some parameter settings (memory size, ...)? If you want to check this yourself, the jar file is available at http://clojure.googlecode.com/files/clojure-1.1.0.zip Thanks, Konrad.
Hi Konrad, I have added some diagnostic message when failing that early in the bootstrap in the VM. Please svn up and let me know what it prints. About the SIGSEGV you get with clojure.jar, I ran the code and got the same error. After investigation, it turns out that the methods you have in that .jar are quite big (50,000 bytecodes) and the static initializer of the core__init class just crashes LLVM because the stack of the thread is not big enough. I hate Java bytecode generators :) Nicolas On Fri, Apr 9, 2010 at 9:26 PM, Konrad Hinsen <konrad.hinsen at fastmail.net>wrote:> On 09.04.2010, at 11:28, nicolas geoffray wrote: > > VMKit runs multiple threads (for example for GC, finalization, etc), so I >> need the back trace of other threads as well :) >> > > Here it comes: > > Thread 4 (process 14442 thread 0x2003): > > #0 0x950be44e in __semwait_signal () > #1 0x950e93e6 in _pthread_cond_wait () > #2 0x950e8dcd in pthread_cond_wait$UNIX2003 () > #3 0x000be2d2 in mvm::Cond::wait (this=0x20526a4, l=0x2052670) at > ctlock.cpp:151 > #4 0x00092275 in mvm::VirtualMachine::enqueueStart (th=0x20200000) at > Object.cpp:109 > #5 0x000bea10 in mvm::Thread::internalThreadStart (th=0x20200000) at > ctthread.cpp:275 > #6 0x950e8155 in _pthread_start () > #7 0x950e8012 in thread_start () > > Thread 3 (process 14442 thread 0x1703): > > #0 0x950be44e in __semwait_signal () > #1 0x950e93e6 in _pthread_cond_wait () > #2 0x950e8dcd in pthread_cond_wait$UNIX2003 () > #3 0x000be2d2 in mvm::Cond::wait (this=0x2052614, l=0x2052630) at > ctlock.cpp:151 > #4 0x00092154 in mvm::VirtualMachine::finalizerStart (th=0x20100000) at > Object.cpp:73 > #5 0x000bea10 in mvm::Thread::internalThreadStart (th=0x20100000) at > ctthread.cpp:275 > #6 0x950e8155 in _pthread_start () > #7 0x950e8012 in thread_start () > > Thread 2 (process 14442 thread 0x313): > #0 0x95193136 in __semwait_signal_nocancel () > #1 0x95192d1b in nanosleep$NOCANCEL$UNIX2003 () > #2 0x9518c013 in usleep$NOCANCEL$UNIX2003 () > #3 0x951a3685 in abort () > #4 0x955eb005 in __gnu_cxx::__verbose_terminate_handler () > #5 0x955e910c in __gxx_personality_v0 () > #6 0x955e914b in std::terminate () > #7 0x955e9261 in __cxa_throw () > #8 0x000130ae in j3::JavaThread::throwException (this=0x20000000, > obj=0x1bcfc00) at JavaThread.cpp:73 > #9 0x0002352b in j3::Class::initialiseClass (this=0x20e5c60, vm=0x20525a8) > at Jnjvm.cpp:249 > #10 0x000242e5 in j3::Jnjvm::loadBootstrap (this=0x20525a8) at > Jnjvm.cpp:1134 > #11 0x000243f1 in j3::Jnjvm::mainJavaStart (thread=0x20000000) at > Jnjvm.cpp:1246 > #12 0x000bea10 in mvm::Thread::internalThreadStart (th=0x20000000) at > ctthread.cpp:275 > #13 0x950e8155 in _pthread_start () > #14 0x950e8012 in thread_start () > > Thread 1 (process 14442 local thread 0x2e03): > > #0 0x950be44e in __semwait_signal () > #1 0x950e93e6 in _pthread_cond_wait () > #2 0x950e8dcd in pthread_cond_wait$UNIX2003 () > #3 0x000be2d2 in mvm::Cond::wait (this=0x20527c4, l=0x2052790) at > ctlock.cpp:151 > #4 0x00020137 in j3::Jnjvm::waitForExit (this=0x20525a8) at Jnjvm.cpp:1225 > #5 0x00001cf6 in main (argc=4, argv=0xbffff070, envp=0xbffff084) at > Main.cpp:47 > > > > In the meantime I installed VMKit under Linux, where it works perfectly > well for most applications I tried. However, I managed to crash it once: > > > j3 -cp clojure-1.1.0.jar clojure.main > Stack overflow in VM code or in JNI code. If it is from > the VM, it is either from the JIT, the GC or the runtime. > This has to be fixed in the VM: VMKit makes sure that > the bottom of the stack is always available when entering > the VM. > Segmentation fault > > There is no JNI code involved, so the stack overflow happens in the VM. Is > this a bug in VMKit or just an indication that I need to change some > parameter settings (memory size, ...)? > > If you want to check this yourself, the jar file is available at > > http://clojure.googlecode.com/files/clojure-1.1.0.zip > > Thanks, > Konrad. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100410/e43df8ee/attachment.html>
On Sat, Apr 10, 2010 at 1:42 PM, nicolas geoffray <nicolas.geoffray at gmail.com> wrote:> I hate Java bytecode generators :)Does that include the bytecode generator known as javac? ;) Reid
Hi Nicolas,> I have added some diagnostic message when failing that early in the > bootstrap in the VM. Please svn up and let me know what it prints.It prints: Exception java/lang/UnsatisfiedLinkError while bootstraping VM That looks like a JNI issue.> About the SIGSEGV you get with clojure.jar, I ran the code and got > the same error. After investigation, it turns out that the methods > you have in that .jar are quite big (50,000 bytecodes) and the > static initializer of the core__init class just crashes LLVM because > the stack of the thread is not big enough.That's indeed a big one. It's the initialization of the standard library of a Lisp implementation.> I hate Java bytecode generators :)I like them. They let me use all those nice Java libraries without having to program in Java :-) Konrad.