[Date Prev][Date Next] [Chronological] [Thread] [Top]
RE: SASL/GSSAPI with 2.1.4 causes segfaults

To: "Quanah Gibson-Mount" <quanah@stanford.edu>
Subject: RE: SASL/GSSAPI with 2.1.4 causes segfaults
From: "Howard Chu" <hyc@symas.com>
Date: Fri, 30 Aug 2002 13:00:22 -0700
Cc: <openldap-software@OpenLDAP.org>
Importance: Normal
In-reply-to: <319227925.1030700670@cadabra.Stanford.EDU>
Start the program under gdb; when it crashes it will automatically leave you
at the point of the crash. Also fyi, the search that slapd performs when
resolving a regexp mapping is purely internal to slapd, it uses no network
connection. Specifying the URL as "ldaps:///" is irrelevant.

Script started on Fri Aug 30 12:52:21 2002
lute:~/OD/obj/tests> gdb ../servers/slapd/slapd
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.8"...
(gdb) run -f test-db/slapd.conf -h ldap://:9000 -d1
Starting program: /export/home/hyc/OD/obj/tests/../servers/slapd/slapd -f
test-db/slapd.conf -h ldap://:9000 -d1
[New LWP 1]
[New LWP 2]
[New LWP 3]
[New LWP 4]
@(#) $OpenLDAP: slapd 2.X (Fri Aug 30 12:50:38 PDT 2002) $
        hyc@lute:/export/home/hyc/OD/obj/servers/slapd
daemon_init: listen on ldap://:9000
daemon_init: 1 listeners to open...
ldap_url_parse_ext(ldap://:9000)
daemon: initialized ldap://:9000
daemon_init: 2 listeners opened
slapd init: initiated server.
slap_sasl_init: initialized!
bdb_open: initialize BDB backend
bdb_open: Sleepycat Software: Berkeley DB 4.0.14: (November 18, 2001)
perl backend open
>>> 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: <o=University of Michigan, c=US>
=> ldap_bv2dn(o=University of Michigan, c=US,0)
<= ldap_bv2dn(o=University of Michigan, c=US,0)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(o=University of Michigan,c=US,272)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(o=university of michigan,c=us,272)=0
<<< dnPrettyNormal: <o=University of Michigan,c=US>, <o=university of
michigan,c=us>
>>> dnPrettyNormal: <cn=Manager, o=University of Michigan, c=US>
=> ldap_bv2dn(cn=Manager, o=University of Michigan, c=US,0)
<= ldap_bv2dn(cn=Manager, o=University of Michigan, c=US,0)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=Manager,o=University of Michigan,c=US,272)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=manager,o=university of michigan,c=us,272)=0
<<< dnPrettyNormal: <cn=Manager,o=University of Michigan,c=US>,
<cn=manager,o=university of michigan,c=us>
slapd startup: initiated.
bdb_db_open: dbenv_open(./test-db)
slapd starting
ldap_pvt_gethostbyname_a: host=lute, r=0
put_filter: "(objectclass=*)"
put_filter: simple
put_simple_filter: "objectclass=*"
ber_scanf fmt (m) ber:
connection_get(15): got connid=0
connection_read(15): checking for input on id=0
ber_get_next
ber_get_next: tag 0x30 len 24 contents:
ber_get_next
ber_get_next on fd 15 failed errno=11 (Resource temporarily unavailable)
do_bind
ber_scanf fmt ({imt) ber:
ber_scanf fmt ({o) ber:
ber_scanf fmt (}}) ber:
>>> dnPrettyNormal: <>
<<< dnPrettyNormal: <>, <>
do_sasl_bind: dn () mech DIGEST-MD5
SASL [conn=0] Debug: DIGEST-MD5 server step 1
send_ldap_sasl: err=14 len=174
send_ldap_response: msgid=1 tag=97 err=14
ber_flush: 193 bytes to sd 15
<== slap_sasl_bind: rc=14
[New LWP 5]
[New LWP 6]
connection_get(15): got connid=0
connection_read(15): checking for input on id=0
ber_get_next
ber_get_next: tag 0x30 len 294 contents:
ber_get_next
ber_get_next on fd 15 failed errno=11 (Resource temporarily unavailable)
do_bind
ber_scanf fmt ({imt) ber:
ber_scanf fmt ({o) ber:
ber_scanf fmt (m) ber:
ber_scanf fmt (}}) ber:
>>> dnPrettyNormal: <>
<<< dnPrettyNormal: <>, <>
do_sasl_bind: dn () mech DIGEST-MD5
SASL [conn=0] Debug: DIGEST-MD5 server step 2
getdn: u:id converted to uid=hyc,cn=zip,cn=DIGEST-MD5,cn=auth
>>> dnNormalize: <uid=hyc,cn=zip,cn=DIGEST-MD5,cn=auth>
=> ldap_bv2dn(uid=hyc,cn=zip,cn=DIGEST-MD5,cn=auth,0)
<= ldap_bv2dn(uid=hyc,cn=zip,cn=DIGEST-MD5,cn=auth,0)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(uid=hyc,cn=zip,cn=digest-md5,cn=auth,272)=0
<<< dnNormalize: <uid=hyc,cn=zip,cn=digest-md5,cn=auth>
==>slap_sasl2dn: converting SASL name uid=hyc,cn=zip,cn=digest-md5,cn=auth to
a DN
slap_sasl_regexp: converting SASL name uid=hyc,cn=zip,cn=digest-md5,cn=auth

Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 3]
0xfed33084 in strlen () from /usr/lib/libc.so.1
(gdb) where
#0  0xfed33084 in strlen () from /usr/lib/libc.so.1
#1  0xfed828d8 in _doprnt () from /usr/lib/libc.so.1
#2  0xfed84a4c in vsnprintf () from /usr/lib/libc.so.1
#3  0x664a4 in lutil_debug (debug=1, level=1,
    fmt=0x9be90 "slap_sasl_regexp: converted SASL name to
