[Date Prev][Date Next] [Chronological] [Thread] [Top]

(ITS#4307) slapd segfaults if suffix is specified last in slapd.conf



Full_Name: Michele Baldessari
Version: 2.3.15
OS: Ubuntu Breezy
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (81.208.106.70)


I stumbled into this accidentally:
If the "suffix" keyword appears at the end of slapd.conf (hence acl's come
before), you get this:
(gdb) run
Starting program: /home/devel/openldap/openldap-2.3.15/debian/build/servers/slapd/.libs/slapd
[Thread debugging using libthread_db enabled]
[New Thread -1212971328 (LWP 27219)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1212971328 (LWP 27219)]
0x080979cc in parse_acl (be=0x8192e98, fname=0x80faef9 "/etc/ldap/slapd.conf",
lineno=79, argc=15, argv=0x8172470, pos=-1) at
/home/devel/openldap/openldap-2.3.15/servers/slapd/aclparse.c:1986
1986                            if ( !BER_BVISNULL( &be->be_nsuffix[ 1 ] ) ) {
(gdb) bt
#0  0x080979cc in parse_acl (be=0x8192e98, fname=0x80faef9
"/etc/ldap/slapd.conf", lineno=79, argc=15, argv=0x8172470, pos=-1) at
/home/devel/openldap/openldap-2.3.15/servers/slapd/aclparse.c:1986
#1  0x08058da1 in config_generic (c=0x81712f8) at
/home/devel/openldap/openldap-2.3.15/servers/slapd/bconfig.c:1182
#2  0x0806346b in config_set_vals (Conf=0x8141a70, c=0x81712f8) at
/home/devel/openldap/openldap-2.3.15/servers/slapd/config.c:295
#3  0x08063884 in config_add_vals (Conf=0x8141a70, c=0x81712f8) at
/home/devel/openldap/openldap-2.3.15/servers/slapd/config.c:363
#4  0x080648bf in read_config_file (fname=0x80faef9 "/etc/ldap/slapd.conf",
depth=0, cf=0x0, cft=0x8141a20) at
/home/devel/openldap/openldap-2.3.15/servers/slapd/config.c:753
#5  0x0805e82a in read_config (fname=0x0, dir=0x0) at
/home/devel/openldap/openldap-2.3.15/servers/slapd/bconfig.c:2993
#6  0x0805720e in main (argc=1, argv=0xbfc02854) at
/home/devel/openldap/openldap-2.3.15/servers/slapd/main.c:633


Naturally if the suffix line is right where it normally is (after database)
things are alive and well.

No big deal, but I thought it still might be worth reporting