Description of problem: I can force a server crash using ldapmodify. Version-Release number of selected component (if applicable): fedora-ds-base-1.1.3-2.fc9.i386 How reproducible: Every time. Steps to Reproduce: % ldapmodify -x -D "cn=directory manager" -W dn: cn=foo,cn=groups,cn=accounts,dc=example.com,dc=com changetype: modify delete: gidnumber (gdb) where #0 dna_pre_op (pb=0x930fe60, modtype=4) at dna.c:1295 #1 0x0017c0a1 in ?? () from /usr/lib/dirsrv/libslapd.so.0 #2 0x0017c2ae in plugin_call_plugins () from /usr/lib/dirsrv/libslapd.so.0 #3 0x0016fb7c in ?? () from /usr/lib/dirsrv/libslapd.so.0 #4 0x001711bc in do_modify () from /usr/lib/dirsrv/libslapd.so.0 #5 0x08058157 in ber_sockbuf_free () #6 0x00927f81 in ?? () from /lib/libnspr4.so #7 0x00bd532f in start_thread () from /lib/libpthread.so.0 #8 0x00af220e in clone () from /lib/libc.so.6 (gdb) print bv $1 = (struct berval *) 0x0
Backtrace using the FDS DNA plugin. This build is from the source tip from 2/11/09. #0 dna_pre_op (pb=0x9c48460, modtype=4) at ldap/servers/plugins/dna/dna.c:2636 #1 0x0017c0a1 in plugin_call_func (list=0x9a14070, operation=405, pb=0x9c48460, call_one=0) at ldap/servers/slapd/plugin.c:1369 #2 0x0017c2ae in plugin_call_plugins (pb=0x9c48460, whichfunction=405) at ldap/servers/slapd/plugin.c:1331 #3 0x0016fb7c in op_shared_modify (pb=0x9c48460, pw_change=0, old_pw=0x0) at ldap/servers/slapd/modify.c:777 #4 0x001711bc in do_modify (pb=0x9c48460) at ldap/servers/slapd/modify.c:341 #5 0x08058157 in connection_threadmain () at ldap/servers/slapd/connection.c:502 #6 0x00927f81 in ?? () from /lib/libnspr4.so #7 0x00bd532f in start_thread () from /lib/libpthread.so.0 #8 0x00af220e in clone () from /lib/libc.so.6 (gdb) print bv $1 = (struct berval *) 0x0
Created attachment 333377 [details] DS DNA patch
Tested 3 scenarios, 2 passed: 1. PASS dn: cn=foo,cn=groups,cn=accounts,dc=example,dc=com changetype: modify delete: gidnumber 2. PASS dn: cn=foo,cn=groups,cn=accounts,dc=example,dc=com changetype: modify replace: gidnumber 3. FAIL dn: cn=foo,cn=groups,cn=accounts,dc=example,dc=com changetype: modify delete: gidnumber gidnumber: 1103 The entry looks like this: dn: cn=foo,cn=groups,cn=accounts,dc=example,dc=com objectClass: top objectClass: groupofnames objectClass: posixGroup objectClass: inetUser description: foo cn: foo gidNumber: 1103 I'm attached to the slapd process but not getting a backtrace when it quits, just: [Thread 0xb4c21b90 (LWP 31146) exited] [ a slew more ] [Thread 0xb6023b90 (LWP 31144) exited] Program exited with code 0177.
Created attachment 333386 [details] Revised DS DNA patch
All my tests pass now
Checked into ldapserver (HEAD). Thanks to Rich for his review, and to Rob for his testing! Checking in ldap/servers/plugins/dna/dna.c; /cvs/dirsec/ldapserver/ldap/servers/plugins/dna/dna.c,v <-- dna.c new revision: 1.17; previous revision: 1.16 done
Rob -Nathan - can I get a bit of information on the setup for this bug? I would like to add regression tests to the automated acceptance tests. How was the original group assigned its gidNumber - I don't want to assume via DNA plugin? Thanks Jenny
gidnumber was assigned by DNA when the group entry was created during my testing.
thanks Rich!
fix verified - RHEL 4 - DS 8.1 - scenarios above do not crash the server and new gidNumbers are assigned.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-0455.html