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

[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