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

2006-08-17 Thread aeby at graeff dot com
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 boehm-gc/28760] GC_PTHREAD_CREATE_NAME segfaults in statically linked binaries

2006-08-17 Thread aeby at graeff dot com
--- 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=12087action=view) Ugly workaround GC_PTHREAD_CREATE_NAME segfault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28760

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

2006-08-17 Thread aeby at graeff dot com
--- 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 static linking

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

2005-10-26 Thread 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

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

2005-10-26 Thread 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

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

2005-09-15 Thread 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

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

2005-09-15 Thread 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=9734action=view) workaround: patch against GCC 4.0.1 unblocking SIGCHLD before execvp() -- http://gcc.gnu.org/bugzilla

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

2005-09-08 Thread aeby at graeff dot com
-- What|Removed |Added Known to fail||4.0.0 4.0.1 Known to work||3.3.3

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

2005-09-07 Thread aeby at graeff dot com
: 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

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

2005-09-07 Thread 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=9686action=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

2005-09-07 Thread 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=9687action=view) Sample program that hangs when executed via Runtime.exec() -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id