[vmkit-commits] About j3-64bit crush

[Allan Tong]

On Fri, Jul 16, 2010 at 10:44 AM, Minas Abrahamyan <minas.subs at gmail.com> wrote:
> Crush occurs within j3::Jnjvm::loadBootstrap():
> when running Class::initialiseClass() of last macro
> LOAD_CLASS(upcalls->SystemClass)
> but before initializing vm->appClassLoader; which would be done just
> by the next call to loadAppClassLoader()
> in Jnjvm.cpp.
>
> <<<
> native compile java/lang/VMRuntime.nativeLoad()
> --> end of native compile java/lang/VMRuntime.nativeLoad()
> [Switching to Thread 0x1200ff700 (LWP 11395)]
>
> Breakpoint 1, Java_java_lang_VMRuntime_nativeLoad (str=0x7ffff020b750,
> javaLoader=0x0)
>    at ClasspathVMRuntime.inc:113
>>>>
> ...many debugging results skipped...
>
> Fruitful was comparison with 32-bit version - as it's working.
>
> And I've found that Problem is FindClass does not load class
> "gnu/classpath/Pointer64" and returns 0,
> while the 32-bit counterpart does find and load corresponding
> "gnu/classpath/Pointer32";
>
> This is result of
> UserClass* currentClass = th->getCallingClassLevel(0);
> in FindClass returns 0;
> <= JavaThread::getCallingClassLevel - returns 0, since all
> 'MethodInfo's in stack have value of MethodType==-1
>
> While 32-bit version finds right value from stack, right value here is
> 'MethodInfo's with MethodType==1
> //why not enums?
>
> So much for now. Something wrongly initializes type values of methods

Hi,

I was having the same problem here.  It turns out that the 64-bit
build of Classpath was omitting frame pointers.  Once I recompiled
Classpath with -fno-omit-frame-pointer, the StackWalker was able to
get past the offending stack frame and find the calling Java method.
This resolves the segfault, though now I get a ClassNotFoundException
trying to find my main class, which I haven't looked into yet.

 - Allan