[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#3407) run ldapdelete with log output, slapd core dumped
> However there's a couple of quick checks you can make: is there any
> attribute in your mapping with an empty delete rule in ldap_at_mappings?
I had did the test with all the default stable *.sql definition, but the
SLAPD still core dumped on my solaris9 environment.
Yesterday I had only inserted one attribute (userpassword) to ldap_attr_mappings,
and hadn't touch the other definition of test_metadata.sql/testdb_create.sql
> the problem should be related with your system's vsnprintf()
> that doesn't like NULL string values (because it applies strlen()
> without checking.
Maybe problem is like your diagnosis.
By gdb, I think I cannot get more useful information than by xcrash tool.
----------
do_delete
ber_scanf fmt (m) ber:
ber_dump: buf=0x000f6448 ptr=0x000f644b end=0x000f645f len=20
0000: 4a 12 63 6e 3d 74 65 73 74 2c 6f 3d 66 6a 68 2c J.cn=test,o=fjh,
0010: 63 3d 6a 70 c=jp
>>> dnPrettyNormal: <cn=test,o=fjh,c=jp>
=> ldap_bv2dn(cn=test,o=fjh,c=jp,0)
ldap_err2string
<= ldap_bv2dn(cn=test,o=fjh,c=jp)=0 Success
=> ldap_dn2bv(272)
ldap_err2string
<= ldap_dn2bv(cn=test,o=fjh,c=jp)=0 Success
=> ldap_dn2bv(272)
ldap_err2string
<= ldap_dn2bv(cn=test,o=fjh,c=jp)=0 Success
<<< dnPrettyNormal: <cn=test,o=fjh,c=jp>, <cn=test,o=fjh,c=jp>
conn=0 op=1 DEL dn="cn=test,o=fjh,c=jp"
==>backsql_delete(): deleting entry "cn=test,o=fjh,c=jp"
=> access_allowed: write access to "o=fjh,c=jp" "children" requested
<= root access granted
==>backsql_get_db_conn()
==>backsql_open_db_conn()
daemon: select: listen=10 active_threads=0 tvp=NULL
backsql_open_db_conn(): connected, adding to tree
<==backsql_open_db_conn()
<==backsql_get_db_conn()
==>backsql_dn2id(): dn="cn=test,o=fjh,c=jp"
id_query "SELECT id,keyval,oc_map_id FROM ldap_entries WHERE upper(dn)=upper(?)"
<==backsql_dn2id(): id=2 keyval=4 oc_id=1
==>backsql_count_children(): dn="cn=test,o=fjh,c=jp"
children id query "SELECT COUNT(distinct subordinates.id) FROM ldap_entries,ldap_entries subordi
nates WHERE subordinates.parent=ldap_entries.id AND upper(ldap_entries.dn)=upper(?)"
<==backsql_count_children(): 0
Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 3]
0xff0b347c in strlen () from /usr/lib/libc.so.1
(gdb) where
#0 0xff0b347c in strlen () from /usr/lib/libc.so.1
#1 0xff1059e8 in _doprnt () from /usr/lib/libc.so.1
#2 0xff1079cc in vsnprintf () from /usr/lib/libc.so.1
#3 0x000a906c in lutil_debug ()
#4 0x0007b130 in backsql_modify_delete_all_values ()
#5 0x0007fa18 in backsql_db_config ()
#6 0x00088354 in avl_delete ()
#7 0x0008833c in avl_delete ()
#8 0x0008833c in avl_delete ()
#9 0x0007fa58 in backsql_db_config ()
#10 0x0007fe78 in backsql_delete ()
#11 0x0003cd3c in do_delete ()
#12 0x0002a8f4 in connection_done ()
#13 0x0008b5c0 in ldap_pvt_thread_pool_destroy ()
#14 0xff065c9c in _lwp_start () from /usr/lib/libthread.so.1
#15 0xff065c9c in _lwp_start () from /usr/lib/libthread.so.1
Previous frame identical to this frame (corrupt stack?)
(gdb)
----------
regards
Pu
On Tue, 30 Nov 2004 10:56:44 GMT
masarati@aero.polimi.it wrote:
> I'll look at your log more in detail, but at a first glance it isn't of
> much help since I'm not familiar with it, and there is no clear
> indication of any reference to the line number where the crash happened.
> However there's a couple of quick checks you can make: is there any
> attribute in your mapping with an empty delete rule in ldap_at_mappings?
> If yes, the problem should be related with your system's vsnprintf()
> that doesn't like NULL string values (because it applies strlen()
> without checking. Later I'll add a check in back-sql and see if the
> problem still occurs.
>
> p.
>
> --
> Pierangelo Masarati tel: +39 02 2399 8309
> mail: pierangelo.masarati at polimi.it fax: +39 02 2399 8334
> http://www.aero.polimi.it/~masarati/
> Dipartimento di Ingegneria Aerospaziale, Politecnico di Milano
> via La Masa 34, 20156 Milano, Italy