RE: Slapadd with bdb backend segfaults

["Howard Chu" <hyc@highlandsun.com>]

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

> -----Original Message-----
> From: owner-openldap-bugs@OpenLDAP.org
> [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of Armbrust, Daniel C.

> I've have now noted that if I load ldap files that are in
> order, instead of out of order, I do not get this segfault.
>
> Someone else who had an issue like this was advised that
> slapadd was supposed to handle out of order entries - and
> maybe it was running out of memory?  My slapadd process never
> uses much memory.  Is there a limit on it that I can configure?
>
> I also saw this message
> http://www.openldap.org/lists/openldap-devel/200302/msg00055.html
>
> If I download the current source from cvs will I get this change?

This message was posted in February 2003, nearly a year ago. The changes
described there were released in OpenLDAP 2.1 long ago and have always been
part of OpenLDAP 2.2.

> -----Original Message-----
> From: owner-openldap-bugs@OpenLDAP.org
> [mailto:owner-openldap-bugs@OpenLDAP.org] On Behalf Of
> Armbrust, Daniel C.
>
> Here is my slapadd command:
> /usr/local/openldap-2.2.5/sbin/slapadd -f foo -l
> ../../source/t22/ldif/Table22.ldif -c -d1

> >>> dnPrettyNormal:
> <link=targetLink,targetConcept=242.90,sourceConcept=2530,assoc
iation=mapsTo,dc=relations,codingScheme=Table22,dc=codingSchemes,service=Tabl
e22,dc=Mayo,> dc=edu>
> Segmentation fault