At 05:51 PM 12/27/98 GMT, starder@rosinter.ru wrote:
>Full_Name: Alex Iliynsky
>Version: 1.1.1
>OS: FreeBSD 3.0/2.2.6
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (194.87.68.4)
>
>
>I have a one problem with 1.1.1 and I think that there is possible bug.
>
>My configuration (Freebsd 2.2.6/3.0 - doesn't matter)
>
>slapd.conf :
>
>#include  %SYSCONFDIR%/slapd.at.conf
>#include  %SYSCONFDIR%/slapd.oc.conf
>schemacheck off
>#referral ldap://ldap.itd.umich.edu
>
>#######################################################################
># ldbm database definitions
>#######################################################################
>
>database ldbm
>suffix  ""
>#suffix  "o=Your Organization Name, c=US"
>directory /usr/tmp
>rootdn  "cn=root, dc=home, dc=ri"
>#rootdn  "cn=root, o=Your Organization Name, c=US"
>rootpw  secret
>
>ldif file for creation of  initial database:
>
>dn: c=ru
>c: ru
>objectclass: country
>
>when I issued ldapsearch "objectclass=*" server does not respond at ALL.
>on next same search server dumped with segfault in strcasecmp (called from
>be_isroot()).

Please provide a back trace ('bt') from the segfault and relevant log
(-d 1) entries.

Hi there!

>>when I issued ldapsearch "objectclass=*" server does not respond at ALL.
>>on next same search server dumped with segfault in strcasecmp (called from
>>be_isroot()).
>
>Please provide a back trace ('bt') from the segfault and relevant log
>(-d 1) entries.

Backtrace from "gdb slapd slapd.core"

(gdb) bt
#0  0x280d818a in strcasecmp ()
#1  0x80501fe in be_isroot (be=0x8070800,
    dn=0xffffffff <Address 0xffffffff out of bounds>) at
backend.c:204
#2  0x8054b6a in acl_get_applicable (be=0x8070800, op=0x80a9380,
e=0x80a92c0,
    attr=0x8072210 "c", edn=0x80722c0 "C=RU", nmatch=10,
matches=0x80cbe60)
    at acl.c:119
#3  0x8050a33 in send_search_entry (be=0x8070800, conn=0x808740c,
    op=0x80a9380, e=0x80a92c0, attrs=0x0, attrsonly=0) at
result.c:250
#4  0x806095b in ldbm_back_search (be=0x8070800, conn=0x808740c,
op=0x80a9380,
    base=0x80721b0 "", scope=2, deref=0, slimit=499, tlimit=3600,
    filter=0x806e4a0, filterstr=0x80721d0 "(objectclass=*)",
attrs=0x0,
    attrsonly=0) at search.c:258
#5  0x804be25 in do_search (conn=0x808740c, op=0x80a9380) at
search.c:169
#6  0x804b4da in connection_operation (arg_v=0x8072180) at
connection.c:74
#7  0x2809238e in _thread_start ()
(gdb)

redirection of "slapd -f slapd.conf -d 1"

slapd 1.1.1-Release (    27     1998 19:03:49 MSK)
        starder@cannon:/usr/home/starder/111/ldap/servers/slapd
slapd starting
do_bind
do_bind: version 2 dn () method 128
send_ldap_result 0::
do_search
select_backend: use default backend
using base
subtree_candidates: base:
=> filter_candidates
=> list_candidates 0xa1
=> filter_candidates
=> ava_candidates 0xa3
=> index_read( "objectclass" "=" "REFERRAL" )
=> ldbm_cache_open( "/usr/tmp/objectclass.dbb", 514, 600 )
<= ldbm_cache_open (opened 0)
<= index_read 0 candidates
<= ava_candidates 0
<= filter_candidates 0
=> filter_candidates
=> presence_candidates
=> index_read( "objectclass" "^@" "*" )
<= index_read 2 candidates (allids - not indexed)
<= presence_candidates 2
<= filter_candidates 2
<= list_candidates 2
<= filter_candidates 2
=> id2entry_r( 1 )
=> ldbm_cache_open( "/usr/tmp/id2entry.dbb", 514, 600 )
<= ldbm_cache_open (opened 1)
=> str2entry
<= str2entry 0x80a92c0
<= id2entry_r( 1 ) (disk)
/* At this point, op already changed. i think it's occured in
id2entry_r */
=> send_search_entry (c=ru)
<= send_search_entry
====> cache_return_entry_r
send_ldap_result 0::
slapd in free(): warning: junk pointer, too high to make sense. /* 
warning while delete_op()*/
ber_get_next on fd 7 failed errno 0 (Undefined error: 0)
*** got 0 of 0 so far
/* ldapsearch still waiting for result ..... killed */
/* Second execution of ldapsearch -h host -b "" "objectclass=*" */
do_bind
do_bind: version 2 dn () method 128
send_ldap_result 0::
do_search
select_backend: use default backend
using base
subtree_candidates: base:
subtree_candidates: base:
=> filter_candidates
=> list_candidates 0xa1
=> filter_candidates
=> ava_candidates 0xa3
=> index_read( "objectclass" "=" "REFERRAL" )
=> ldbm_cache_open( "/usr/tmp/objectclass.dbb", 514, 600 )
<= ldbm_cache_open (cache 0)
<= index_read 0 candidates
<= ava_candidates 0
<= filter_candidates 0
=> filter_candidates
=> presence_candidates
=> index_read( "objectclass" "^@" "*" )
<= index_read 2 candidates (allids - not indexed)
<= presence_candidates 2
<= filter_candidates 2
<= list_candidates 2
<= filter_candidates 2
=> id2entry_r( 1 )
====> cache_find_entry_dn2id: found id: 1 rw: 0
<= id2entry_r 0x80a92c0 (cache)
=> send_search_entry (c=ru)
/* core dumped. Segfault on 2.2.6 and Bus error on 3.0*/

