RE: Slapadd with bdb backend segfaults

["Armbrust, Daniel C." <Armbrust.Daniel@mayo.edu>]

I was wondering about those... But when I looked at the ldif file there had already been a bunch of others earlier in the file that it ran fine on (I'm assuming it reads the file top down).

If they are the cause of the segfault, I guess the bug focus needs to shift to slapcat (from an ldbm backend) then, since that is what created the ldif file.

Files that we have created from other ways (like export from softerras browser) do not have these carriage returns, nor did the source that we loaded.

Thanks, 

Dan


-----Original Message-----
From: Howard Chu [mailto:hyc@highlandsun.com] 
Sent: Monday, February 16, 2004 6:07 PM
To: 'Armbrust, Daniel C.'; openldap-bugs@OpenLDAP.org
Subject: RE: Slapadd with bdb backend segfaults

This trace shows a DN with a bunch of embedded carriage-return characters. It
appears that your input LDIF file is corrupt. See the ldif.5 manpage if
you're unsure about the proper format. Ordinarily control characters would
need to be escaped when used legitimately in a DN; in this case they do not
appear to legitimately belong there at all.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: owner-openldap-bugs@OpenLDAP.org
> [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of Armbrust, Daniel
> C.
> Sent: Monday, February 16, 2004 6:29 AM
> To: openldap-bugs@OpenLDAP.org
> Subject: RE: Slapadd with bdb backend segfaults
>
>
> Thanks, I was wondering what I was doing wrong with the
> debugger.  I'm (obviously) not a c programmer.
>
> Here is a much more useful looking stack trace:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1074034560 (LWP 23136)]
> 0x42074230 in _int_malloc () from /lib/tls/libc.so.6
> (gdb) bt
> #0  0x42074230 in _int_malloc () from /lib/tls/libc.so.6
> #1  0x4207360b in malloc () from /lib/tls/libc.so.6
> #2  0x080e1ec5 in ber_memalloc_x (s=4, ctx=0x0) at memory.c:232
> #3  0x080e2772 in ber_strndup_x (s=0x83d03b9 "HL7,dc=org",
> l=3, ctx=0x0) at memory.c:700
> #4  0x080c9569 in str2strval (str=0x83d03b9 "HL7,dc=org",
> stoplen=10, val=0xbfffe600, next=0xbfffe628, flags=0,
>     retFlags=0xbfffe614, ctx=0x0) at getdn.c:1555
> #5  0x080c8de9 in ldap_bv2rdn_x (bv=0xbfffe670,
> rdn=0xbfffe71c, n_in=0xbfffe72c, flags=0, ctx=0x0) at getdn.c:1274
> #6  0x080c81b2 in ldap_bv2dn_x (bv=0xbfffe7d0, dn=0xbfffe764,
> flags=0, ctx=0x0) at getdn.c:799
> #7  0x0806f17d in dnPrettyNormal (syntax=0x0, val=0xbfffe7d0,
> pretty=0x81ea0ec, normal=0x81ea0f4, ctx=0x0) at dn.c:579
> #8  0x0806c8e1 in str2entry (
>     s=0x81ea4f0 "dn:
> link=targetLink,targetConcept=C1126693,sourceConcept=C0783574,
> association=\r\rconsistsOf,dc=relations,codingScheme=RXNorm,dc
> =codingSchemes,service=RXNorm,d\r\rc=HL7,dc=org") at entry.c:150
> #9  0x0804a949 in main (argc=5, argv=0xbfffeaa4) at slapadd.c:107
> #10 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
>
>
> Dan