Re: [Ldapdns-users] ICMP Destination Unreachable, Port 53 Unreachable

[Mark B. <ma...@ib...>]

On some further investigation I find that setting THREADS=128 and
HANDLERS=1 ldapdns does not crash out. If I set it to THREADS=1 and
HANDLERS=3 it will crash like before.

After watching this setting the GDB for a while, I did not see any
threads crash so for the time being THREADS=128 and HANDLERS=1 is my
solution.

Mark


On Mon, 2006-03-13 at 17:39 +0800, Mark Burring wrote:
> I apologise for the delay on this.
> 
> This is the output of GDB
> 
> Core was generated by `/bin/ldapdns'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /usr/local/lib/libldap_r-2.3.so.0...done.
> Loaded symbols for /usr/local/lib/libldap_r-2.3.so.0
> Reading symbols from /usr/local/lib/liblber-2.3.so.0...done.
> Loaded symbols for /usr/local/lib/liblber-2.3.so.0
> Reading symbols from /lib/libpthread.so.0...done.
> Loaded symbols for /lib/libpthread.so.0
> Reading symbols from /lib/libc.so.6...done.
> Loaded symbols for /lib/libc.so.6
> Reading symbols from /lib/libresolv.so.2...done.
> Loaded symbols for /lib/libresolv.so.2
> Reading symbols from /lib/ld-linux.so.2...done.
> Loaded symbols for /lib/ld-linux.so.2
> #0  ldap_parse_result (ld=0x807a010, r=0x8085700, errcodep=0xbf7ffa90,
> matcheddnp=0x0, errmsgp=0x0, referralsp=0x0, serverctrls=0x0, freeit=0)
>     at error.c:282
> 282             if ((lm->lm_msgtype == LDAP_RES_SEARCH_ENTRY) ||
> 
> 
> (gdb) backtrace
> #0  ldap_parse_result (ld=0x807a010, r=0x8085700, errcodep=0xbf7ffa90,
> matcheddnp=0x0, errmsgp=0x0, referralsp=0x0, serverctrls=0x0, freeit=0)
>     at error.c:282
> #1  0x0804e49d in ldapdns_process_zonesearch (c=0x80602b8) at
> engine.c:1612
> #2  0x080525a3 in ldap_msgwait_loop (c_void=0x805ec60) at engine.c:3156
> #3  0x40063e51 in pthread_start_thread () from /lib/libpthread.so.0
> #4  0x4018792a in clone () from /lib/libc.so.6
> 
> 
> Since I'm relatively new to GDB, please let me know if there is any
> other useful output.
> 
> Since it appears to be crashing in the middle of an LDAP call I will
> list out my relevant system stats here:
> 
> Debian Sarge
> openldap-2.3.13
> gcc version 3.3.5 (Debian 1:3.3.5-13)
> 
> 
> On Sun, 2006-02-05 at 21:56 -0500, Mrs. Brisby wrote:
> > On Tue, 2006-01-31 at 13:52 +0800, Mark Burring wrote:
> > > Greetings,
> > > 
> > > I am using ldapdns-2.05 with openldap 2.3.13 and have found that
> > > occasionally the server will return a port unreachable for udp port 53.
> > > I am trying to discover if this is normal behaviour as it has not caused
> > > and serious issues yet but a minor issue did come up because of this.
> > 
> > I would seriously consider setting firewall rules up to block outgoing
> > ICMP port unreachable messages, in general, because it'll cause dns
> > lookups to fail instead of retry.
> > 
> > If LDAPDNS crashes (and it can for lots of reasons, I'll go into that in
> > a moment), then it will be restarted if you're using supervise or
> > running it from init (which you SHOULD be doing for anything critical).
> > 
> > Now on my systems, OpenLDAP has a memory leak that I observe. I use
> > softlimit so the process either has malloc() fail or receives SEGV.
> > Either way, it's not exploitable by any means, and because it restarts
> > immediately, nothing is "lost" - except a potential retry.
> > 
> > It also happens infrequently enough that I'm not worried about
> > upgrading- if I were, I probably would increase the memory limit first,
> > or do more work on LDAPDNS3 :)
> > 
> > > There seems to be no pattern, it will send this message at random for
> > > any type of query.
> > 
> > You received port unreachable because LDAPDNS died. Simple as that.
> > 
> > Based on where your traces are, it occurs in a recvfrom() which either
> > points outside of usable memory, or the kernel is doing it to you during
> > the call. Or another thread is crashing, and you don't notice.
> > 
> > If you really want to find out, set HANDLERS=1 THREADS=128. Also, build
> > LDAPDNS with debug symbols and configure your system to dump LDAPDNS's
> > core so you can look at it later with gdb. It'll probably make things
> > much easier to spot, because you can look at other threads....
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Ldapdns-users mailing list
> Lda...@li...
> https://lists.sourceforge.net/lists/listinfo/ldapdns-users