BTW 1.0 and 1.1 as i wrote, working fine with the same config and the
same database.
Alex Iliynsky [starder@rosinter.ru] FIDO 2:5020/23.0@fidonet.org
JV RosInter Communication and Network Department

At 10:03 PM 12/27/98 GMT, starder@rosinter.ru wrote:
>BTW 1.0 and 1.1 as i wrote, working fine with the same config and the
>same database.

It is interesting that you do not see this with OpenLDAP 1.1.0.
I ask you double check your prior tests and make sure the slapd.conf
and initial LDIF data is the same.  You might also see if you can
duplicate it --without-threads.

The only difference I can find between 1.1.0 and 1.1.1 that impacts
searches is the realBase handling in ldbm_back_search().   In 1.1.0,
there was an extraneous free() and realbase was being leaked.  The
extraneous free() was removed and many of the realbase leaks plugged.
It might be interesting to see if this change (applied to 1.1.0 and/or
backed out of 1.1.1) has any impact upon the results.
  http://www.OpenLDAP.org/devel/cvsweb.cgi/servers/slapd/back-ldbm/search.c.diff?r1=1.7.2.6&r2=1.7.2.7

Kurt

moved from Incoming to Software

>At 10:03 PM 12/27/98 GMT, starder@rosinter.ru wrote:
>>BTW 1.0 and 1.1 as i wrote, working fine with the same config and the
>>same database.
>
>It is interesting that you do not see this with OpenLDAP 1.1.0.
>I ask you double check your prior tests and make sure the slapd.conf
>and initial LDIF data is the same.  You might also see if you can
>duplicate it --without-threads.

I running different version, specifying slapd.conf placed in 1.1.1
directory. so all of version have the same config and the same database. I
just compiled 1.1.1 --without-threads. Result is the same.


>The only difference I can find between 1.1.0 and 1.1.1 that impacts
>searches is the realBase handling in ldbm_back_search().   In 1.1.0,
>there was an extraneous free() and realbase was being leaked.  The
>extraneous free() was removed and many of the realbase leaks plugged.
>It might be interesting to see if this change (applied to 1.1.0 and/or
>backed out of 1.1.1) has any impact upon the results.
>
http://www.OpenLDAP.org/devel/cvsweb.cgi/servers/slapd/back-ldbm/search.c.di
ff?r1=1.7.2.6&r2=1.7.2.7


Looks like my code alredy have this patch applied - i got it from
openldap.org in day where i wrote a first message.

Dammit! I've found a bug :)

back-ldbm/search.c - call to subtree_candidate with UNINITIALIZED char *
matched.
On exit, where nothing was found, matched still NOT NULL and on following
call free(matched), arbitraty data (in my case, it was Op structure -
garbage was left on stack by previous call ) will freed. Any next calloc
will owerwrite op structure and cause unpredictable results.

So - just init matched on declare time

char    *    matched = NULL;

I've tested my configuration with this patch. all ok. I don't know, why this
error was not occured in 1.0 and 1.1.1 :) Maybe the moon was in proper stage
while you wrote 1.1 :)


