From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20843 invoked by alias); 15 Sep 2005 14:25:24 -0000 Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org Received: (qmail 20403 invoked by uid 48); 15 Sep 2005 14:25:06 -0000 Date: Thu, 15 Sep 2005 14:25:00 -0000 Message-ID: <20050915142506.20402.qmail@sourceware.org> From: "aeby at graeff dot com" To: java-prs@gcc.gnu.org In-Reply-To: <20050907131331.23763.aeby@graeff.com> References: <20050907131331.23763.aeby@graeff.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug libgcj/23763] Runtime.getRuntime().exec() signalling X-Bugzilla-Reason: CC X-SW-Source: 2005-q3/txt/msg00603.txt.bz2 List-Id: ------- 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