[Bug boehm-gc/28760] GC_PTHREAD_CREATE_NAME segfaults in statically linked binaries

--- Comment #4 from aeby at graeff dot com 2006-08-17 19:43 --- A bug tracker is not the right place to discuss philosophy questions, so if you'd like to continue the discussion, we should move over to e-mail or the gcj mailing list (lookout for subject: "GCJ 4.1.1 and stat

[Bug boehm-gc/28760] GC_PTHREAD_CREATE_NAME segfaults in statically linked binaries

--- Comment #1 from aeby at graeff dot com 2006-08-17 11:50 --- Created an attachment (id=12087) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12087&action=view) Ugly workaround GC_PTHREAD_CREATE_NAME segfault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28760

[Bug boehm-gc/28760] New: GC_PTHREAD_CREATE_NAME segfaults in statically linked binaries

Severity: normal Priority: P3 Component: boehm-gc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aeby at graeff dot com GCC build triplet: i386-pc-linux GCC host triplet: i386-pc-linux GCC target triplet: i386-pc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28760

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

--- 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

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

--- 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

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

--- 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/b

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

--- 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

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

-- 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

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

--- 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

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

--- 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] New: Runtime.getRuntime().exec() signalling

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-li