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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
