Memory corruption in connection-handling code
erthink opened this issue · 0 comments
erthink commented
This bug was inherited from OpenLDAP, related to #143.
Due the race condition in the connection-handling code a statistical counters could be updated even the connection was closed and the corresponding memory region allocated for counters is freed.
(gdb) bt
#0 0x00007fa1f30bb428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1 0x00007fa1f30bd02a in __GI_abort () at abort.c:89
#2 0x00007fa1f30b3bd7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x5da49d "ldap: rc == 0", file=file@entry=0x5da492 "posix.c", line=line@entry=370,
function=function@entry=0x5daab0 <__FUNCTION__.4382> "ldap_pvt_thread_mutex_lock") at assert.c:92
#3 0x00007fa1f30b3c82 in __GI___assert_fail (assertion=0x5da49d "ldap: rc == 0", file=0x5da492 "posix.c", line=370, function=0x5daab0 <__FUNCTION__.4382> "ldap_pvt_thread_mutex_lock") at assert.c:101
#4 0x000000000050df3c in __ldap_assert_fail (assertion=0x5da49d "ldap: rc == 0", file=0x5da492 "posix.c", line=370, function=0x5daab0 <__FUNCTION__.4382> "ldap_pvt_thread_mutex_lock") at globals.c:194
#5 0x00000000004b3959 in ldap_pvt_thread_mutex_lock (mutex=0x7fa1e0002a08) at posix.c:370
#6 0x00000000004f7378 in slap_send_search_entry (op=0x7fa1e67fc350, rs=0x7fa1e67fc130) at result.c:1456
#7 0x00000000004f07c6 in syncprov_sendresp (mode=2, so=0x7fa1e0103890, ri=0x7fa1e010f5c0, op=0x7fa1e67fc350) at syncprov.c:1139
#8 syncprov_playback_locked (so=0x7fa1e0103890, op=0x7fa1e67fc350) at syncprov.c:1174
#9 syncprov_playback_dequeue (ctx=<optimized out>, arg=0x7fa1e0103890) at syncprov.c:1231
#10 0x000000000043b951 in ldap_int_thread_pool_wrapper (xpool=0x1c40180) at tpool.c:982
#11 0x00007fa1f34576ba in start_thread (arg=0x7fa1e67fd700) at pthread_create.c:333
#12 0x00007fa1f318d41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109