llvm dev - Apr 2010 - [LLVMdev] VMKit assertion failure

On 7 Apr 2010, at 21:36, nicolas geoffray wrote:
> Hmm, I am not getting that error message on my MacOS 10.5 machine  
> with that same gcc. Could you run j3 in gdb and get me a backtrace?
Sure:

(gdb) bt
#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

I'll try installing VMKit in a virtual Linux for comparison.

Konrad.

VMKit runs multiple threads (for example for GC, finalization, etc), so I
need the back trace of other threads as well :)

Thanks!
Nicolas

On Fri, Apr 9, 2010 at 9:28 AM, Konrad Hinsen <konrad.hinsen at
fastmail.net>wrote:
> On 7 Apr 2010, at 21:36, nicolas geoffray wrote:
>
>  Hmm, I am not getting that error message on my MacOS 10.5 machine with
>> that same gcc. Could you run j3 in gdb and get me a backtrace?
>>
>
> Sure:
>
> (gdb) bt
> #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
>
> I'll try installing VMKit in a virtual Linux for comparison.
>
> Konrad.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100409/52722bad/attachment.html>

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.