[Bug boehm-gc/28760] New: GC_PTHREAD_CREATE_NAME segfaults in statically linked binaries
Compiled java programs that are linked statically with gcj segfault on startup
(starting with GCC 4.1.x):
# gcj -g -static --main=test -Wl,--whole-archive -lnss_files_p -lnss_dns_p
-lresolv -lpthread -ldl -Wl,--no-whole-archive test.java
# ./a.out
Segmentation fault
with test.java being i.e.
public class test {
public static void main( String args[] ) {
System.err.println( "Hello" ); }}
GDB tells me the program is crashing in:
(gdb) bt
#0 0x in ?? ()
#1 0x081e89de in pthread_create (new_thread=0x86c733c, attr=0xba04,
start_routine=0x808fff0 , arg=0x74ff8) at
../.././boehm-gc/pthread_support.c:1289
#2 0x0808fee7 in _Jv_ThreadStart (thread=0x5cb18, data=0x86c7338,
meth=0x808cd30 <_Jv_ThreadRun(java::lang::Thread*)>) at
../.././libjava/posix-threads.cc:488
#3 0x0808c702 in java::lang::Thread::start (this=0x5cb18)
at ../.././libjava/java/lang/natThread.cc:328
#4 0x080620e4 in _Jv_CreateJavaVM (vm_args=0x0) at
../.././libjava/prims.cc:1334
#5 0x080622da in _Jv_RunMain (vm_args=0x0, klass=0x8441fc0, name=0x0,
argc=1, argv=0xbd84,
is_jar=false) at ../.././libjava/prims.cc:1355
#6 0x08062468 in _Jv_RunMain (klass=0x8441fc0, name=0x0, argc=1,
argv=0xbd84, is_jar=false)
at ../.././libjava/prims.cc:1401
#7 0x0806249b in JvRunMain (klass=0x8441fc0, argc=1, argv=0xbd84)
at ../.././libjava/prims.cc:1407
#8 0x0804824c in main (argc=Cannot access memory at address 0x1
) at /tmp/ccYuSF5L.i:11
Obviously, in line 1289 of pthread_support.c GC_PTHREAD_REAL_NAME is null due
to the fact that it is computed using dlvsym() in line 1218. Of course(?)
dlvsym() will return null if libpthread is statically linked.
My quick hack around the problem was to just disable the dlvsym() variation
(see attached patch). This seems to work for me.
Best regards,
Tom
--
Summary: GC_PTHREAD_CREATE_NAME segfaults in statically linked
binaries
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
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 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] 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 static linking - SEGV"). However, my answer to your (Andrew) question is: - for portability: The binary I am building statically is supposed to work out-of-the-box on as many machines as ever possible - for stability: Some systems out there are known to have deficiencies, i.e. Debian/woody came with a not completely thread-safe glibc, so linking glibc statically solves these issues, too - for reproducibility: ask users that complain about issues in your software to try out the statically built version and if the problem stops you know you've found another combination of library versions your software does not work well with (or you can confirm that your software, not the runtime environment has a bug in the other case) > It will almost not work for other cases. I cannot confirm this. The project I'm trying to build statically with 4.1.1 is built statically for years with earlier gcc versions with less problems than the dynamic builds had ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28760
[Bug libgcj/23763] New: Runtime.getRuntime().exec() signalling
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
--- 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
--- 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
-- 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
--- 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
--- 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
[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 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
--- 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
