Issue 3119 - slapd segmentation fault on Solaris 9
Summary: slapd segmentation fault on Solaris 9
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: 2004-04-27 22:34 UTC by greg.adams@eds.com
Modified: 2014-08-01 21:05 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 greg.adams@eds.com 2004-04-27 22:34:22 UTC
Full_Name: Greg Adams
Version: 2.1.30
OS: Solaris 2.9
URL: 
Submission from: (NULL) (192.85.47.1)


OpenLDAP version: 2.1.30 (stable-20040421)

Platform: 
Solaris 2.9 sparc
BerkeleyDB 4.2.52.NC
OpenSSL 0.9.6l
GCC 3.3.2 Thread model: posix 

Configure environment:
configure commands:

CPPFLAGS="-I/usr/local/BerkeleyDB.4.2/include
-I/usr/local/openssl-0.9.6l/include" ; export CPPFLAGS
./configure --with-tls --enable-crypt --enable-debug

no startling output from configure.

full command that produces the error:

# make test
cd tests; make test
ln: cannot create ./data: File exists
*** Error code 2 (ignored)
ln: cannot create ./schema: File exists
*** Error code 2 (ignored)
Initiating LDAP tests for BDB...
>>>>> Executing all LDAP tests...
>>>>> Test Directory: .
>>>>> Backend: bdb
>>>>> Starting test000-rootdse ...
running defines.sh
Datadir is ./data
Cleaning up in ./test-db...
Starting slapd on TCP/IP port 9009...
Using ldapsearch to retrieve the root DSE...
Waiting 5 seconds for slapd to start...
4172 Segmentation Fault - core dumped
Waiting 5 seconds for slapd to start...
Waiting 5 seconds for slapd to start...

<this goes on forever...>


also...

