Strange C++ crashes on program exit

[Francois Tigeot <ftigeot@xxxxxxxxxxxx>]

Hi all,

For the last month or so, I have been working on porting LibreOffice to
DragonFly.
I believe it is mostly done, but some issues remain. Most importantly,
some automated tests consistently fail on DragonFly whereas there is no
problem on other systems.

These tests use cppunit with newly generated shared libraries.
Here's a small example:

  ----------------------------------------------------------
  - start unit test #1 on library ../../unxdflyx3.pro/lib/librtl_OStringBuffer.so
  ----------------------------------------------------------
  : && LD_LIBRARY_PATH=${LD_LIBRARY_PATH+${LD_LIBRARY_PATH}:}/home/ftigeot/Projects/LibreOffice/bootstrap/clone/ure/sal/unxdflyx3.pro/lib:/home/ftigeot/Projects/LibreOffice/bootstrap/solver/330/unxdflyx3.pro/lib ../../unxdflyx3.pro/bin/cppunittester ../../unxdflyx3.pro/lib/librtl_OStringBuffer.so
  OK (0)
  /usr/pkg/bin/bash: line 1: 13320 Segmentation fault: 11  (core dumped) LD_LIBRARY_PATH=${LD_LIBRARY_PATH+${LD_LIBRARY_PATH}:}/home/ftigeot/Projects/LibreOffice/bootstrap/clone/ure/sal/unxdflyx3.pro/lib:/home/ftigeot/Projects/LibreOffice/bootstrap/solver/330/unxdflyx3.pro/lib ../../unxdflyx3.pro/bin/cppunittester ../../unxdflyx3.pro/lib/librtl_OStringBuffer.so
  dmake:  Error code 139, while making 'test1'


The problem is, the test program itself doesn't crash. The "OK (0)" is proof
that it completed successfully.

The crash seems to occur in some internal cleanup function of the C library.
Running the test program in gdb, I get this:

(gdb) run
Starting program:
/home/ftigeot/Projects/LibreOffice/bootstrap/clone/ure/sal/unxdflyx3.pro/bin/cppunittester ../../unxdflyx3.pro/lib/librtl_OStringBuffer.so
OK (0)

Program received signal SIGSEGV, Segmentation fault.
0x0000000801535510 in ?? ()
(gdb) bt
#0  0x0000000801535510 in ?? ()
#1  0x00000008010b7db9 in __cxa_finalize (dso=0x0) at /usr/src/lib/libc/../libc/stdlib/atexit.c:178
#2  0x00000008010b7a4a in exit (status=0) at /usr/src/lib/libc/../libc/stdlib/exit.c:64
#3  0x000000000040223a in _start (ap=0x7fffffffcec0, cleanup=0x80050ef0d <rtld_exit>) at /usr/src/lib/csu/x86_64/crt1.c:101
(gdb)


I must add that this result was obtained with a gcc-4.4 compiled test program
and set of libraries; when using gcc-4.1, gdb ends up in a 'wait' state and
becomes completely unresponsive.

I'm not sure what to make of this; I hope some of the gurus lurking on this
list may be able to shine some light on this subject...

-- 
Francois Tigeot