That's great news! Thanks Allan for sharing the fix. About this ClassNotFoundException, try to debug vmkit and see how the classpath is being parsed.<div><br></div><div>Cheers,</div><div>Nicolas<br><br><div class="gmail_quote">
On Mon, Jul 19, 2010 at 6:15 AM, Will Dietz <span dir="ltr"><<a href="mailto:willdtz@gmail.com">willdtz@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Recompiling classpath with framepointers as you suggested fixed my<br>
64bit j3 nicely!<br>
<br>
Just wanted to thank you for sharing this :)<br>
<font color="#888888"><br>
~Will<br>
</font><div><div></div><div class="h5"><br>
On Sun, Jul 18, 2010 at 8:19 PM, Allan Tong <<a href="mailto:actong88@gmail.com">actong88@gmail.com</a>> wrote:<br>
> On Fri, Jul 16, 2010 at 10:44 AM, Minas Abrahamyan <<a href="mailto:minas.subs@gmail.com">minas.subs@gmail.com</a>> wrote:<br>
>> Crush occurs within j3::Jnjvm::loadBootstrap():<br>
>> when running Class::initialiseClass() of last macro<br>
>> LOAD_CLASS(upcalls->SystemClass)<br>
>> but before initializing vm->appClassLoader; which would be done just<br>
>> by the next call to loadAppClassLoader()<br>
>> in Jnjvm.cpp.<br>
>><br>
>> <<<<br>
>> native compile java/lang/VMRuntime.nativeLoad()<br>
>> --> end of native compile java/lang/VMRuntime.nativeLoad()<br>
>> [Switching to Thread 0x1200ff700 (LWP 11395)]<br>
>><br>
>> Breakpoint 1, Java_java_lang_VMRuntime_nativeLoad (str=0x7ffff020b750,<br>
>> javaLoader=0x0)<br>
>>    at ClasspathVMRuntime.inc:113<br>
>>>>><br>
>> ...many debugging results skipped...<br>
>><br>
>> Fruitful was comparison with 32-bit version - as it's working.<br>
>><br>
>> And I've found that Problem is FindClass does not load class<br>
>> "gnu/classpath/Pointer64" and returns 0,<br>
>> while the 32-bit counterpart does find and load corresponding<br>
>> "gnu/classpath/Pointer32";<br>
>><br>
>> This is result of<br>
>> UserClass* currentClass = th->getCallingClassLevel(0);<br>
>> in FindClass returns 0;<br>
>> <= JavaThread::getCallingClassLevel - returns 0, since all<br>
>> 'MethodInfo's in stack have value of MethodType==-1<br>
>><br>
>> While 32-bit version finds right value from stack, right value here is<br>
>> 'MethodInfo's with MethodType==1<br>
>> //why not enums?<br>
>><br>
>> So much for now. Something wrongly initializes type values of methods<br>
><br>
> Hi,<br>
><br>
> I was having the same problem here.  It turns out that the 64-bit<br>
> build of Classpath was omitting frame pointers.  Once I recompiled<br>
> Classpath with -fno-omit-frame-pointer, the StackWalker was able to<br>
> get past the offending stack frame and find the calling Java method.<br>
> This resolves the segfault, though now I get a ClassNotFoundException<br>
> trying to find my main class, which I haven't looked into yet.<br>
><br>
>  - Allan<br>
><br>
> _______________________________________________<br>
> vmkit-commits mailing list<br>
> <a href="mailto:vmkit-commits@cs.uiuc.edu">vmkit-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/vmkit-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/vmkit-commits</a><br>
><br>
<br>
_______________________________________________<br>
vmkit-commits mailing list<br>
<a href="mailto:vmkit-commits@cs.uiuc.edu">vmkit-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/vmkit-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/vmkit-commits</a><br>
</div></div></blockquote></div><br></div>