I wanted to use duma for debugging a possible free issue inside of OpenLDAP, but found that trying to use duma simply fails. I tried the release from the SF site (2.5.14) and from CVS (2.5.15?).
In either case, as soon as I attempt to start slapd with duma preloaded, the system just crashes with a core file in one of the OS level functions:
[zimbra@freelancer ~]$ ldap start
DUMA 2.5.15 (shared library, NO_LEAKDETECTION)
Copyright (C) 2006 Michael Eddington <meddington@gmail.com>
Copyright (C) 2002-2008 Hayati Ayguen <h_ayguen@web.de>, Procitec GmbH
Copyright (C) 1987-1999 Bruce Perens <bruce@perens.com>
Core was generated by `/opt/zimbra/openldap/libexec/slapd -l LOCAL0 -4 -u zimbra -h ldap://freelancer.'.
Program terminated with signal 4, Illegal instruction.
#0 0x00000038dc030497 in ?? ()
(gdb) bt
#0 0x00000038dc030497 in ?? ()
Cannot access memory at address 0x7fff8dbbfc68
(gdb) l
295 main.c: No such file or directory.
in main.c
Note that the ldap start script executes a script as root via sudo, which has the LD_PRELOAD bit in it for duma.
I do not have this problem using electric fence v2.2.2 with the patches from Howard Chu, so this looks to be a duma specific issue.
--Quanah
My compilation of DUMA-2.4.27 has this same problem. I ran echo under gdb with LD_PRELOAD=libduma.so.0.0 and got this output:
(gdb) set env LD_PRELOAD=libduma.so.0.0
(gdb) exec /bin/echo
(gdb) set args test
(gdb) run
Starting program: /bin/echo test
DUMA 2.4.27 (shared library)
Copyright (C) 2002-2006 Hayati Ayguen <h_ayguen@web.de>, Procitec GmbH
Copyright (C) 1987-1999 Bruce Perens <bruce@perens.com>
Using host libthread_db library "/lib64/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
DUMA 2.4.27 (shared library)
Copyright (C) 2002-2006 Hayati Ayguen <h_ayguen@web.de>, Procitec GmbH
Copyright (C) 1987-1999 Bruce Perens <bruce@perens.com>
test
[New Thread 0x2b10322c3b20 (LWP 4275)]
Program received signal SIGILL, Illegal instruction.
[Switching to Thread 0x2b10322c3b20 (LWP 4275)]
0x00002b10315edf37 in kill () from /lib64/libc.so.6
(gdb) bt
#0 0x00002b10315edf37 in kill () from /lib64/libc.so.6
#1 0x00002b10313b94ae in DUMA_Abort (pattern=<value optimized out>) at print.c:304
#2 0x00002b10313b6efe in DUMA_delFrame () at duma.c:1604
#3 0x00002b10313b6f25 in _duma_exit () at duma.c:1629
#4 0x00002b10313b562f in ?? () from /usr/lib/libduma.so.0.0
(gdb)
But this doesn't happen for me under DUMA-2.5.13. So this bug is probably invalid or out of date?
Quanah: Do you still have this problem, and what version of DUMA do you use (not that I'm an official or anything:-))?
As per my original post, I used 2.5.14 (the official current release) and the source from SVN. Both failed.