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

Re: Seg. fault with meta backend (ITS#1953)



Xavier.Redon@eudil.fr wrote:
> Full_Name: Xavier Redon
> Version: 2.1.3
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (193.48.57.37)
> 
> 
> When trying the following backend configuration
> 
> database       meta
> suffix         "o=eudil,c=fr"
> uri            "ldap://ldap.eudil.fr/ou=People,o=eudil,c=fr";
> uri            "ldap://ldap.eudil.fr/ou=Group,o=eudil,c=fr";
> uri            "ldap://ldap.eudil.fr/ou=Register,o=eudil,c=fr";
> lastmod        off
> 
> and the request :
> 
> ldapsearch -x -h douaisis.eudil.fr -b "o=eudil,c=fr" "cn=rex"
> 
> a segmentation fault occurs. Seems to be a memory allocation bug.
> An example of the seg. fault under gdb:
> 
> #0  0x400ae4e7 in malloc () from /lib/libc.so.6
> #1  0x400ae074 in malloc () from /lib/libc.so.6
> #2  0x400a7152 in open_memstream () from /lib/libc.so.6
> #3  0x4010c8ce in vsyslog () from /lib/libc.so.6
> #4  0x4010c825 in syslog () from /lib/libc.so.6
> #5  0x0805b0b0 in send_search_result (conn=0x4015db8c, op=0x80fdd40, err=1,
>     matched=0x80b9120 "", text=0x80b9120 "", refs=0x0, ctrls=0x0, nentries=0)
>     at result.c:602
> #6  0x0807b936 in meta_back_search (be=0x80dccc0, conn=0x4015db8c,
>     op=0x80fdd40, base=0xbf5ffa28, nbase=0xbf5ffa30, scope=2, deref=0,
>     slimit=0, tlimit=0, filter=0x8100068, filterstr=0xbf5ffa18, attrs=0x0,
>     attrsonly=0) at search.c:438
> #7  0x0805063d in do_search (conn=0x4015db8c, op=0x80fdd40) at search.c:320
> #8  0x0804f100 in connection_operation (arg_v=0x80fddc0) at connection.c:977
> #9  0x0808e05f in ldap_int_thread_pool_wrapper (xpool=0x80c6d30) at tpool.c:401
> #10 0x400320ba in pthread_start_thread () from /lib/libpthread.so.0
> #11 0x40032101 in pthread_start_thread_event () from /lib/libpthread.so.0
> 
> You may try to reproduce the bug using the config. above our ldap server is
> public.
> 
> Xavier
> 

I'll look at this; the problem, on my build, occurs when
normalizing an apparently fine DN; actually, it occurs
during a malloc, so the corruption should be way before.

Pierangelo.