# ./servers/slapd/slapd -d 1
@(#) $OpenLDAP: slapd 2.1.30 (Apr 27 2004 15:01:28) $
        @maul:/space/pkg/openldap-2.1.30/servers/slapd
daemon_init: listen on ldap:///
daemon_init: 1 listeners to open...
ldap_url_parse_ext(ldap:///)
daemon: initialized ldap:///
daemon_init: 2 listeners opened
slapd init: initiated server.
bdb_initialize: initialize BDB backend
bdb_initialize: version mismatch
        expected: Sleepycat Software: Berkeley DB 4.2.52: (December  3, 2003)
        got: Sleepycat Software: Berkeley DB 3.1.17: (July 31, 2000) 
bdb_initialize: Sleepycat Software: Berkeley DB 3.1.17: (July 31, 2000)
>>> dnNormalize: <cn=Subschema>
=> ldap_bv2dn(cn=Subschema,0)
<= ldap_bv2dn(cn=Subschema,0)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=subschema,272)=0
<<< dnNormalize: <cn=subschema>
bdb_db_init: Initializing BDB database
>>> dnPrettyNormal: <dc=ddm,dc=apm,dc=bpm,dc=eds,dc=com>
=> ldap_bv2dn(dc=ddm,dc=apm,dc=bpm,dc=eds,dc=com,0)
<= ldap_bv2dn(dc=ddm,dc=apm,dc=bpm,dc=eds,dc=com,0)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(dc=ddm,dc=apm,dc=bpm,dc=eds,dc=com,272)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(dc=ddm,dc=apm,dc=bpm,dc=eds,dc=com,272)=0
<<< dnPrettyNormal: <dc=ddm,dc=apm,dc=bpm,dc=eds,dc=com>,
<dc=ddm,dc=apm,dc=bpm,dc=eds,dc=com>
>>> dnPrettyNormal: <cn=Manager,dc=ddm,dc=apm,dc=bpm,dc=eds,dc=com>
=> ldap_bv2dn(cn=Manager,dc=ddm,dc=apm,dc=bpm,dc=eds,dc=com,0)
<= ldap_bv2dn(cn=Manager,dc=ddm,dc=apm,dc=bpm,dc=eds,dc=com,0)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=Manager,dc=ddm,dc=apm,dc=bpm,dc=eds,dc=com,272)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=manager,dc=ddm,dc=apm,dc=bpm,dc=eds,dc=com,272)=0
<<< dnPrettyNormal: <cn=Manager,dc=ddm,dc=apm,dc=bpm,dc=eds,dc=com>,
<cn=manager,dc=ddm,dc=apm,dc=bpm,dc=eds,dc=com>
matching_rule_use_init
    1.2.840.113556.1.4.804 (integerBitOrMatch): matchingRuleUse: (
1.2.840.113556.1.4.804 NAME 'integerBitOrMatch' APPLIES supportedLDAPVersion )
    1.2.840.113556.1.4.803 (integerBitAndMatch): matchingRuleUse: (
1.2.840.113556.1.4.803 NAME 'integerBitAndMatch' APPLIES supportedLDAPVersion )
    1.3.6.1.4.1.1466.109.114.2 (caseIgnoreIA5Match): matchingRuleUse: (
1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' APPLIES ( email $
associatedDomain $ dc $ mail $ altServer ) )
    1.3.6.1.4.1.1466.109.114.1 (caseExactIA5Match): matchingRuleUse: (
1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' APPLIES ( email $
associatedDomain $ dc $ mail $ altServer ) )
    2.5.13.34 (certificateExactMatch): matchingRuleUse: ( 2.5.13.34 NAME
'certificateExactMatch' APPLIES ( cACertificate $ userCertificate ) )
    2.5.13.30 (objectIdentifierFirstComponentMatch): matchingRuleUse: (
2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' APPLIES (
supportedApplicationContext $ ldapSyntaxes $ matchingRuleUse $ objectClasses $
attributeTypes $ matchingRules $ supportedFeatures $ supportedExtension $
supportedControl $ structuralObjectClass $ objectClass ) )
    2.5.13.29 (integerFirstComponentMatch): matchingRuleUse: ( 2.5.13.29 NAME
'integerFirstComponentMatch' APPLIES supportedLDAPVersion )
    2.5.13.27 (generalizedTimeMatch): matchingRuleUse: ( 2.5.13.27 NAME
'generalizedTimeMatch' APPLIES ( modifyTimestamp $ createTimestamp ) )
    2.5.13.24 (protocolInformationMatch): matchingRuleUse: ( 2.5.13.24 NAME
'protocolInformationMatch' APPLIES protocolInformation )
    2.5.13.23 (uniqueMemberMatch): matchingRuleUse: ( 2.5.13.23 NAME
'uniqueMemberMatch' APPLIES uniqueMember )
    2.5.13.22 (presentationAddressMatch): matchingRuleUse: ( 2.5.13.22 NAME
'presentationAddressMatch' APPLIES presentationAddress )
    2.5.13.20 (telephoneNumberMatch): matchingRuleUse: ( 2.5.13.20 NAME
'telephoneNumberMatch' APPLIES telephoneNumber )
    2.5.13.17 (octetStringMatch): matchingRuleUse: ( 2.5.13.17 NAME
'octetStringMatch' APPLIES userPassword )
    2.5.13.16 (bitStringMatch): matchingRuleUse: ( 2.5.13.16 NAME
'bitStringMatch' APPLIES x500UniqueIdentifier )
    2.5.13.14 (integerMatch): matchingRuleUse: ( 2.5.13.14 NAME 'integerMatch'
APPLIES supportedLDAPVersion )
    2.5.13.13 (booleanMatch): matchingRuleUse: ( 2.5.13.13 NAME 'booleanMatch'
APPLIES hasSubordinates )
    2.5.13.11 (caseIgnoreListMatch): matchingRuleUse: ( 2.5.13.11 NAME
'caseIgnoreListMatch' APPLIES ( registeredAddress $ postalAddress ) )
    2.5.13.8 (numericStringMatch): matchingRuleUse: ( 2.5.13.8 NAME
'numericStringMatch' APPLIES ( internationaliSDNNumber $ x121Address ) )
    2.5.13.7 (caseExactSubstringsMatch): matchingRuleUse: ( 2.5.13.7 NAME
'caseExactSubstringsMatch' APPLIES ( dnQualifier $ destinationIndicator $
serialNumber ) )
    2.5.13.6 (caseExactOrderingMatch): matchingRuleUse: ( 2.5.13.6 NAME
'caseExactOrderingMatch' APPLIES ( dnQualifier $ destinationIndicator $
serialNumber ) )
    2.5.13.5 (caseExactMatch): matchingRuleUse: ( 2.5.13.5 NAME 'caseExactMatch'
APPLIES ( uid $ labeledURI $ dmdName $ houseIdentifier $ dnQualifier $
generationQualifier $ initials $ givenName $ destinationIndicator $
physicalDeliveryOfficeName $ postOfficeBox $ postalCode $ businessCategory $
description $ title $ ou $ o $ street $ st $ l $ c $ serialNumber $ sn $
knowledgeInformation $ cn $ name $ ref $ vendorVersion $ vendorName $
supportedSASLMechanisms ) )
    2.5.13.3 (caseIgnoreOrderingMatch): matchingRuleUse: ( 2.5.13.3 NAME
'caseIgnoreOrderingMatch' APPLIES ( dnQualifier $ destinationIndicator $
serialNumber ) )
    2.5.13.2 (caseIgnoreMatch): matchingRuleUse: ( 2.5.13.2 NAME
'caseIgnoreMatch' APPLIES ( uid $ labeledURI $ dmdName $ houseIdentifier $
dnQualifier $ generationQualifier $ initials $ givenName $ destinationIndicator
$ physicalDeliveryOfficeName $ postOfficeBox $ postalCode $ businessCategory $
description $ title $ ou $ o $ street $ st $ l $ c $ serialNumber $ sn $
knowledgeInformation $ cn $ name $ ref $ vendorVersion $ vendorName $
supportedSASLMechanisms ) )
    2.5.13.1 (distinguishedNameMatch): matchingRuleUse: ( 2.5.13.1 NAME
'distinguishedNameMatch' APPLIES ( seeAlso $ roleOccupant $ owner $ member $
distinguishedName $ aliasedObjectName $ namingContexts $ subschemaSubentry $
modifiersName $ creatorsName ) )
    2.5.13.0 (objectIdentifierMatch): matchingRuleUse: ( 2.5.13.0 NAME
'objectIdentifierMatch' APPLIES ( supportedApplicationContext $
supportedFeatures $ supportedExtension $ supportedControl $
structuralObjectClass $ objectClass ) )
slapd startup: initiated.
Illegal Instruction - core dumped


