[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
slapd coredump trying to strdup NULL- possibly broken ldif file?
Hello,
I'm attempting to experimet with openLDAP 1.2 using web500gw and a samll
db I've cretaed myself (with virtually no refernce material)
As a result, the following bug is probably due to my brokem databse
structure, but I think that shouldn't cause slapd to coredump.
the bug is really 2 potential 'bugs':
a) the STR_TRANSLATION define is not a configure option and is not
documented anywhere, but web500gw needs it to compile by default. Is
translation from T.61 strings deprecated? Is it slated for removal? Or
are there some problems with the current implementation (apart from the
performance hit).
b) on my system (linux 2.0.36, libc 5.4.46, gdbm 1.7.3 used as backend)
slapd will segfault when web500gw tries to browse above the default
'start' DN set up in its configuration files.
slapd.conf entries (DB definitions, no indices defined):
web500gw 'home' DN
homedn: ou=Periphonics VPS Ltd.,c=GB,ou=Periphonics EMEA,o=Periphonics
Corporation,dc=peri,dc=com
database ldbm
suffix "dc=peri, dc=com"
#suffix "o=Periphonics VPS Ltd, c=GB"
directory /usr/tmp
rootdn "cn=root, dc=peri, dc=com"
#rootdn "cn=root, o=Periphonics VPS Ltd, c=GB"
rootpw secret
ldif file used (I know that 90% of this is probably pathologically,
bizarrely wrong but I have yet to find a description of how to structure
an LDAP directory I can understand):
dn: dc=peri,dc=com
o: Periphonics Corporation
objectclass: organization
dn: ou=Periphonics EMEA,o=Periphonics Corporation,dc=peri,dc=com
ou: Periphonics EMEA
o: Periphonics Corporation
objectclass: organizationalunit
dn: ou=Periphonics GmbH.c=DE,ou=Periphonics EMEA,o=Periphonics
Corporation,dc=peri,dc=com
ou: Periphonics GmbH
ou: Periphonics EMEA
c: DE
cn: EMEA
cn: DE
o: Periphonics Corporation
objectclass: organizationalunit
dn: ou=Periphonics VPS Ltd.,c=GB,ou=Periphonics EMEA,o=Periphonics
Corporation,dc=peri,dc=com
ou: Periphonics VPS Ltd.
ou: Periphonics EMEA
o: Periphonics Corporation
c: GB
cn: EMEA
cn: UK
objectclass: organizationalunit
dn: ou=Customer Projects,ou=Periphonics VPS Ltd.,c=GB,ou=Periphonics
EMEA,o=Periphonics Corporation,dc=peri,dc=com
ou: Customer Projects
ou: Periphonics VPS Ltd.
ou: Periphonics EMEA
c: GB
o: Periphonics Corporation
objectclass: organizationalunit
dn: ou=Admin,ou=Periphonics VPS Ltd.,c=GB,ou=Periphonics
EMEA,o=Periphonics Corporation,dc=peri,dc=com
ou: Admin
ou: Periphonics VPS Ltd.
ou: Periphonics EMEA
c: GB
o: Periphonics Corporation
objectclass: organizationalunit
dn: ou=IT,ou=Admin,ou=Periphonics VPS Ltd.,c=GB,ou=Periphonics
EMEA,o=Periphonics Corporation,dc=peri,dc=com
objectclass: organizationalunit
ou: IT
ou: Admin
ou: Periphonics VPS Ltd.
ou: Periphonics EMEA
c: GB
o: Periphonics Corporation
dn: cn=fornax,ou=IT,ou=Admin,ou=Periphonics VPS Ltd.,c=GB,ou=Periphonics
EMEA,o=Periphonics Corporation,dc=peri,dc=com
ou: IT
ou: Admin
cn: fornax
ou: Periphonics VPS Ltd.
ou: Periphonics EMEA
c: GB
o: Periphonics Corporation
objectclass: device
dn: cn=WWW/LDAP-Gateway,cn=fornax,ou=IT,ou=Admin,ou=Periphonics VPS
Ltd.,c=GB,ou=Periphonics EMEA,o=Periphonics Corporation,dc=peri,dc=com
cn: WWW/LDAP-Gateway
ou: IT
ou: Admin
cn: fornax
ou: Periphonics VPS Ltd.
ou: Periphonics EMEA
c: GB
o: Periphonics Corporation
objectclass: service
dn: Dirk Niggemann,ou=Customer Projects,ou=Periphonics VPS
Ltd.,c=GB,ou=Periphonics EMEA,o=Periphonics Corporation, dc=peri,dc=com
cn: Dirk Niggemann
sn: Niggemann
mail: Dirk.Niggemann@peri.com
ou: Customer Projects
ou: Periphonics VPS Ltd.
ou: Periphonics EMEA
c: GB
o: Periphonics Corporation
objectclass: person
BTW I just noticed the strange positioning of objectclass in 1 entry as
well....
The segfault occurs when thread support is compiled in or not.
The sefault happens with both db 1.8.5 and gdbm 1.7.3
both compiles of libldap had DSTR_TRANSLATION defined.
Anyway, the sefault is in strdup,
debug -d123 from as follows
select activity on 1 descriptors
new connection on 8
activity on:
listening for connections on 6, activity on: 8r
before select active_threads 0
select activity on 1 descriptors
activity on: 8r
read activity on 8
ber_get_next
ber_get_next: tag 0x30 len 148 contents:
ber_dump: buf 0x80886a0, ptr 0x80886a0, end 0x8088734
current len 148, contents:
02 01 01 ` 81 8e 02 01 02 04 81 86 c n = W
W W / L D A P - G a t e w a y ,
c n = f o r n a x , o u = I T ,
o u = A d m i n , o u = P e r i
p h o n i c s 20 V P S 20 L t d .
, c = G B , o u = P e r i p h o
n i c s 20 E M E A , o = P e r i
p h o n i c s 20 C o r p o r a t
i o n , d c = p e r i , d c = c
o m 80 00
do_bind
do_bind: version 2 dn
(cn=WWW/LDAP-Gateway,cn=fornax,ou=IT,ou=Admin,ou=Periphonics VPS
Ltd.,c=GB,ou=Periphonics EMEA,o=Periphonics Corporation,dc=peri,dc=com)
method 128
dn2entry_r: dn:
"CN=WWW/LDAP-GATEWAY,CN=FORNAX,OU=IT,OU=ADMIN,OU=PERIPHONICS VPS
LTD.,C=GB,OU=PERIPHONICS EMEA,O=PERIPHONICS CORPORATION,DC=PERI,DC=COM"
=> dn2id( "CN=WWW/LDAP-GATEWAY,CN=FORNAX,OU=IT,OU=ADMIN,OU=PERIPHONICS
VPS LTD.,C=GB,OU=PERIPHONICS EMEA,O=PERIPHONICS
CORPORATION,DC=PERI,DC=COM" )
=> ldbm_cache_open( "/usr/tmp/dn2id.gdbm", 2, 600 )
<= ldbm_cache_open (opened 0)
<= dn2id 9
=> id2entry_r( 9 )
=> ldbm_cache_open( "/usr/tmp/id2entry.gdbm", 2, 600 )
<= ldbm_cache_open (opened 1)
=> str2entry
<= str2entry 0x80bd470
<= id2entry_r( 9 ) (disk)
send_ldap_result 0::
ber_flush: 14 bytes to sd 8
====> cache_return_entry_r
listening for connections on 6, activity on: 8r
before select active_threads 0
select activity on 1 descriptors
activity on: 8r
read activity on 8
ber_get_next
ber_get_next: tag 0x30 len 106 contents:
ber_dump: buf 0x80bd378, ptr 0x80bd378, end 0x80bd3e2
current len 106, contents:
02 01 02 c e 04 E c = G B , 20 o u =
P e r i p h o n i c s 20 E M E A
, 20 o = P e r i p h o n i c s 20
C o r p o r a t i o n , 20 d c =
p e r i , 20 d c = c o m 0a 01 00 0a
01 02 02 01 00 02 01 00 01 01 00 87 0b o b j
e c t C l a s s 0 00
do_search
begin get_filter
PRESENT
end get_filter 0
<= dereferencing dn: "C=GB,OU=PERIPHONICS EMEA,O=PERIPHONICS
CORPORATION,DC=PERI,DC=COM"
dn2entry_r: dn: "C=GB,OU=PERIPHONICS EMEA,O=PERIPHONICS
CORPORATION,DC=PERI,DC=COM"
=> dn2id( "C=GB,OU=PERIPHONICS EMEA,O=PERIPHONICS
CORPORATION,DC=PERI,DC=COM" )
=> ldbm_cache_open( "/usr/tmp/dn2id.gdbm", 2, 600 )
<= ldbm_cache_open (cache 0)
<= dn2id NOID
dn2entry_r: dn: "OU=PERIPHONICS EMEA,O=PERIPHONICS
CORPORATION,DC=PERI,DC=COM"
=> dn2id( "OU=PERIPHONICS EMEA,O=PERIPHONICS CORPORATION,DC=PERI,DC=COM"
)
=> ldbm_cache_open( "/usr/tmp/dn2id.gdbm", 2, 600 )
<= ldbm_cache_open (cache 0)
<= dn2id 2
=> id2entry_r( 2 )
=> ldbm_cache_open( "/usr/tmp/id2entry.gdbm", 2, 600 )
<= ldbm_cache_open (cache 1)
=> str2entry
<= str2entry 0x80887b8
<= id2entry_r( 2 ) (disk)
====> cache_return_entry_r
dn2entry_r: dn: "OU=PERIPHONICS EMEA,O=PERIPHONICS
CORPORATION,DC=PERI,DC=COM"
=> dn2id( "OU=PERIPHONICS EMEA,O=PERIPHONICS CORPORATION,DC=PERI,DC=COM"
)
====> cache_find_entry_dn2id: found dn: OU=PERIPHONICS
EMEA,O=PERIPHONICS CORPORATION,DC=PERI,DC=COM
<= dn2id 2 (in cache)
=> id2entry_r( 2 )
====> cache_find_entry_dn2id: found id: 2 rw: 0
<= id2entry_r 0x80887b8 (cache)
<= matched OU=PERIPHONICS EMEA,O=PERIPHONICS CORPORATION,DC=PERI,DC=COM
<= remainder C=GB,
<= checking for alias for dn ou=Periphonics EMEA,o=Periphonics
Corporation,dc=peri,dc=com
<= l&g we have OU=PERIPHONICS EMEA,O=PERIPHONICS
CORPORATION,DC=PERI,DC=COM vs ou=Periphonics EMEA,o=Periphonics
Corporation,dc=peri,dc=com
====> cache_return_entry_r
====> cache_return_entry_r
dn2entry_r: dn: "(null)"
Program received signal SIGSEGV, Segmentation fault.
0x4007735f in strdup ()
stack backtrace gives nothing usable at this point,
so by setting a few breakpoints it appears the problem is somewhere in
derefDN(alias.c)
- the segfault occurs in dn2entry_r called in line 281
(where it derefDN manages to pass a NULL dn to dn2entry_r).
Any suggestions?
Hope this is useful,
Dirk
Dirk Niggemann
dirk-n@dircon.co.uk