Re: slapadd segmentation fault (2.1.22/bdb 4.1.25)

[Allan Streib <astreib@indiana.edu>]

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?

Allan

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.