Issue 5176 - Segmentation Fault in test001-slapadd
Summary: Segmentation Fault in test001-slapadd
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-08 14:33 UTC by openldap@consotec.de
Modified: 2014-08-01 21:06 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description openldap@consotec.de 2007-10-08 14:33:07 UTC
Full_Name: Mark
Version: 2.3.38
OS: Suse Linux 10.01
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (84.128.87.178)


** Problem 
test001-slapdadd fails with segmentation fault.

** Environment
Suse Linux 10.1
Berkly DB  4.6.21
Openldap   2.3.38

** Configuration of ldap
configure --prefix=/usr --enable-debug

** Shared Library depency
        libdb-4.6.so => /usr/lib/libdb-4.6.so (0x40028000)
        libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x40169000)
        libdl.so.2 => /lib/libdl.so.2 (0x40182000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x40185000)
        libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40197000)
        libc.so.6 => /lib/i686/libc.so.6 (0x401e9000)

** StackTrace

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 32771 (LWP 28247)]
0x400bd3bd in __lock_get_internal (lt=0x8215ae8, sh_locker=0x7, flags=0,
obj=0x82168d4, lock_mode=DB_LOCK_READ, timeout=0, lock=0x40d8e50c) at
../lock/lock.c:740
740                     no_dd = sh_locker->master_locker == INVALID_ROFF &&
(gdb) bt
#0  0x400bd3bd in __lock_get_internal (lt=0x8215ae8, sh_locker=0x7, flags=0,
obj=0x82168d4, lock_mode=DB_LOCK_READ, timeout=0, lock=0x40d8e50c) at
../lock/lock.c:740
#1  0x400bcc85 in __lock_get (dbenv=0x82154e8, locker=0x7, flags=0,
obj=0x82168d4, lock_mode=DB_LOCK_READ, lock=0x40d8e50c) at ../lock/lock.c:447
#2  0x400ec2f7 in __db_lget (dbc=0x8216858, action=0, pgno=1, mode=DB_LOCK_READ,
lkflags=0, lockp=0x40d8e50c) at ../db/db_meta.c:1012
#3  0x40054d7d in __bam_get_root (dbc=0x8216858, pg=1, slevel=1, flags=1409,
stack=0x40d8e614) at ../btree/bt_search.c:94
#4  0x400551a4 in __bam_search (dbc=0x8216858, root_pgno=1, key=0x40d8e97c,
flags=1409, slevel=1, recnop=0x0, exactp=0x40d8e818) at
../btree/bt_search.c:200
#5  0x40045160 in __bamc_search (dbc=0x8216858, root_pgno=0, key=0x40d8e97c,
flags=26, exactp=0x40d8e818) at ../btree/bt_cursor.c:2486
#6  0x400411bc in __bamc_get (dbc=0x8216858, key=0x40d8e97c, data=0x40d8e95c,
flags=26, pgnop=0x40d8e8ac) at ../btree/bt_cursor.c:961
#7  0x400da81d in __dbc_get (dbc_arg=0x8217158, key=0x40d8e97c, data=0x40d8e95c,
flags=26) at ../db/db_cam.c:697
#8  0x400e7dfb in __dbc_get_pp (dbc=0x8217158, key=0x40d8e97c, data=0x40d8e95c,
flags=26) at ../db/db_iface.c:2022
#9  0x080d455f in bdb_id2entry (be=0x7, tid=0x0, locker=7, id=1, e=0x40d8e9f8)
at id2entry.c:125
#10 0x080cdabb in bdb_cache_find_id (op=0x822a638, tid=0x0, id=1,
eip=0x40d8ea84, islocked=0, locker=7, lock=0x40d8eb1c) at cache.c:760
#11 0x080d12cd in bdb_dn2entry (op=0x822a638, tid=0x0, dn=0x0, e=0x40d8eb14,
matched=1, locker=7, lock=0x40d8eb1c) at dn2entry.c:68
#12 0x080b4ae9 in bdb_search (op=0x822a638, rs=0x40e4fc9c) at search.c:374
#13 0x0805ec5b in fe_op_search (op=0x822a638, rs=0x40e4fc9c) at search.c:355
#14 0x0805e43f in do_search (op=0x822a638, rs=0x40e4fc9c) at search.c:217
#15 0x0805cae2 in connection_operation (ctx=0x7, arg_v=0x822a638) at
connection.c:1133
#16 0x080fd514 in ldap_int_thread_pool_wrapper (xpool=0x81c0a88) at tpool.c:478
#17 0x4019cf60 in pthread_start_thread () from /lib/i686/libpthread.so.0
#18 0x4019d0fe in pthread_start_thread_event () from /lib/i686/libpthread.so.0
#19 0x402c5327 in clone () from /lib/i686/libc.so.6



** Description
We added some printf's and found the that sh_locker has the value 0x7 
which seems to be an index but not a valid lock for the database. 

Note: With the following modification the tests are running:

File: servers/slapd/back-bdb/id2entry.c 
Line: 120

#if 0
	/* Use our own locker if needed */
	if ( !tid && locker )
		cursor->locker = locker;
#endif


Any help is appriated


Regards
    Mark






Comment 1 Howard Chu 2007-10-08 16:18:18 UTC
changed notes
changed state Open to Closed
Comment 2 ando@openldap.org 2007-10-09 14:42:42 UTC
> Full_Name: Mark
> Version: 2.3.38
> OS: Suse Linux 10.01
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (84.128.87.178)
>
>
> ** Problem
> test001-slapdadd fails with segmentation fault.
>
> ** Environment
> Suse Linux 10.1
> Berkly DB  4.6.21
> Openldap   2.3.38

OpenLDAP 2.3 does not support Berkeley > 4.6.9; this issue has been risen
dozens of times, but apprently browsing archives for known issues has
become unfashionable.

Please either upgrade to OpenLDAP 2.4 or downgrade to Berkeley < 4.6.

This ITS will be closed.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   pierangelo.masarati@sys-net.it
---------------------------------------


Comment 3 Howard Chu 2007-10-09 22:05:42 UTC
changed notes
changed state Closed to Suspended
Comment 4 Howard Chu 2007-10-09 22:06:00 UTC
changed notes
changed state Suspended to Feedback
Comment 5 Howard Chu 2007-11-01 14:18:35 UTC
changed notes
Comment 6 Howard Chu 2008-04-11 11:20:32 UTC
changed notes
changed state Feedback to Suspended
Comment 7 Howard Chu 2008-11-06 16:14:58 UTC
changed notes
changed state Suspended to Closed
Comment 8 Howard Chu 2009-02-17 06:45:24 UTC
moved from Incoming to Archive.Incoming
Comment 9 OpenLDAP project 2014-08-01 21:06:04 UTC
dup #5148, #5162, #5169
keep unclosed for visibility
I think we can ignore this now