GCJ Interpreter SEGV w/ Dynamically Linked Program

[Craig A. Vanderborgh]

Hello Everyone:

I have made some progress getting the 4.1-112505 snapshot running.  
Right now, I am testing on 2 platforms, one is x86 linux (RHEL4) and the 
other is PowerPC 604.  I have correct builds for both, but am having one 
last problem, which is reproducible on both.

For DYNAMICALLY LINKED programs, the GCJ interpreter fails with a SEGV 
when it is processing JavaScript stuff in our browser.  A typical stack 
trace (on RHEL4/X86) looks like this:

#0  0x005f17a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) where
#0  0x005f17a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x00250955 in raise () from /lib/tls/libc.so.6
#2  0x00252319 in abort () from /lib/tls/libc.so.6
#3  0x008d25b8 in _Jv_Throw (value=0x441588) at 
../../../gcc-4.1-20051125/libjava/exception.cc:111
#4  0x008c5ccb in catch_segv (_dummy=Could not find the frame base for 
"catch_segv".
) at ../../../gcc-4.1-20051125/libjava/prims.cc:152
#5  <signal handler called>
#6  0x02368902 in ?? ()
#7  0x00b0e027 in ffi_call_SYSV () at 
../../../gcc-4.1-20051125/libffi/src/x86/sysv.S:60
#8  0x00b0ddc3 in ffi_raw_call (cif=0x3a11278, fn=0x2368900, 
rvalue=0xbfee0718, fake_avalue=0xbfee0490)
    at ../../../gcc-4.1-20051125/libffi/src/x86/ffi.c:449
#9  0x008dc535 in _Jv_InterpMethod::run (retp=0xbfee0920, 
args=0xbfee0940, meth=0x4c9070)
    at ../../../gcc-4.1-20051125/libjava/interpret.cc:1217
#10 0x008df61b in _Jv_InterpMethod::run_normal (ret=0xbfee0920, 
args=0xbfee0940, __this=0x4c9070)
    at ../../../gcc-4.1-20051125/libjava/interpret.cc:252
#11 0x00b0e101 in ffi_closure_raw_SYSV () at 
../../../gcc-4.1-20051125/libffi/src/x86/sysv.S:225
#12 0x080864f7 in voxware::browser::Expr::evaluateInScriptable ()
#13 0x08086378 in voxware::browser::Expr::evaluate ()
#14 0x08097e4c in voxware::browser::SystemProperty::enter ()
#15 0x0809f327 in voxware::browser::ScopeElement::modifyProperties ()
#16 0x08091c22 in voxware::browser::Page::interpret ()
#17 0x080730cd in voxware::browser::Application::interpret ()
#18 0x080a103e in voxware::browser::Session::interpret ()
#19 0x080a4162 in voxware::browser::Session::run ()
#20 0x080a42d9 in voxware::browser::Session::run ()
#21 0x0807fd6b in voxware::browser::DOMBrowser::main ()
#22 0x008f3044 in gnu::java::lang::MainThread::call_main (this=0x65ee0)
    at ../../../gcc-4.1-20051125/libjava/gnu/java/lang/natMainThread.cc:47
#23 0x00924ca7 in gnu.java.lang.MainThread.run() (this=0x65ee0) at 
MainThread.java:105
#24 0x009022fb in _Jv_ThreadRun (thread=0x65ee0) at 
../../../gcc-4.1-20051125/libjava/java/lang/natThread.cc:299
#25 0x008c700a in _Jv_RunMain (vm_args=0x0, klass=0x837b380, name=0x0, 
argc=16, argv=0xbfee0e04, is_jar=false)
    at ../../../gcc-4.1-20051125/libjava/prims.cc:1389
#26 0x008c7184 in _Jv_RunMain (klass=0x837b380, name=0x0, argc=16, 
argv=0xbfee0e04, is_jar=false)
    at ../../../gcc-4.1-20051125/libjava/prims.cc:1400
#27 0x008c71c7 in JvRunMain (klass=0x837b380, argc=16, argv=0xbfee0e04) 
at ../../../gcc-4.1-20051125/libjava/prims.cc:1406
#28 0x0805f508 in main ()
(gdb)

So at the time it fails, it's in FFI closures doing something that's 
needed as part of JS interpretation.  That's all I really know right now 
and it's not that much to go on.

But isn't the fact that the application works when statically linked a 
pretty big clue?  Any ideas about how to proceed from here?

Any input greatly appreciated...

Thanks in advance,
craig vanderborgh
voxware incorporated