RE: Slapadd with bdb backend segfaults

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

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?

Do you think it would help - if this segfault is indeed caused by out of order entries?

Thanks, 

Dan


-----Original Message-----
From: owner-openldap-bugs@OpenLDAP.org [mailto:owner-openldap-bugs@OpenLDAP.org] On Behalf Of Armbrust, Daniel C.
Sent: Wednesday, February 11, 2004 9:43 AM
To: openldap-bugs@OpenLDAP.org
Subject: RE: Slapadd with bdb backend segfaults

Here are portions of my slapd.conf file (if I left out something important, let me know the rest is just permissions and schema includes, etc - this is all I have related to the database config):

database        bdb
suffix          "service=Table22,dc=Mayo,dc=edu"
directory       /home/armbrust/dbT22/

Here is my DB_CONFIG file:

set_flags       DB_TXN_NOSYNC
set_flags       DB_LOG_AUTOREMOVE
set_cachesize   0       524288000       1
set_lg_bsize    2097152

Here is my slapadd command:
/usr/local/openldap-2.2.5/sbin/slapadd -f foo -l ../../source/t22/ldif/Table22.ldif -c -d1

Here is the last bit of output I got before it segfaulted:

=> index_entry_add( 19656, "targetConcept=242.90,sourceConcept=2530,association=mapsTo,dc=relations,codingScheme=Table22,dc=codingSchemes,service=Table22,dc=Mayo,dc=edu" )
=> key_change(ADD,4cc8)
<= key_change 0
=> key_change(ADD,4cc8)
<= key_change 0
=> key_change(ADD,4cc8)
<= key_change 0
=> key_change(ADD,4cc8)
<= key_change 0
=> key_change(ADD,4cc8)
<= key_change 0
<= index_entry_add( 19656, "targetConcept=242.90,sourceConcept=2530,association=mapsTo,dc=relations,codingScheme=Table22,dc=codingSchemes,service=Table22,dc=Mayo,dc=edu" ) success
=> str2entry: "dn: link=targetLink,targetConcept=242.90,sourceConcept=2530,association=mapsTo,dc=relations,codingScheme=Table22,dc=codingSchemes,service=Table22,dc=Mayo,dc=edu
aliasedObjectName: conceptCode=242.90,dc=Concepts,codingScheme=Table22,dc=codingSchemes,service=Table22,dc=Mayo,dc=edu
objectClass: targetLink
objectClass: alias
link: targetLink
"
>>> dnPrettyNormal: <link=targetLink,targetConcept=242.90,sourceConcept=2530,association=mapsTo,dc=relations,codingScheme=Table22,dc=codingSchemes,service=Table22,dc=Mayo,dc=edu>
Segmentation fault 


And here is my attempt at generating a backtrace (I may be doing this wrong - please advise)

I attached gdb to my slapadd process like this:
gdb foo 23480

It spit out some stuff, and gave me a prompt, where I pressed c:

(gdb) c
Continuing.
 
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1074034560 (LWP 23480)]
0x42074230 in _int_malloc () from /lib/tls/libc.so.6
(gdb) backtrace
#0  0x42074230 in _int_malloc () from /lib/tls/libc.so.6
#1  0x4207360b in malloc () from /lib/tls/libc.so.6
#2  0x080beb1d in strcpy ()
#3  0x080bf196 in strcpy ()
#4  0x080ad3ba in strcpy ()
#5  0x080acc8f in strcpy ()
#6  0x080ac529 in strcpy ()
#7  0x080664ee in strcpy ()
#8  0x0806484f in strcpy ()
#9  0x0804a809 in strcpy ()
#10 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6


Does this shed any light on what is going on to you?

Thanks, 

Dan