[Date Prev][Date Next]
Re: connection_close() called with c_struct_state == SLAP_C_INACTIVE
Howard Chu wrote:
Pierangelo Masarati wrote:
Here's something similar, although in a different place, happening on
Solaris 9 with a hacked version of 2.3.30 (hacking is basically not in
this file; I only imported fixes to ITS#4769 and ITS#4771) when I shut
it down hitting CTRL-C.
Recently, with 2.3.30, I got an assertion during shutdown because
connection_close() was called with c_struct_state ==
SLAP_C_INACTIVE. Unfortunately I couldn't save neither the core nor
a backtrace. I guess the fix in connection.c 1.375 -> 1.376 should
be backported to re23, but the code changed since then, and I fear I
could break something. Is this correct?
Pretty sure that change is already incorporated in 2.3.30's connection.c.
./bin/slapd-sysnet-0.3.34-beta.2-gprof -f slapd.conf -h ldap://:9020 -s0 -d0
pthreads: using profiling hooks for gprof
^CAssertion failed: c->c_struct_state == SLAP_C_USED, file connection.c,
Abort (core dumped)
Note: connection.c:811 corresponds to connection.c:809 in 2.3.30 code.
#0 0x7fffffff7e7a754c in _lwp_kill () from /usr/lib/64/libc.so.1
#1 0x7fffffff7e753e7c in raise () from /usr/lib/64/libc.so.1
#2 0x7fffffff7e73d274 in abort () from /usr/lib/64/libc.so.1
#3 0x7fffffff7e73d56c in _assert () from /usr/lib/64/libc.so.1
#4 0x0000000100033834 in connection_closing (c=0x100eebb00,
why=0x1001d0498 "slapd shutdown") at connection.c:811
#5 0x0000000100031c2c in connections_shutdown () at connection.c:212
#6 0x000000010002fd10 in slapd_daemon_task (ptr=0x100343b10) at
#7 0x7fffffff7f800d00 in wrapper_routine (data=0xffffffff7ffff768)
#8 0x7fffffff7df17478 in _lwp_start ()
#9 0x7fffffff7df17478 in _lwp_start ()
What I see is that c->c_struct_state is 1 (SLAP_C_UNUSED) instead of 2
Any thoughts? I have access to the binary and the core (sort of: it's
more than 2000 km apart on a not fast enough connection to download it,
and the firewall will shut the connection down shortly...).
Apparently, connections_shutdown() should lock the connection's c_mutex
before testing c_struct_state, and not after, right?