#805981 slapd crashes under not yet understood circumstances during a connection failure in ADS

Package:
slapd
Source:
openldap
Description:
OpenLDAP server (slapd)
Submitter:
Simon Bin
Date:
2015-12-03 05:21:04 UTC
Severity:
important
#805981#5
Date:
2015-11-24 14:09:52 UTC
From:
To:
Dear Maintainer,

   * What led up to the situation?

Our ldap Admin reports that he was using Apache Directory Studio
copying a user record when slapd crashed. We had two crashes today
already.

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

So far we weren't able to isolate and properly reproduce the issue but
we could gather the following stacktrace from gdb.

Program received signal SIGPIPE, Broken pipe.
(gdb) bt full
#0  0x00007f652b626a7d in write () at ../sysdeps/unix/syscall-template.S:81
No locals.
#1  0x00007f652d0370f8 in ?? () from /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2
No symbol table info available.
#2  0x00007f652c2e45d6 in ?? () from /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28
No symbol table info available.
#3  0x00007f652c2df551 in ?? () from /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28
No symbol table info available.
#4  0x00007f652c2ffa98 in gnutls_alert_send () from /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28
No symbol table info available.
#5  0x00007f652c2e1389 in gnutls_bye () from /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28
No symbol table info available.
#6  0x00007f652d276822 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
No symbol table info available.
#7  0x00007f652d037fe2 in ber_int_sb_close () from /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2
No symbol table info available.
#8  0x00007f652d0380d4 in ber_sockbuf_free () from /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2
No symbol table info available.
#9  0x00007f652d6e72c8 in slapd_remove (s=70, sb=0x7f650811f530, wasactive=<optimized out>, wake=0, locked=<optimized out>) at ../../../../servers/slapd/daemon.c:908
        waswriter = <optimized out>
        wasreader = <optimized out>
        id = 0
        __PRETTY_FUNCTION__ = "slapd_remove"
#10 0x00007f652d6ec116 in connection_destroy (c=<optimized out>) at ../../../../servers/slapd/connection.c:705
        connid = 1080
        close_reason = 0x7f652d784740 <conn_lost_str> "connection lost"
        sb = 0x7f650811f530
        sd = 70
#11 connection_close (c=0x7f652e599230) at ../../../../servers/slapd/connection.c:855
No locals.
#12 0x00007f652d6ed195 in connection_read (cri=<optimized out>, s=<optimized out>) at ../../../../servers/slapd/connection.c:1477
        c = 0x7f652e599230
#13 connection_read_thread (ctx=0x46, argv=0x7f65001bba10) at ../../../../servers/slapd/connection.c:1284
No locals.
#14 0x00007f652d24dc62 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
No symbol table info available.
#15 0x00007f652b6200a4 in start_thread (arg=0x7f6515ffc700) at pthread_create.c:309
        __res = <optimized out>
        pd = 0x7f6515ffc700
        now = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140072137508608, 4154731789372546579, 0, 140072530411616, 1, 140072137508608, -4079494405578105325, -4079482495802221037}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0},
            data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#16 0x00007f652b35504d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
No locals.
(gdb) q

   * What outcome did you expect instead?

slapd should not crash during disconnect.

I appreciate any input.

#805981#10
Date:
2015-11-24 15:48:28 UTC
From:
To:
Hi, thanks for the report.

Indeed.

It's hard to tell without symbol information, but at a glance this
doesn't look like any crash I'm already aware of.

Would you please install slapd-dbg, libldap-2.4-2-dbg, and
libgnutls28-dbg, and obtain the stack trace again? I can't promise that
will lead us to the problem, but it will certainly help.

Thank you,

Ryan