[Date Prev][Date Next] [Chronological] [Thread] [Top]

OpenLDAP client cores when ldap server goes away...



Title: OpenLDAP client cores when ldap server goes away...

Hi -

I've been running into the following and was wondering if anyone has seen
something similar - or has a suggestion.  Just fyi... I'm using
OpenLDAP version 2.0.23.

I have a process start up and initiate an ldap connection (including a bind)
to an ldap server (just happens to be OpenLDAP slapd).  After I know the
bind has occurred and was successful, I kill the slapd process on the remote
server.  I then begin to issue ldap_search (async) calls to the ldap server.

Two peculiar things happen...

The first ldap_search comes back saying that it was successful (returns
a valid message id).  The next ldap_search call causes the process to
core (the meaningful part of the stack is below).  I'm assuming that the
situation is that the ldap server went away without formally closing the
connection to the client(s).  So, the client still thinks it has a valid
connection during the ber_flush and beyond.  Should there be a place at
some point in this code path that an actual status check of the connection
is made?  Is this something that has been discussed earlier (if so, could you
point me at the discussion)?

Here's the stack (from the second ldap_search call):

Program received signal SIGPIPE, Broken pipe.
0x482ee921 in _syscall_sys_write ()
(gdb) where
#0  0x482ee921 in _syscall_sys_write ()
#1  0x482b15c2 in sb_stream_write (sbiod=0x8092df8, buf=0x80a1338, len=1036)
    at sockbuf.c:544
#2  0x482b1905 in sb_rdahead_write (sbiod=0x8092e10, buf=0x80a1338, len=1036)
    at sockbuf.c:675
#3  0x482b1d35 in sb_debug_write (sbiod=0x80965a8, buf=0x80a1338, len=1036)
    at sockbuf.c:838
#4  0x482b14e1 in ber_int_sb_write (sb=0x8097a40, buf=0x80a1338, len=1036)
    at sockbuf.c:428
#5  0x482af61d in ber_flush (sb=0x8097a40, ber=0x8095b50, freeit=0) at io.c:229
#6  0x482c5aa0 in ldap_send_server_request (ld=0x80978f0, ber=0x8095b50,
    msgid=3, parentreq=0x0, srvlist=0x0, lc=0x0, bind=0x0) at request.c:202
#7  0x482c58ee in ldap_send_initial_request (ld=0x80978f0, msgtype=99,
    dn=0x808416c "ou=People,dc=f5,dc=com", ber=0x8095b50) at request.c:110
#8  0x482bc96c in ldap_search (ld=0x80978f0,
    base=0x808416c "ou=People,dc=f5,dc=com", scope=2,
    filter=0x80467fc "(&(userCertificate=\\30\\82\\03\\89\\30\\82\\02\\f2\\a0\\03\\02\\01\\02\\02\\01\\01\\30\\0d\\06\\09\\2a\\86\\48\\86\\f7\\0d\\01\\01\\04\\05\\00\\30\\81\\81\\31\\0b\\30\\09\\06\\03\\55\\04\\06\\13\\02\\55\\53\\31\\13\\30\\11\\06\\03\\55\\04\\08\\13\\0a\\57\\61\\"..., attrs=0x8046764, attrsonly=0)

    at search.c:240

Thank you,

- Dave Sloat