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

Re: Segmentation fault on 2.1.13



> Today at 9:01am, Frank Swasey wrote:
>
>> [08:31 AM root@tldap root]# time slapadd -f newldap.ldif
>> No databases found in config file
>
> Doh!  Now that I've stared at it and stared at it and run it under
> gdb... -f is the wrong flag.... Silly me!
>
> Anyway....
>
> # gdp /usr/sbin/slapadd
> (gdb) break main
> (gdb) run -v -d -1 -l newldap.ldif
> (gdb) step
> ....
> <= index_entry_add( 32,
> "uvmEduAlias=Alpha.Zeta,ou=Aliases,dc=uvm,dc=edu" ) success
> => dn2id_add( "uvmEduAlias=alpha.zeta,ou=aliases,dc=uvm,dc=edu", 32 ) =>
> ldbm_cache_open( "dn2id.dbb", 73, 600 )
> <= ldbm_cache_open (cache 2)
> <= dn2id_add 0
> added: "uvmEduAlias=Alpha.Zeta,ou=Aliases,dc=uvm,dc=edu" (00000020) =>
> str2entry
>>>> dnPrettyNormal: <uvmEduAlias=altbreak,ou=Aliases,dc=uvm,dc=edu>
> <<< dnPrettyNormal: <uvmEduAlias=altbreak,ou=Aliases,dc=uvm,dc=edu>,
> <uvmEduAlias=altbreak,ou=aliases,dc=uvm,dc=edu>
>>>> dnPretty: <cn=Manager,dc=uvm,dc=edu>
> <<< dnPretty: <cn=Manager,dc=uvm,dc=edu>
>>>> dnPretty: <cn=Manager,dc=uvm,dc=edu>
> <<< dnPretty: <cn=Manager,dc=uvm,dc=edu>
> <= str2entry(uvmEduAlias=altbreak,ou=Aliases,dc=uvm,dc=edu) -> 0x8238ca8
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x4207a4cb in strlen () from /lib/i686/libc.so.6
> (gdb) backtrace
> #0  0x4207a4cb in strlen () from /lib/i686/libc.so.6
> #1  0x4204a390 in vfprintf () from /lib/i686/libc.so.6
> #2  0x4206a3e4 in vsnprintf () from /lib/i686/libc.so.6
> #3  0x42052404 in snprintf () from /lib/i686/libc.so.6
> #4  0x08073532 in entry_schema_check ()
> #5  0x080652af in main ()
> #6  0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
> (gdb)
>
> What else do you want?

the crash is due to a bug that was fixed last night; however,
it is related to generating an error message, which says the
related entry is invalid, because it either has an attributeType
or a value in its rdn that is not present in the entry itself.

Fix your ldif and retry; you better get the fix first,
as suggested by Howard

http://www.openldap.org/lists/openldap-bugs/200302/msg00118.html

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it