GDB information:

stack backtrace (output from bt full after run -d 1 gives SIGILL, Illegal
instruction)

Program received signal SIGILL, Illegal instruction.
0x000e4fd0 in ?? ()
(gdb) bt full
#0  0x000e4fd0 in ?? ()
No symbol table info available.
#1  0x0002f4c0 in backend_startup (be=0xc4800) at backend.c:321
        i = 0
        rc = 0
#2  0x0001d01c in main (argc=804864, argv=0x1) at main.c:513
        i = 0
        no_detach = 807936
        rc = 0
        urls = 0xc4800 ""
        username = 0x9d400 "line (ignored)\n"
        groupname = 0x0
        sandbox = 0xc4800 ""
        syslogUser = 0
        configfile = 0x0
        serverName = 0x0
(gdb) 


Additional notes:
setting a break in slap_startup led me to the line that produces SIGILL.

(gdb) step
198             bdb->bi_dbenv->set_errpfx( bdb->bi_dbenv,
be->be_suffix[0].bv_val );
(gdb) print bdb
$3 = (struct bdb_info *) 0xe3570
(gdb) step

Program received signal SIGILL, Illegal instruction.
0x000e4fd0 in ?? ()
(gdb) 



Line 198 in back-bdb/init.c

Comment 1 greg.adams@eds.com 2004-04-27 23:06:29 UTC
Update:

ldd revealed that I was actually linking a BerkeleyDB 3.1 that I wasn't
aware was on my system. Please await further details before doing any
research or trying to reproduce. I will reply again if this was the cause.

-----Original Message-----
From: openldap-its@OpenLDAP.org [mailto:openldap-its@OpenLDAP.org]
Sent: Tuesday, April 27, 2004 3:34 PM
To: greg.adams@eds.com
Subject: Re: slapd segmentation fault on Solaris 9 (ITS#3119)



*** THIS IS AN AUTOMATICALLY GENERATED REPLY ***

Thanks for your report to the OpenLDAP Issue Tracking System.  Your
report has been assigned the tracking number ITS#3119.

One of our support engineers will look at your report in due course.
Note that this may take some time because our support engineers
are volunteers.  They only work on OpenLDAP when they have spare
time.

If you need to provide additional information in regards to your
issue report, you may do so by replying to this message.  Note that
any mail sent to openldap-its@openldap.org with (ITS#3119)
in the subject will automatically be attached to the issue report.

	mailto:openldap-its@openldap.org?subject=(ITS#3119)

You may follow the progress of this report by loading the following
URL in a web browser:
    http://www.OpenLDAP.org/its/index.cgi?findid=3119

Please remember to retain your issue tracking number (ITS#3119)
on any further messages you send to us regarding this report.  If
you don't then you'll just waste our time and yours because we
won't be able to properly track the report.

Please note that the Issue Tracking System is not intended to
be used to seek help in the proper use of OpenLDAP Software.
Such requests will be closed.

OpenLDAP Software is user supported.
	http://www.OpenLDAP.org/support/

--------------
Copyright 1999-2004 The OpenLDAP Foundation, All Rights Reserved.

Comment 2 Kurt Zeilenga 2004-04-27 23:13:50 UTC
changed notes
Comment 3 greg.adams@eds.com 2004-04-27 23:20:00 UTC
Yep, linking against BerkeleyDB 3.1 was causing the segmentation fault.
Problem solved. Please close this issue at your convenience.

Comment 4 Kurt Zeilenga 2004-04-27 23:23:17 UTC
changed notes
changed state Open to Closed
Comment 5 Howard Chu 2009-02-17 05:25:25 UTC
moved from Incoming to Archive.Incoming
Comment 6 OpenLDAP project 2014-08-01 21:05:49 UTC
close on submitter's request