Bug 165136

Summary: gcj: execing processes on shutdownhook fails
Product: [Fedora] Fedora Reporter: Ivan Pantuyev <ipantuye>
Component: gccAssignee: Tom Tromey <tromey>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: aph, jakub, patrickm
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: 4.1.0-0.14 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-01-07 17:07:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
the test case none

Description Ivan Pantuyev 2005-08-04 16:17:40 UTC
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();
				}
			}
		});
	}
}

Comment 1 Ivan Pantuyev 2005-08-04 16:18:34 UTC
Created attachment 117463 [details]
the test case

Comment 2 Tom Tromey 2006-01-04 21:31:00 UTC
For me this aborts while trying to print the stack trace -- oops.


Comment 3 Tom Tromey 2006-01-04 23:13:20 UTC
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)



Comment 4 Tom Tromey 2006-01-05 00:18:13 UTC
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.


Comment 5 Tom Tromey 2006-01-06 01:01:51 UTC
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).


Comment 6 Jakub Jelinek 2006-01-07 17:07:59 UTC
Should be fixed in gcc-4.1.0-0.14.