Re: Slapadd with bdb backend segfaults

[Matthew Backes <lucca@csun.edu>]

Is the ldif in question line-wrapped?  IIRC, the ldif parser uses \r\r 
to overwrite the \n[space] to implement logical line unwrapping...

Matthew Backes
lucca@csun.edu

On Feb 16, 2004, at 4:07 PM, Howard Chu wrote:

> 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
> >
> >
> > -----Original Message-----
> > From: Howard Chu [mailto:hyc@highlandsun.com]
> > Sent: Friday, February 13, 2004 5:30 PM
> > To: 'Armbrust, Daniel C.'; openldap-bugs@OpenLDAP.org
> > Subject: RE: Slapadd with bdb backend segfaults
> >
> > Your backtrace is useless because there are no debug symbols
> > present. Please
> > recompile the OpenLDAP servers/slapd directory with debugging
> > enabled and
> > optimization disabled
> > 	make clean
> > 	make AC_CFLAGS=-g
> > and don't bother doing "make install", just run the binaries
> > where they were
> > built.
> >
> > 	gdb servers/slapd/tools/slapadd
> > 	run -f foo -l ../../source/t22/ldif/Table22.ldif -c
> >
> > If gdb complains that slapadd is not an executable file,
> > that's probably
> > because it is a libtool wrapper script; then the real
> > executable is below:
> > 	gdb servers/slapd/tools/.libs/slapadd
> >
> >   -- Howard Chu
> >   Chief Architect, Symas Corp.       Director, Highland Sun
> >   http://www.symas.com               http://highlandsun.com/hyc
> >   Symas: Premier OpenSource Development and Support