ldap:///%s??%s?%s\n";)
    at ../../../head/libraries/liblutil/debug.c:285
#4  0x458c0 in slap_sasl_regexp (in=0x101810, out=0xfc801658)
    at ../../../head/servers/slapd/saslauthz.c:328
#5  0x45aa4 in slap_sasl2dn (conn=0x113118, saslname=0xfc801850,
    sasldn=0xfc801770) at ../../../head/servers/slapd/saslauthz.c:411
#6  0x48ad8 in slap_sasl_getdn (conn=0x113118, id=0x109634 "zip",
len=1087024,
    user_realm=0x0, dn=0xfc801850, flags=2)
    at ../../../head/servers/slapd/sasl.c:447
#7  0x497d0 in slap_sasl_canonicalize (sconn=0x125020, context=0xfc801850,
    in=0x109630 "hyc@zip", inlen=7, flags=1, user_realm=0x0, out=0x125a31 "",
    out_max=256, out_len=0x125890) at ../../../head/servers/slapd/sasl.c:834
#8  0xff1d4d48 in _sasl_canon_user (conn=0x125020, user=0x109630 "hyc@zip",
    ulen=7, flags=1, oparams=0x125880) at canonusr.c:109
#9  0xfe3c4f7c in digestmd5_server_mech_step2 (stext=0x126148,
    sparams=0x124040, clientin=0x0, clientinlen=1206064,
serverout=0xfc801b54,
    serveroutlen=0xfc801b4c, oparams=0x125880) at digestmd5.c:2321
#10 0xff1ddb14 in sasl_server_step (conn=0x125020, clientin=0x0,
    clientinlen=1206064, serverout=0xfc801b54, serveroutlen=0xfc801b4c)
    at server.c:1258
#11 0x4a434 in slap_sasl_bind (conn=0x113118, op=0x1242e8, dn=0xfc801c08,
    ndn=0xfc801c00, cred=0xfc801bf0, edn=0xfc801bf8, ssfp=0xfc801bdc)
    at ../../../head/servers/slapd/sasl.c:1493
#12 0x2f32c in do_bind (conn=0x113118, op=0x1242e8)
    at ../../../head/servers/slapd/bind.c:291
#13 0x19e94 in connection_operation (ctx=0x125fb0, arg_v=0x109610)
    at ../../../head/servers/slapd/connection.c:946
#14 0x6ba50 in ldap_int_thread_pool_wrapper (xpool=0xbd620)
    at ../../../head/libraries/libldap_r/tpool.c:431
(gdb) q
The program is running.  Exit anyway? (y or n) y
lute:~/OD/obj/tests>
script done on Fri Aug 30 12:52:56 2002


  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: Quanah Gibson-Mount [mailto:quanah@stanford.edu]
> Sent: Friday, August 30, 2002 9:45 AM
> To: Howard Chu
> Subject: RE: SASL/GSSAPI with 2.1.4 causes segfaults
>
>
>
>
> --On Friday, August 30, 2002 5:31 AM -0700 Howard Chu
> <hyc@symas.com> wrote:
>
> > This is due to a typo in a Debug statement. By the way, when reporting a
> > crash, you will get a faster resolution if you give us the stack trace
> > from the crash. It would make it easier for us to locate these errors.
> > You would even be able to locate and fix the error yourself very quickly,
> > especially for such simple mistakes as this.
>
> Howard,
>
> I did do a gdb on the running slapd process, trying to gather more
> information.  Unfortunately, the thread involved died so quickly I didn't
> even get a chance to switch to it.  I'm still learning how to use gdb
> effectively, so I'll see what I can do about stack traces in the future.
>
> --Quanah
>
> --
> Quanah Gibson-Mount
> Senior Systems Administrator
> ITSS/TSS/Computing Systems
> Stanford University
> GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
Prev by Date: Re: Another database
Next by Date: RE: database ldbm problem
Index(es):
- Chronological
- Thread