Issue 6556 - component_match: test031 core dumps after applying first filter
Summary: component_match: test031 core dumps after applying first filter
Status: VERIFIED DUPLICATE of issue 6210
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-23 13:29 UTC by dieter@dkluenter.de
Modified: 2020-03-19 19:51 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description dieter@dkluenter.de 2010-05-23 13:29:29 UTC
Full_Name: Dieter Kluenter
Version: HEAD
OS: openSuSE
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (84.142.11.71)


I have enabled slapd-modules/comp_match and properly installed all relevant
files to tests/data/comp_libs. When running test031, slapd segfaults:

Running ./scripts/test031-component-filter for bdb...
running defines.sh
Running slapadd to build slapd database...
Running slapindex to index slapd database...
Starting slapd on TCP/IP port 9011...
Testing slapd searching...
Testing Component Filter Match RFC3687 Certificate searching:
        f=(userCertificate:componentFilterMatch:=item:{ component
"toBeSigned.serialNumber", rule allComponen
tsMatch, value 0 }) ...
        f=(userCertificate:componentFilterMatch:=item:{ component
"toBeSigned.version", rule allComponentsMat
ch, value 2 }) ...
./scripts/test031-component-filter: Zeile 105:  5312 Speicherzugriffsfehler 
(Speicherabzug geschrieben) $SLA
PD -f $ADDCONF -h $URI1 -d $LVL $TIMING > $LOG1 2>&1
ldapsearch failed (255)!
./scripts/test031-component-filter: Zeile 110: kill: (5312) - Kein passender
Prozess gefunden

