[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: OpenLDAP client cores when ldap server goes away...
Please direct OpenLDAP Software use questions, including questions
regarding use of OpenLDAP provided libraries, to the software
list. This list is reserved for discussions regarding the
development of OpenLDAP Software itself.
I also note that the answer to your question can be
found with a little googling.
http://www.google.com/search?q=site%3Awww.openldap.org+SIGPIPE
Thanks, Kurt
At 08:07 AM 2002-09-05, David Sloat wrote:
>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