From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.8) Gecko/20050623 Fedora/1.0.4-5 Firefox/1.0.4 Description of problem: In a gcj compiled program, when attempting to execute a program on a shutdown hook (Runtime.addShutdownHook) using Runtime.exec(), the exec function fails and throws an unidentified exception with only "Abort" in it's stacktrace. The behavior does not happen every time, but at times shows up consistently. Version-Release number of selected component (if applicable): 4.0.1-3 How reproducible: Sometimes Steps to Reproduce: 1. gcj --main=TestCase TestCase.java 2. run the a.out Actual Results: An unchecked exception is thrown from exec() (it is being caught in the testcase). Additional info: The mailserver is down and I don't know how to add attachments accept through links in mail, so there's the test case code. public class TestCase { public static void main(String[] args) { Runtime.getRuntime().addShutdownHook(new Thread() { public void start() { try { Runtime.getRuntime().exec("touch hello"); } catch (IOException ioe) { System.out.println("IO exception"); } catch (Exception e) { System.out.println("Caught exception that shouldn't be here. Check out the stack trace: "); e.printStackTrace(); } } }); } }
Created attachment 117463 [details] the test case
For me this aborts while trying to print the stack trace -- oops.
I'm CCing Andrew since stack trace bugs are more his area. Andrew, the attached test case aborts trying to print a stack trace (I compile it to bytecode and run it with svn 4.1 gij). Here's what gdb says: (gdb) thread apply all bt Thread 2 (Thread 51813296 (LWP 6611)): #0 0x002cc402 in __kernel_vsyscall () #1 0x008617a6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x017559b7 in _Jv_CondWait (cv=0x271e6e0, mu=0x271e6c0, millis=0, nanos=0) at ../../../gcc-4_1-branch/libjava/posix-threads.cc:166 #3 0x01734b4a in gnu::gcj::runtime::FinalizerThread::run (this=0x4cb40) at ../../../gcc-4_1-branch/libjava/gnu/gcj/runtime/natFinalizerThread.cc:57 #4 0x0174a538 in _Jv_ThreadRun (thread=0x4cb40) at ../../../gcc-4_1-branch/libjava/java/lang/natThread.cc:299 #5 0x017552bd in really_start (x=0x68ff8) at ../../../gcc-4_1-branch/libjava/posix-threads.cc:430 #6 0x020664d8 in GC_start_routine (arg=0x43fa0) at ../../../gcc-4_1-branch/boehm-gc/pthread_support.c:1185 #7 0x0085fb80 in start_thread () from /lib/libpthread.so.0 #8 0x007b79ce in clone () from /lib/libc.so.6 Thread 1 (Thread -1208935968 (LWP 6605)): #0 0x002cc402 in __kernel_vsyscall () #1 0x00715118 in raise () from /lib/libc.so.6 #2 0x00716888 in abort () from /lib/libc.so.6 #3 0x0170db0f in _Jv_Throw (value=Could not find the frame base for "_Jv_Throw". ) at ../../../gcc-4_1-branch/libjava/exception.cc:111 ---Type <return> to continue, or q <return> to quit--- #4 0x017236d9 in _Jv_InterpMethod::run (retp=0xbfe2eca0, args=0xbfe2ecc0, meth=0x47930) at ../../../gcc-4_1-branch/libjava/interpret.cc:3284 #5 0x017238e1 in _Jv_InterpMethod::run_normal (ret=0xbfe2eca0, args=0xbfe2ecc0, __this=0x47930) at ../../../gcc-4_1-branch/libjava/interpret.cc:252 #6 0x0204a061 in ffi_closure_raw_SYSV () at ../../../gcc-4_1-branch/libffi/src/x86/sysv.S:225 #7 0x019fd074 in java.lang.Runtime.exit(int) (this=0x4fc30, status=0) at ../../../gcc-4_1-branch/libjava/java/lang/Runtime.java:162 #8 0x016fcd09 in _Jv_RunMain (vm_args=0xbfe2f090, klass=0x0, name=0xbfe2fa58 "TestCase", argc=1, argv=0xbfe2f188, is_jar=false) at ../../../gcc-4_1-branch/libjava/prims.cc:1393 #9 0x00edc348 in main (argc=2, argv=0xbfe2f184) at ../../../gcc-4_1-branch/libjava/gij.cc:333 #10 0x00701d5f in __libc_start_main () from /lib/libc.so.6 #11 0x08048461 in _start () (gdb)
The core bug here (not the stack trace thing) is that we're trying to create some new Thread objects after the main thread has been killed. This leads to an NPE since the main thread's group is now null.
I've fixed the shutdown-related bug on svn head and the 4.1 branch of the gcc repository. This fix ought to appear in fc5. Andrew, I didn't look for the stack unwinding issue. You might want to look at that before updating (or stick to revision 109399 on the trunk).
Should be fixed in gcc-4.1.0-0.14.