__cxa_atexit and "FAIL: cxxtest run"

Wed Dec 14 09:45:00 GMT 2005

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[CC-ing libstdc++ for any possible insights into this issue.]

Hi,

  As I indicated in an earlier message, I have started seeing
a "FAIL: cxxtest run" in the libjava testsuite on GCC mainline
in recent times (a week, or two at the most). This testcase
can be found in "$GCC_SRC/libjava/testsuite/libjava.jni".

I don't see a "FAIL: cxxtest run" in some of the recent
libjava testresults sent by other people for
i686-pc-linux-gnu:

  http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00740.html
  http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00738.html

but the fact remains that I do get to see this failure
consistently for my runs. My GCC bootstrap is configured
like so:

$GCC_SRC_DIR/configure --prefix=$HOME/gcc --enable-languages=c,c++,java \
- --with-as=/home/ranmath/gnu/bin/as --with-gnu-as \
- --with-ld=/home/ranmath/gnu/bin/ld --with-gnu-ld \
- --with-arch=pentium4 --with-tune=pentium4 \
- --disable-nls --disable-checking --disable-libmudflap \
- --disable-debug --enable-threads=posix --enable-__cxa_atexit

and I'm using GCC 3.4.5 for bootstrapping. The libc I'm
using is FSF glibc-2.3.2 plus whatever Red Hat put in for
RHEL 3AS Update 5.

The difference is that I use "--enable-__cxa_atexit" for
configuring GCC while the others don't. I prefer to use
this option, the system GCC provided by Red Hat uses it
and according to:

  http://gcc.gnu.org/install/configure.html

it is essential for full standards compliance. If I omit
this option, I *do not* get to see this failure.

What I've noticed is that the "cxxtest" executable doesn't
abort if I use libstdc++.so.6 from GCC 3.4.5, but it does
when I use this library from mainline.

Here's some more information:
- ---------------------------- 8< ----------------------------
$ echo $LD_LIBRARY_PATH
/home/ranmath/gnu/lib:/home/ranmath/src/gcc/build/i686-pc-linux-gnu/libjava/.libs

$ ./cxxtest
true

$ export LD_LIBRARY_PATH=/home/ranmath/src/gcc/build/i686-pc-linux-gnu/libstdc++-v3/src/.libs:$LD_LIBRARY_PATH

$ ./cxxtest
true
Aborted

$ gdb --quiet ./cxxtest
Using host libthread_db library "/lib/tls/libthread_db.so.1".
(gdb) r
Starting program: /home/ranmath/src/gcc/build/i686-pc-linux-gnu/libjava/testsuite/cxxtest
[Thread debugging using libthread_db enabled]
[New Thread -1218565632 (LWP 15269)]
[New Thread 49458096 (LWP 15272)]
true

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1218565632 (LWP 15269)]
0x00213a3f in xdr_u_long_internal () from /lib/tls/libc.so.6
(gdb) bt
#0  0x00213a3f in xdr_u_long_internal () from /lib/tls/libc.so.6
#1  0x0013b6c3 in exit () from /lib/tls/libc.so.6
#2  0x0182cbad in java::lang::Runtime::exitInternal (this=0x51c30, status=0)
    at /home/ranmath/src/gcc/gcc/libjava/java/lang/natRuntime.cc:106
#3  0x01a0a0c3 in _ZN4java4lang7Runtime4haltEJvi (this=0x51c30, status=0)
    at Runtime.java:338
#4  0x01a16395 in _ZN4java4lang7Runtime4exitEJvi (this=0x51c30, status=0)
    at Runtime.java:224
#5  0x017f8682 in _Jv_RunMain (vm_args=0x0, klass=0x80492a0, name=0x0, argc=1,
    argv=0xbfffb7b4, is_jar=false)
    at /home/ranmath/src/gcc/gcc/libjava/prims.cc:1393
#6  0x017f87ca in _Jv_RunMain (klass=0x80492a0, name=0x0, argc=1,
    argv=0xbfffb7b4, is_jar=false)
    at /home/ranmath/src/gcc/gcc/libjava/prims.cc:1400
#7  0x017f880b in JvRunMain (klass=0x80492a0, argc=1, argv=0xbfffb7b4)
    at /home/ranmath/src/gcc/gcc/libjava/prims.cc:1406
#8  0x08048b64 in main (argc=Cannot access memory at address 0x3
) at /tmp/cc2a5UcT.i:11
(gdb) thread 2
[Switching to thread 2 (Thread 49458096 (LWP 15272))]#0  0x00a1c26d in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
(gdb) bt
#0  0x00a1c26d in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/libpthread.so.0
#1  0x018370e2 in _Jv_CondWait (cv=0x23f2300, mu=0x23f22e0, millis=0, nanos=0)
    at /home/ranmath/src/gcc/gcc/libjava/posix-threads.cc:166
#2  0x018216c2 in gnu::gcj::runtime::FinalizerThread::run (this=0x4db40)
    at /home/ranmath/src/gcc/gcc/libjava/gnu/gcj/runtime/natFinalizerThread.cc:5
7
#3  0x0182fdcd in _Jv_ThreadRun (thread=0x4db40)
    at /home/ranmath/src/gcc/gcc/libjava/java/lang/natThread.cc:299
#4  0x01836caa in really_start (x=0x60ff8)
    at /home/ranmath/src/gcc/gcc/libjava/posix-threads.cc:430
#5  0x01d9cc05 in GC_start_routine (arg=0x43fa0)
    at /home/ranmath/src/gcc/gcc/boehm-gc/pthread_support.c:1185
#6  0x00a19de8 in start_thread () from /lib/tls/libpthread.so.0
#7  0x001ed93a in clone () from /lib/tls/libc.so.6
(gdb) c
Continuing.

Program received signal SIGABRT, Aborted.
0x00138cdf in raise () from /lib/tls/libc.so.6
- ---------------------------- 8< ----------------------------

- From the source RPM corresponding to the installed glibc,
I see that exit() doesn't call xdr_<anything> directly and
it therefore must be called from within one of the atexit()-
registered functions or a destructor invoked by __cxa_atexit().

XDR routines are used in RPC, right? Why are they being
pulled in for a simple JNI test for libjava? More puzzlingly,
why doesn't this problem surface for any other testcase?

Does this issue ring a bell for anyone here? Can someone
tell me how I can track this problem down to the offending
bit that has been introduced in recent times into either
libjava or libstdc++?

Many thanks in advance,
Ranjit.

- --
Ranjit Mathew      Email: rmathew AT gmail DOT com

Bangalore, INDIA.    Web: http://ranjitmathew.hostingzero.com/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDn+JtYb1hx2wRS48RArppAJ9PDwfeh9RWI0XMKrzM+wnRIpOaeACfVCks
wUltHMmYJVWQqI7VlmHHduA=
=hs5M
-----END PGP SIGNATURE-----