P.S. as i noticed, all calls to functions that has a matched-like pointer in
args preceed by setting matched to NULL.
-----Original Message-----
From: Kurt D. Zeilenga <Kurt@OpenLDAP.Org>
To: starder@rosinter.ru <starder@rosinter.ru>
Cc: openldap-its@OpenLDAP.Org <openldap-its@OpenLDAP.Org>
Date: 28 äåêàáðÿ 1998 ã. 2:58
Subject: Re: SEGFAULT with NULL backend suffix definition (ITS#23)


>At 10:03 PM 12/27/98 GMT, starder@rosinter.ru wrote:
>>BTW 1.0 and 1.1 as i wrote, working fine with the same config and the
>>same database.
>
>It is interesting that you do not see this with OpenLDAP 1.1.0.
>I ask you double check your prior tests and make sure the slapd.conf
>and initial LDIF data is the same.  You might also see if you can
>duplicate it --without-threads.
>
>The only difference I can find between 1.1.0 and 1.1.1 that impacts
>searches is the realBase handling in ldbm_back_search().   In 1.1.0,
>there was an extraneous free() and realbase was being leaked.  The
>extraneous free() was removed and many of the realbase leaks plugged.
>It might be interesting to see if this change (applied to 1.1.0 and/or
>backed out of 1.1.1) has any impact upon the results.
>
http://www.OpenLDAP.org/devel/cvsweb.cgi/servers/slapd/back-ldbm/search.c.di
ff?r1=1.7.2.6&r2=1.7.2.7
>
>Kurt
>
>

>Dammit! I've found a bug :)
>
>back-ldbm/search.c - call to subtree_candidate with UNINITIALIZED char *
>matched.
>On exit, where nothing was found, matched still NOT NULL and on following
>call free(matched), arbitraty data (in my case, it was Op structure -
>garbage was left on stack by previous call ) will freed. Any next calloc
>will owerwrite op structure and cause unpredictable results.
>
>So - just init matched on declare time
>
>char    *    matched = NULL;


I drop another look to code, and think, that best place to init matched -
subtree_candidates before dn2entry_r(). But it can depends..

Alex Iliynsky wrote:
> 
> >Dammit! I've found a bug :)
> >
> >back-ldbm/search.c - call to subtree_candidate with UNINITIALIZED char *
> >matched.
> >On exit, where nothing was found, matched still NOT NULL and on following
> >call free(matched), arbitraty data (in my case, it was Op structure -
> >garbage was left on stack by previous call ) will freed. Any next calloc
> >will owerwrite op structure and cause unpredictable results.
> >
> >So - just init matched on declare time
> >
> >char    *    matched = NULL;
> 
> I drop another look to code, and think, that best place to init matched -
> subtree_candidates before dn2entry_r(). But it can depends..

I've just initialized matched where declared in ldbm_back_search() to NULL as
dn2entry_r() may never be reached.   See search.c rev 1.18.

Kurt

Confirmed, this fixes my segfaulting as well.

line 52 :changed to
	char		*matched = NULL;
in back-ldbm/search.c

Well done and many thanks to all, 

happy new year (1.1.2????)

regards

alan

starder@rosinter.ru wrote:
> 
> Dammit! I've found a bug :)
> 
> back-ldbm/search.c - call to subtree_candidate with UNINITIALIZED char *
> matched.
> On exit, where nothing was found, matched still NOT NULL and on following
> call free(matched), arbitraty data (in my case, it was Op structure -
> garbage was left on stack by previous call ) will freed. Any next calloc
> will owerwrite op structure and cause unpredictable results.
> 
> So - just init matched on declare time
> 
> char    *    matched = NULL;
> 
> I've tested my configuration with this patch. all ok. I don't know, why this
> error was not occured in 1.0 and 1.1.1 :) Maybe the moon was in proper stage
> while you wrote 1.1 :)
> 
> P.S. as i noticed, all calls to functions that has a matched-like pointer in
> args preceed by setting matched to NULL.
> -----Original Message-----
> From: Kurt D. Zeilenga <Kurt@OpenLDAP.Org>
> To: starder@rosinter.ru <starder@rosinter.ru>
> Cc: openldap-its@OpenLDAP.Org <openldap-its@OpenLDAP.Org>
> Date: 28 麧罻摫� 1998 �. 2:58
> Subject: Re: SEGFAULT with NULL backend suffix definition (ITS#23)
> 
> >At 10:03 PM 12/27/98 GMT, starder@rosinter.ru wrote:
> >>BTW 1.0 and 1.1 as i wrote, working fine with the same config and the
> >>same database.
> >
> >It is interesting that you do not see this with OpenLDAP 1.1.0.
> >I ask you double check your prior tests and make sure the slapd.conf
> >and initial LDIF data is the same.  You might also see if you can
> >duplicate it --without-threads.
> >
> >The only difference I can find between 1.1.0 and 1.1.1 that impacts
> >searches is the realBase handling in ldbm_back_search().   In 1.1.0,
> >there was an extraneous free() and realbase was being leaked.  The
> >extraneous free() was removed and many of the realbase leaks plugged.
> >It might be interesting to see if this change (applied to 1.1.0 and/or
> >backed out of 1.1.1) has any impact upon the results.
> >
> http://www.OpenLDAP.org/devel/cvsweb.cgi/servers/slapd/back-ldbm/search.c.di
> ff?r1=1.7.2.6&r2=1.7.2.7
> >
> >Kurt
> >
> >

-- 
------------------// Alan's Signature //--------------------
If the answers not at http://www.hk.super.net/~alan_k , then 
let me now, CAUSE IT'S SUPPOSED TO BE!
-----------// Alan's Linux Infomation Center //-------------

changed notes
changed state Open to Test

changed notes
changed state Test to Release

changed notes
changed state Release to Closed

moved from Software to Software Bugs

Fixed in rev 1.18 of back-ldbm/search.c
Released with 1.1.2