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

Re: slapadd segmentation fault (2.1.22/bdb 4.1.25)

Re-ordering my ldif file (produced by slapcat) into superior order avoids this problem. My speculation is that slapadd maintains some kind of forward reference when it encounters a "child" entry before encountering its "parent", and that with large ldif files (about 20 million lines in this case, representing about 1.2 million entries, with up to 4 levels of "depth" from the root entry to the leaf entries) perhaps it is overflowing something.

I do have another question -- the data load produced over 8 GB of BDB log files, and db_archive did not say that any were removable until after slapadd finished. Is this a result of my "DB_TXN_NOSYNC" option in DB_CONFIG, or is that normal?


On Wednesday, October 15, 2003, at 03:32 PM, Allan Streib wrote:

Trying to load an ldif file into a new directory using slapadd, and it chugs along for a while and then dies with a segmentation fault. With full debugging turned on, the last messages are:

=> bdb_tool_entry_put( -1, "iuEduUPID=ddd7c2b4ed319896d2659777dab297c9,ou=people,dc=iu,dc=edu" )
=> bdb_dn2id( "iuEduUPID=ddd7c2b4ed319896d2659777dab297c9,ou=people,dc=iu,dc=edu" )
<= bdb_dn2id: got id=0x00001767
=> entry_encode(0x00000041): ¡ZX
Segmentation fault

My DB_CONFIG contains:

set_flags       DB_TXN_NOSYNC
set_lg_dir      /var/db/bdb
set_lg_max      104857600
set_lg_bsize    26214400
set_cachesize   0 1048576 0

OS is Red Hat Enterprise Linux ES release 2.1 (Panama). I'll be happy to try to provide more info if necessary, but thought that might be enough to help focus the effort. Anyone seen anything similar to this? Searched ITS and archives and did not find anything that looked real likely.