(gdb) core-file core
Core was generated by `/home/dieter/build/openldap/servers/slapd/.libs/lt-slapd
-s0 -f /home/dieter/bu'.
Program terminated with signal 11, Segmentation fault.
(gdb) file /home/dieter/build/openldap/servers/slapd/.libs/lt-slapd 
Reading symbols from
/home/dieter/build/openldap/servers/slapd/.libs/lt-slapd...done.
(gdb) where
#0  0x080e6525 in slap_sl_free (ptr=0x87ba173, ctx=0x89aa3c0) at
sl_malloc.c:492
#1  0x080a0f5b in ch_free (ptr=0x87ba173) at ch_malloc.c:137
#2  0x080e3e3a in mra_free (op=0x89adc80, mra=0x87ba218, freeit=1) at mra.c:43
#3  0x08085621 in filter_free_x (op=0x89adc80, f=0x87ba258, freeme=1) at
filter.c:556
#4  0x0808373e in do_search (op=0x89adc80, rs=0xb71190c4) at search.c:230
#5  0x080805f9 in connection_operation (ctx=0xb7119198, arg_v=0x89adc80) at
connection.c:1109
#6  0x08080b18 in connection_read_thread (ctx=0xb7119198, argv=0x11) at
connection.c:1245
#7  0xb7f963b7 in ?? ()
#8  0xb7cf86e5 in ?? ()

(gdb) bt full
#0  0x080e6525 in slap_sl_free (ptr=0x87ba173, ctx=0x89aa3c0) at
sl_malloc.c:492
        sh = 0x89aa3c0
        size = 543520108
        p = 0x87ba16f
        nextp = 0x28e116db
        tmpp = 0xb7119198
        __PRETTY_FUNCTION__ = "slap_sl_free"
#1  0x080a0f5b in ch_free (ptr=0x87ba173) at ch_malloc.c:137
        ctx = 0x89aa3c0
#2  0x080e3e3a in mra_free (op=0x89adc80, mra=0x87ba218, freeit=1) at mra.c:43
No locals.
#3  0x08085621 in filter_free_x (op=0x89adc80, f=0x87ba258, freeme=1) at
filter.c:556
        p = 0x8214680
        next = 0x89adcac
#4  0x0808373e in do_search (op=0x89adc80, rs=0xb71190c4) at search.c:230
        base = {bv_len = 17, bv_val = 0x89aff28 "dc=example,dc=com"}
        siz = 0
        off = 0
        i = 0
#5  0x080805f9 in connection_operation (ctx=0xb7119198, arg_v=0x89adc80) at
connection.c:1109
        rc = 80
        cancel = 0
        op = 0x89adc80
        rs = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 2, sr_err = 0,
sr_matched = 0x0, 
          sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search =
{r_entry = 0x0, 
              r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0,
r_nentries = 2, r_v2ref = 0x0}, 
            sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0,
r_rspdata = 0x0}}, sr_flags = 0}
        tag = 99
        opidx = SLAP_OP_SEARCH
        conn = 0x8433e04
        memctx = 0x89aa3c0
        memctx_null = 0x0
        memsiz = 1048576
        __PRETTY_FUNCTION__ = "connection_operation"
#6  0x08080b18 in connection_read_thread (ctx=0xb7119198, argv=0x11) at
connection.c:1245
---Type <return> to continue, or q <return> to quit---
        rc = 0
        cri = {op = 0x89adc80, func = 0, arg = 0x0, ctx = 0xb7119198, nullop =
0}
        s = 17
#7  0xb7f963b7 in ?? ()
No symbol table info available.
#8  0xb7cf86e5 in ?? ()
No symbol table info available.
(gdb) 

-Dieter

Comment 1 dieter@dkluenter.de 2010-05-27 10:12:33 UTC
Hi,
I have run slapd in valgrind now, which produced following error:

==15353== 1 errors in context 1 of 5:
==15353== Invalid write of size 4
==15353==    at 0x80E64B5: slap_sl_free (sl_malloc.c:492)
==15353==    by 0x80A0EEA: ch_free (ch_malloc.c:137)
==15353==    by 0x80E3DC9: mra_free (mra.c:43)
==15353==    by 0x80855B0: filter_free_x (filter.c:556)
==15353==    by 0x80836CD: do_search (search.c:230)
==15353==    by 0x8080588: connection_operation (connection.c:1109)
==15353==    by 0x403B376: ldap_int_thread_pool_wrapper (tpool.c:685)
==15353==    by 0x43046E4: start_thread (in /lib/libpthread-2.10.1.so)
==15353==    by 0x43045FF: ??? (in /lib/libpthread-2.10.1.so)
==15353==  Address 0x843692b1 is not stack'd, malloc'd or (recently)
free'd

Full valgrind log can be found at
http://pastebin.de/6914

-Dieter

Comment 2 dieter@dkluenter.de 2010-05-27 10:30:51 UTC
Hi,
I have run slapd in valgrind now. The full log kan be found here:
http://pastebin.de/6914
In short, valgrind reported following error:
 
=15353== 1 errors in context 1 of 5:
==15353== Invalid write of size 4
==15353==    at 0x80E64B5: slap_sl_free (sl_malloc.c:492)
==15353==    by 0x80A0EEA: ch_free (ch_malloc.c:137)
==15353==    by 0x80E3DC9: mra_free (mra.c:43)
==15353==    by 0x80855B0: filter_free_x (filter.c:556)
==15353==    by 0x80836CD: do_search (search.c:230)
==15353==    by 0x8080588: connection_operation (connection.c:1109)
==15353==    by 0x403B376: ldap_int_thread_pool_wrapper (tpool.c:685)
==15353==    by 0x43046E4: start_thread (in /lib/libpthread-2.10.1.so)
==15353==    by 0x43045FF: ??? (in /lib/libpthread-2.10.1.so)
==15353==  Address 0x843692b1 is not stack'd, malloc'd or (recently) free'd

-Dieter

-- 
Dieter Klünter | Systemberatung
sip: +49.40.20932173
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6

Comment 3 ando@openldap.org 2010-09-30 12:34:56 UTC
changed notes
Comment 4 ian@uns.ac.rs 2010-11-15 12:25:09 UTC
slap_sl_free dumps core here because it gets passed a bogus bv_val (from 
the ma_value field of an instance of struct MatchingRuleAssertion). As far 
as I can see, the original bv_val gets clobbered in get_comp_filter 
(servers/slapd/component.c), line 350:

     bv->bv_val = cav.cav_ptr;

Commenting that line out fixes the core dump. I suspect that the 
assignment is there to support nested component filters (see lines 1039 et 
seq. in the same file).

Earlier versions of OpenLDAP had different logic in slap_sl_free, which 
skipped the offending pointer (and thus probably leaving a memory leak).

i.

Comment 5 OpenLDAP project 2014-08-01 21:03:45 UTC
comp_match
Comment 6 Quanah Gibson-Mount 2017-03-28 00:17:08 UTC
moved from Incoming to Software Bugs
Comment 7 Quanah Gibson-Mount 2020-03-19 19:51:47 UTC

*** This issue has been marked as a duplicate of issue 6210 ***