Howard Chu wrote:
hyc@symas.com wrote:
I suspect this is a bug in glibc mcheck's pthread support, since ElectricFence with EF_PROTECT_BELOW set will detect 100% of all memory underruns, and no such error occurs there.
Also this report (which it seems the original is no longer accessible) implies the same problem with mcheck
http://www.google.com/search?q=cache:dAqJIBQSNRQJ:groups.google.com/group/gn...
Eh... Looking at glibc's mcheck code http://sourceware.org/cgi-bin/cvsweb.cgi/libc/malloc/?cvsroot=glibc shows that it has no mutex protection at all. It is completely invalid here, this ITS will be closed.
By the way, this stzck trace confirms the problem: (gdb) info thr 17 Thread 1208023360 (LWP 4680) 0x00002ae575308491 in clone () from /lib64/libc.so.6 16 Thread 1199630656 (LWP 4679) 0x00002ae575277535 in raise () from /lib64/libc.so.6 15 Thread 1191237952 (LWP 4678) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 * 14 Thread 1182845248 (LWP 4677) 0x00002ae5752bc3b7 in memset () from /lib64/libc.so.6 13 Thread 1174452544 (LWP 4676) 0x00002ae5752b8733 in mcheck_check_all () from /lib64/libc.so.6 12 Thread 1166059840 (LWP 4675) 0x00002ae5752b8762 in unlink_blk () from /lib64/libc.so.6 11 Thread 1157667136 (LWP 4674) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 10 Thread 1149274432 (LWP 4673) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 9 Thread 1140881728 (LWP 4672) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 8 Thread 1132489024 (LWP 4671) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 7 Thread 1124096320 (LWP 4670) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 6 Thread 1115703616 (LWP 4669) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 5 Thread 1107310912 (LWP 4665) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 4 Thread 1098918208 (LWP 4655) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 3 Thread 1090525504 (LWP 4650) 0x00002ae57467ea68 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 2 Thread 1082132800 (LWP 4639) 0x00002ae5753088b8 in ?? () from /lib64/libc.so.6 1 Thread 47165004620160 (LWP 4632) 0x00002ae5746795d5 in pthread_join () from /lib64/libpthread.so.0 (gdb) thr 13 [Switching to thread 13 (Thread 1174452544 (LWP 4676))]#0 0x00002ae5752b8733 in mcheck_check_all () from /lib64/libc.so.6 (gdb) bt #0 0x00002ae5752b8733 in mcheck_check_all () from /lib64/libc.so.6 #1 0x00002ae5752b89b9 in mallochook () from /lib64/libc.so.6 #2 0x00002ae57410f865 in ber_memalloc_x (s=9297104, ctx=0x2ae57410f865) at ../../../head/libraries/liblber/memory.c:226 #3 0x00002ae57410fd68 in ber_dupbv_x (dst=0x46009b80, src=0x2aaaaadae240, ctx=0x0) at ../../../head/libraries/liblber/memory.c:501 #4 0x00002ae573ed26ce in ldap_bv2escaped_filter_value_x (in=0x2aaaaadae240, out=0x46009b80, inplace=0, ctx=0x933bd0) at search.c:468 #5 0x000000000043d239 in filter2bv_x (op=0x92e4c0, f=0x2aaaaadae280, fstr=0x92e538) at ../../../head/servers/slapd/filter.c:608 #6 0x000000000043a943 in do_search (op=0x92e4c0, rs=0x4600acb0) at ../../../head/servers/slapd/search.c:138 #7 0x0000000000437e5e in connection_operation (ctx=0x4600ade0, arg_v=0x92e4c0) at ../../../head/servers/slapd/connection.c:1145 #8 0x0000000000438332 in connection_read_thread (ctx=0x4600ade0, argv=0xb) at ../../../head/servers/slapd/connection.c:1271 #9 0x00002ae573ece7e7 in ldap_int_thread_pool_wrapper (xpool=0x7dae80) at ../../../head/libraries/libldap_r/tpool.c:614 #10 0x00002ae57467809e in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae5753084cd in clone () from /lib64/libc.so.6 #12 0x0000000000000000 in ?? () (gdb) thr 12 [Switching to thread 12 (Thread 1166059840 (LWP 4675))]#0 0x00002ae5752b8762 in unlink_blk () from /lib64/libc.so.6 (gdb) bt #0 0x00002ae5752b8762 in unlink_blk () from /lib64/libc.so.6 #1 0x00002ae5752b8a36 in freehook () from /lib64/libc.so.6 #2 0x000000000045b93d in ch_free (ptr=0x7d9370) at ../../../head/servers/slapd/ch_malloc.c:139 #3 0x000000000049accd in slap_sasl_open (conn=0x2ae5769dbe60, reopen=<value optimized out>) at ../../../head/servers/slapd/sasl.c:1395 #4 0x00000000004368d9 in connection_init (s=18, listener=0x7a2ad0, dnsname=0x4efe78 "unknown", peername=0x45808ca0 "IP=127.0.0.1:36732", flags=0, ssf=0, authid=0x0, peerbv=0x45808c80) at ../../../head/servers/slapd/connection.c:633 #5 0x00000000004332e0 in slap_listener (sl=0x7a2ad0) at ../../../head/servers/slapd/daemon.c:1823 #6 0x0000000000433489 in slap_listener_thread (ctx=0x45809de0, ptr=0x7a2ad0) at ../../../head/servers/slapd/daemon.c:1856 #7 0x00002ae573ece7e7 in ldap_int_thread_pool_wrapper (xpool=0x7dae80) at ../../../head/libraries/libldap_r/tpool.c:614 #8 0x00002ae57467809e in start_thread () from /lib64/libpthread.so.0 #9 0x00002ae5753084cd in clone () from /lib64/libc.so.6 #10 0x0000000000000000 in ?? () (gdb)
Note that thread 12 is removing a block from the chunk list while thread 13 is walking the list. There is absolutely no thread safety here whatsoever.