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

RE: DN/AD crash in HEAD



Title: RE: DN/AD crash in HEAD

0x65726944 looks suspciously like ASCII to me,
   e r i D
When using Intel little endian goofiness, "Dire", which might be part of "Directory"(?)
also, bv_val = 0x6567616e, have fun with the rest, there are more that look like ascii.
                  e g a n

As for why it's getting stomped, I'm stumped.
(Sorry if that's quite obvious, and I didn't help matters any.)

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Monday, February 11, 2002 3:56 PM
To: openldap-devel@OpenLDAP.org
Subject: DN/AD crash in HEAD


I'm seeing this on both Linux and FreeBSD in the DN/AD code.
After many successful binds with the rootdn, I get:

#0  0x8072839 in slap_bv2ad (bv=0xa1e7ae0, ad=0xa188e74, text=0xa188e78)
    at ad.c:263
263                     if( d2->ad_flags != desc.ad_flags ) {
(gdb) where
#0  0x8072839 in slap_bv2ad (bv=0xa1e7ae0, ad=0xa188e74, text=0xa188e78)
    at ad.c:263
#1  0x805d54f in LDAPDN_rewrite (dn=0xa1e7b00, flags=1) at dn.c:247
#2  0x805db35 in dnPrettyNormal (syntax=0x0, val=0xa188f30, pretty=0xa188f08,
    normal=0xa188f10) at dn.c:482
#3  0x8061687 in do_bind (conn=0x8152ce4, op=0x8138700) at bind.c:155
#4  0x8050424 in connection_operation (arg_v=0x8104be0) at connection.c:936
#5  0x80a003a in ldap_int_thread_pool_wrapper (pool=0x80f2300) at tpool.c:402
#6  0x2829810b in _thread_start () from /usr/lib/libc_r.so.4
#7  0x0 in ?? ()
(gdb) print *d2
Cannot access memory at address 0x65726944.
(gdb) print desc
$2 = {ad_next = 0x0, ad_type = 0x80fac80, ad_cname = {bv_len = 1,
    bv_val = 0xa1e7af8 "c"}, ad_lang = {bv_len = 0, bv_val = 0x0},
  ad_flags = 0}
(gdb) print *desc.ad_type
$4 = {sat_atype = {at_oid = 0x80fb5a0 "2.5.4.6", at_names = 0x80fb5e0,
    at_desc = 0x80fc240 "RFC2256: ISO-3166 country 2-letter code",
    at_obsolete = 0, at_sup_oid = 0x80fb5b0 "name", at_equality_oid = 0x0,
    at_ordering_oid = 0x0, at_substr_oid = 0x0, at_syntax_oid = 0x0,
    at_syntax_len = 0, at_single_value = 1, at_collective = 0,
    at_no_user_mod = 0, at_usage = 0, at_extensions = 0x0}, sat_cname = {
    bv_len = 1, bv_val = 0x80fb5c0 "c"}, sat_sup = 0x80fa800,
  sat_subtypes = 0x0, sat_equality = 0x80f44c0, sat_approx = 0x80f43c0,
  sat_ordering = 0x0, sat_substr = 0x80f4540, sat_syntax = 0x80f2880,
  sat_check = 0, sat_flags = 0, sat_next = 0x80fad00, sat_ad = 0x812aaa0,
  sat_ad_mutex = 0x80fc280}
(gdb) print *desc.ad_type.sat_ad
$5 = {ad_next = 0x65726944, ad_type = 0x726f7463, ad_cname = {
    bv_len = 1632444537,
    bv_val = 0x6567616e <Address 0x6567616e out of bounds>}, ad_lang = {
    bv_len = 114, bv_val = 0x0}, ad_flags = 0}

The preceding operation (on a separate connection) was
a failed modify/add w/ zero values from the rootdn.  (this
might be completely irrelevant).

Any thoughts?

Kurt