ando@sys-net.it wrote:
Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando
There is code that accesses c_conn_state and c_struct_state while not adequately mutex-protected. In most cases, this code basically consists in assertions, so we risk a core dump because of an assertion on non-mutex protected data. This is the case (as happened to me) of connection_next().
I have a fix for the case I noticed, with two unhandled asserts (marked with a FIXME) because I'm not sure whether it's worth to add extra mutexes just to be able to safely assert, or remove assertions.
Committing the fix; there might be more. Please check.
I noticed this while testing concurrency for re24; here is the relevant portion of the core dump:
(gdb) bt #0 0x00483402 in __kernel_vsyscall () #1 0x00c9ad20 in raise () from /lib/libc.so.6 #2 0x00c9c631 in abort () from /lib/libc.so.6 #3 0x00c9416b in __assert_fail () from /lib/libc.so.6 #4 0x08084b80 in connection_next (c=0x0, index=0xb62e3d8c) at ../../../ldap-2.4-src/servers/slapd/connection.c:871 #5 0x081a810c in monitor_subsys_conn_update (op=0x8a145f0, rs=0xb62e5128, e=0x896632c) at ../../../../ldap-2.4-src/servers/slapd/back-monitor/conn.c:230
<snip>
(gdb) f 4 #4 0x08084b80 in connection_next (c=0x0, index=0xb62e3d8c) at ../../../ldap-2.4-src/servers/slapd/connection.c:871 (gdb) p connections[*index] $1 = {c_struct_state = 2, c_conn_state = 1, c_conn_idx = 19, c_sd = 19, <snip>
Cheers, p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------