[Bug libgcj/23763] Runtime.getRuntime().exec() signalling

[Bug libgcj/23763] Runtime.getRuntime().exec() signalling

[aeby at graeff dot com]

------- Comment #6 from aeby at graeff dot com  2005-10-26 08:48 -------
I have just tested against 4.0.2 and the bug is still there (no surprise, of
course).


-- 

aeby at graeff dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|4.0.0 4.0.1                 |4.0.0 4.0.1 4.0.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23763

[Bug libgcj/23763] Runtime.getRuntime().exec() signalling

[tromey at gcc dot gnu dot org]

------- Comment #7 from tromey at gcc dot gnu dot org  2005-10-26 09:01 -------
Sorry for the delay on this.
The patch looks reasonable enough to me.  It needs a small
amount of reformatting and a ChangeLog entry.
Also I think the call to signal() is not needed, a custom
handler is reset to the default on exec.


-- 

tromey at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-10-26 09:01:06
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23763

[Bug libgcj/23763] Runtime.getRuntime().exec() signalling

[aeby at graeff dot com]

------- Comment #8 from aeby at graeff dot com  2005-10-26 18:04 -------
no problem ...

I thought, resetting the signal handler to SIG_DFL before unblocking might be a
good idea in the (not very probable) case a SIGCHLD signal is either in the
signal queue or is otherwise received between sigprocmask() and exec(), just to
be safe :-)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23763

[Bug libgcj/23763] Runtime.getRuntime().exec() signalling

[tromey at gcc dot gnu dot org]

------- Comment #9 from tromey at gcc dot gnu dot org  2005-11-08 19:44 -------
I'm handling this.


-- 

tromey at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |tromey at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2005-10-26 09:01:06         |2005-11-08 19:44:20
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23763

[Bug libgcj/23763] Runtime.getRuntime().exec() signalling

[tromey at gcc dot gnu dot org]

------- Comment #10 from tromey at gcc dot gnu dot org  2005-11-08 20:59 -------
Subject: Bug 23763

Author: tromey
Date: Tue Nov  8 20:59:20 2005
New Revision: 106654

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106654
Log:
        PR libgcj/23763.  From aeby@graeff.com.
        * java/lang/natPosixProcess.cc (nativeSpawn): Unblock SIGCHLD
        before exec.

Modified:
    branches/gcc-4_0-branch/libjava/ChangeLog
    branches/gcc-4_0-branch/libjava/java/lang/natPosixProcess.cc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23763

[Bug libgcj/23763] Runtime.getRuntime().exec() signalling

[tromey at gcc dot gnu dot org]

------- Comment #11 from tromey at gcc dot gnu dot org  2005-11-08 21:00 -------
Subject: Bug 23763

Author: tromey
Date: Tue Nov  8 21:00:15 2005
New Revision: 106655

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106655
Log:
        PR libgcj/23763.  From aeby@graeff.com.
        * java/lang/natPosixProcess.cc (nativeSpawn): Unblock SIGCHLD
        before exec.

Modified:
    trunk/libjava/ChangeLog
    trunk/libjava/java/lang/natPosixProcess.cc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23763

[Bug libgcj/23763] Runtime.getRuntime().exec() signalling

[tromey at gcc dot gnu dot org]

------- Comment #12 from tromey at gcc dot gnu dot org  2005-11-08 21:01 -------
Fix checked in.


-- 

tromey at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.0.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23763

[Bug libgcj/23763] New: Runtime.getRuntime().exec() signalling

[aeby at graeff dot com]

Showcase: compile exectest.c, run test.java calling 'exectest'

Runtime.exec() seems to pass down some strange signal configuration to child
processes in GCC >=4.0.0. When run from test.java the exectest.c parent process
does never get CHLD signals - they seem to get blocked (as I've seen the
rtsig-queue growing each time test.java was run).

GCC 3.3.3 does not have this problem.

-- 
           Summary: Runtime.getRuntime().exec() signalling
           Product: gcc
           Version: 4.0.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libgcj
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: aeby at graeff dot com
                CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
                    dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23763

[Bug libgcj/23763] Runtime.getRuntime().exec() signalling

[aeby at graeff dot com]

------- Additional Comments From aeby at graeff dot com  2005-09-07 13:17 -------
Created an attachment (id=9686)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9686&action=view)
Execs "exectest" and demonstrates how it hangs


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23763

[Bug libgcj/23763] Runtime.getRuntime().exec() signalling

[aeby at graeff dot com]

------- Additional Comments From aeby at graeff dot com  2005-09-07 13:18 -------
Created an attachment (id=9687)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9687&action=view)
Sample program that hangs when executed via Runtime.exec()


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23763

[Bug libgcj/23763] Runtime.getRuntime().exec() signalling

[aeby at graeff dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.0.0 4.0.1
      Known to work|                            |3.3.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23763

[Bug libgcj/23763] Runtime.getRuntime().exec() signalling

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-10 02:20 -------
This is might be the same problem as described in PR 23758.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |23758
              nThis|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23763

[Bug libgcj/23763] Runtime.getRuntime().exec() signalling

[aeby at graeff dot com]

------- Additional Comments From aeby at graeff dot com  2005-09-15 14:24 -------
I don't think this bug is linked with 23758. No matter if you call unsafe
procedures before or after fork() SIGCHLD ist still blocked at the point where
execvp() is called. It seems the posix-threads code does explicitly block
SIGCHLD signals (block_sigchld() in libjava/posix-threads.cc) without unblocking
them before calling execvp(). Therefore, the child process runs with SIGCHLD
blocked, too.

I'm attaching a dirty hack(?) fixing the problem for me (just sets signal
handler for SIGCHLD to SIG_DFL and unblock SIGCHLD just before execvp()).

BTW: Am I the only person in the world that is trying to exec() external
programs from Java? :-))

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23763

[Bug libgcj/23763] Runtime.getRuntime().exec() signalling

[aeby at graeff dot com]

------- Additional Comments From aeby at graeff dot com  2005-09-15 14:27 -------
Created an attachment (id=9734)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9734&action=view)
workaround: patch against GCC 4.0.1 unblocking SIGCHLD before execvp()


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23763