Bug#365409: [Pkg-openldap-devel] Bug#365409: slapd: segfaults on entry modify

[Steinar H. Gunderson]

On Mon, Jun 05, 2006 at 12:42:57AM +0200, Steinar H. Gunderson wrote:
> OK, the problem doesn't show up at -O0, which supports the theory that it's
> some kind of overflow issue. I'm starting a build with -O2 now -- perhaps it
> can be caught using valgrind on a slightly faster platform, though...

OK, valgrind didn't catch it, but I believe in the theory of a stack smashing
problem (which valgrind won't catch; bounds-checking gcc would, though).

Watch the following gdb session (on arm):

kose:~# gdb /usr/sbin/slapd
[banner]
(gdb) break modify_add_values
Breakpoint 1 at 0x6bb5c
(gdb) r -d 16383
Starting program: /usr/sbin/slapd -d 16383
[debug info]
[ldapmodify connecting from another session]
[more debug info]
[Switching to Thread 32771 (LWP 10007)]

Breakpoint 1, 0x0006bb5c in modify_add_values ()
(gdb) bt
#0  0x0006bb5c in modify_add_values ()
#1  0x40609b24 in bdb_modify_internal () from /usr/lib/ldap/back_bdb.so
#2  0x4060a894 in bdb_modify () from /usr/lib/ldap/back_bdb.so
#3  0x0003cbc0 in fe_op_modify ()
#4  0x0003dd58 in do_modify ()
#5  0x000295cc in connection_client_stop ()
#6  0x402d9f90 in __pthread_alt_lock () from /lib/libpthread.so.0
#7  0x00000000 in ?? ()
(gdb) info threads
* 4 Thread 32771 (LWP 10328)  0x0006bb5c in modify_add_values ()
  3 Thread 16386 (LWP 10247)  0x404001b4 in epoll_wait () from /lib/libc.so.6
  2 Thread 32769 (LWP 10246)  0x403f6f74 in poll () from /lib/libc.so.6
  1 Thread 16384 (LWP 10234)  0x402d80d0 in __pthread_sigsuspend () from /lib/libpthread.so.0
(gdb) stepi
0x0006bb60 in modify_add_values ()
(gdb)
0x0006bb64 in modify_add_values ()
(gdb)
0x0006bb68 in modify_add_values ()
(gdb)
0x0006bb6c in modify_add_values ()
(gdb)
daemon: select: listen=10 active_threads=0 tvp=NULL
0x0006bb70 in modify_add_values ()
(gdb) bt
#0  0x0006bb70 in modify_add_values ()
#1  0x40609b24 in bdb_modify_internal () from /usr/lib/ldap/back_bdb.so
#2  0xbe3ff908 in ?? ()
Cannot access memory at address 0x0

So, at some point, what I believe happens is that some other thread wakes up
(exactly at which instruction appears to be somewhat random -- all the
instructions I stepped over are simple mov or sub instructions), prints out a
debug message and in the process kills the current thread's stack. There's
evilness in here, and I hope it will get easier when I get a version with
-g... :-)

/* Steinar */
-- 
Homepage: http://www.sesse.net/