strangeness on Redhat Linux

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

Well, I'm toying with my changes on Redhat Linux, but I'm seeing lots of
very odd faults.  They appear unrelated to my changes (I will confirm
this next).

% uname -a
Linux ldap-1.boolean.net 2.0.36 #1 Tue Oct 13 22:17:11 EDT 1998 i686 unknown
% gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.7.2.3/specs
gcc version 2.7.2.3
% ldd ../servers/slapd/slapd
        libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x40004000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x4000a000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x40039000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x40047000)
        libc.so.6 => /lib/libc.so.6 (0x40054000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)

% ls -l /lib/libc*
-rwxr-xr-x   1 root     root      3070220 Oct 13 05:27 libc-2.0.7.so
lrwxrwxrwx   1 root     root           13 Dec 31 06:30 libc.so.6 -> libc-2.0.7.s

% ./scripts/test008-concurrency
[...]
(blows up)

% gdb ../servers/slapd/slapd core
> where
#0  0x400c7767 in __sched_yield ()
#1  0x806058c in ldap_pvt_thread_yield () at thr_posix.c:123
#2  0x80585fb in ldbm_back_search (be=0x8073670, conn=0x807bf10, 
    op=0x40200d90, base=0x80f31b0 "O=UNIVERSITY OF MICHIGAN,C=US", scope=2, 
    deref=0, slimit=499, tlimit=3600, filter=0x80f3638, 
    filterstr=0x80f3680 "(cn=BJORN JENSEN)", attrs=0x80f3698, attrsonly=0)
    at search.c:293
#3  0x804c777 in do_search (conn=0x807bf10, op=0x40200d90) at search.c:149
#4  0x804be51 in connection_operation (arg_v=0x40200650) at connection.c:480
#5  0x40056357 in pthread_start_thread (arg=0xbf1ffea4) at manager.c:192

% ./scripts/test008-concurrency
[...]
(blows up)

% gdb ../servers/slapd/slapd core
(gdb) where
#0  0x400cd42d in __libc_fsync ()
#1  0x40058d48 in fsync (fd=22) at wrapsyscall.c:80
#2  0x40013116 in gdbm_sync ()
#3  0x805b0a5 in ldbm_cache_store (db=0x8079498, key={dptr = 0xbf3ffcd8 "=3", 
      dsize = 3}, data={dptr = 0x80f47f8 "\b", dsize = 40}, flags=-2147483647)
    at dbcache.c:214
#4  0x805d022 in idl_store (be=0x8073670, db=0x8079498, key={
      dptr = 0xbf3ffcd8 "=3", dsize = 3}, idl=0x80f47f8) at idl.c:217
#5  0x805d2bc in idl_insert_key (be=0x8073670, db=0x8079498, key={
      dptr = 0xbf3ffcd8 "=3", dsize = 3}, id=20) at idl.c:361
#6  0x805c5e1 in id2children_add (be=0x8073670, p=0x80f48c8, e=0x80f5038)
    at id2children.c:41
#7  0x8058d7f in ldbm_back_add (be=0x8073670, conn=0x807be5c, op=0x80bd408, 
    e=0x80f5038) at add.c:166
#8  0x804d851 in do_add (conn=0x807be5c, op=0x80bd408) at add.c:128
#9  0x804bdfd in connection_operation (arg_v=0x80bcc08) at connection.c:457
#10 0x40056357 in pthread_start_thread (arg=0xbf3ffea4) at manager.c:192


PS: I see similiar problems with DB2.  I switched to GDBM for ease of debugging.