Stray "cxxtest" processes

Tue Jun 4 20:27:00 GMT 2002

On Tue, Jun 04, 2002 at 12:54:30PM -0600, Tom Tromey wrote:
>> Zack> Anyone seen this? Or know why it gets stuck like that? The
> Zack> code in cxxtest.{cc,java} is unenlightening.
>> Could you get a stack trace? That might help.

(gdb) bt
#0 0x4012287e in sigsuspend () from /lib/libc.so.6
#1 0x407c1879 in __pthread_wait_for_restart_signal ()
 from /lib/libpthread.so.0
#2 0x407c1436 in pthread_onexit_process () from /lib/libpthread.so.0
#3 0x407c1773 in pthread_kill_other_threads_np () from /lib/libpthread.so.0
#4 0x40199ed6 in execve () from /lib/libc.so.6
#5 0x4019a2ef in execvp () from /lib/libc.so.6
#6 0x40457827 in java::lang::ConcreteProcess::startProcess(JArray<java::lang::String*>*, JArray<java::lang::String*>*) (this=0x8092f40, progarray=0x80c9b78, 
 envp=0x8076fb8) at java/lang/natConcreteProcess.cc:233
#7 0x405d4e78 in java.lang.ConcreteProcess.ConcreteProcess(java.lang.String[], java.lang.String[]) (this=0x80c9b78, progarray=0xfffffffc, envp=0xfffffffc)
 at java/lang/ConcreteProcess.java:64
#8 0x4045af05 in java::lang::Runtime::execInternal(JArray<java::lang::String*>*, JArray<java::lang::String*>*) (this=0x8090f60, cmd=0xfffffffc, 
 env=0xfffffffc) at ../../../libjava/java/lang/natRuntime.cc:543
#9 0x4046fe6c in java.lang.Runtime.exec(java.lang.String[], java.lang.String[], java.io.File) (this=0x8090f60, cmd=0x8092f40, env=0x80c9b78, dir=0x0)
 at ../../../libjava/java/lang/Runtime.java:540
#10 0x4046fd9a in java.lang.Runtime.exec(java.lang.String, java.lang.String[], java.io.File) (this=0x8090f60, cmdline=0xfffffffc, env=0xfffffffc, 
 dir=0xfffffffc) at ../../../libjava/java/lang/Runtime.java:471
#11 0x4046fca8 in java.lang.Runtime.exec(java.lang.String) (this=0xfffffffc, 
 cmdline=0xfffffffc) at ../../../libjava/java/lang/Runtime.java:423
#12 0x4047cb46 in java.lang.CPlusPlusDemangler.CPlusPlusDemangler(java.io.PrintWriter) (this=0x80c9b78, writer=0xfffffffc)
 at ../../../libjava/java/lang/Throwable.java:89
#13 0x4047c971 in java.lang.Throwable.printStackTrace(java.io.PrintWriter) (
 this=0x8090f18, wr=0x809cb30)
 at ../../../libjava/java/lang/Throwable.java:462
#14 0x4047c920 in java.lang.Throwable.printStackTrace(java.io.PrintStream) (
 this=0x8090f18, s=0xfffffffc)
 at ../../../libjava/java/lang/Throwable.java:448
#15 0x4047acec in java.lang.ThreadGroup.uncaughtException(java.lang.Thread, java.lang.Throwable) (this=0xfffffffc, thread=0x8090f18, t=0x8090f18)
 at ../../../libjava/java/lang/ThreadGroup.java:528
#16 0x4045dbf8 in _Jv_ThreadRun(java::lang::Thread*) (thread=0x80a8fc0)
 at ../../../libjava/java/lang/natThread.cc:293
#17 0x40420f7c in _Jv_RunMain(java::lang::Class*, char const*, int, char const**, bool) (klass=0x8049100, name=0x0, argc=1, argv=0xbfffdae4, is_jar=false)
 at ../../../libjava/prims.cc:1010
#18 0x4042109d in JvRunMain (klass=0xfffffffc, argc=-4, argv=0xfffffffc)
 at ../../../libjava/prims.cc:1020
#19 0x08048b14 in main (argc=1, argv=0xbfffdae4) at /tmp/ccehZ6GT.i:11
This looks suspiciously like a C library bug with fork() called from a
threaded program.
Wasn't the license for the demangler fixed so that it could be linked
into libjava, thus eliminating the need to spawn a separate process?
zw