Full_Name: David Schmitt Version: 2.4.23-5 OS: Debian squeeze URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.170.188.2) I'm seeing reproducible but inconsistent segfaults from within back-sql: #0 slap_sl_free (ptr=0x9cc440, ctx=0x98e270) at /home/devel/openldap/trunk/servers/slapd/sl_malloc.c:490 p = 0xffffffee009bc130 tmpp = <value optimized out> #1 0x00007ffff35f7877 in backsql_free_entryID (id=0x7ffff139d678, freeit=0, ctx=0x98e270) at /home/devel/openldap/trunk/servers/slapd/back-sql/entry-id.c:84 next = 0x0 __PRETTY_FUNCTION__ = "backsql_free_entryID" #2 0x00007ffff35f0ad8 in backsql_search (op=0x98b500, rs=0x7ffff139ea40) at /home/devel/openldap/trunk/servers/slapd/back-sql/search.c:2552 dbh = 0x965590 sres = <value optimized out> user_entry = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} base_entry = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} manageDSAit = 0 stoptime = 1285164120 bsi = {bsi_op = 0x98b500, bsi_rs = 0x7ffff139ea40, bsi_flags = 1, bsi_base_ndn = 0x98b538, bsi_use_subtree_shortcut = 0, bsi_base_id = {eid_id = 1, eid_keyval = 1, eid_oc_id = 1, eid_oc = 0x98bb50, eid_dn = {bv_len = 0, bv_val = 0x0}, eid_ndn = {bv_len = 18, bv_val = 0x9cc440 "ou=samba,ou=uni-ak"}, eid_next = 0x0}, bsi_scope = 2, bsi_filter = 0x9bbf98, bsi_stoptime = 1285164120, bsi_id_list = 0x0, bsi_id_listtail = 0x7ffff139d6d8, bsi_c_eid = 0x7ffff139d678, bsi_n_candidates = -2, bsi_status = 0, bsi_oc = 0x98b3f0, bsi_sel = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_from = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_join_where = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_flt_where = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_filter_oc = 0x0, bsi_dbh = 0x965590, bsi_attrs = 0x0, bsi_e = 0x0} eid = <value optimized out> lastid = 0 #3 0x00000000004355c9 in fe_op_search (op=0x98b500, rs=0x7ffff139ea40) at /home/devel/openldap/trunk/servers/slapd/search.c:366 bd = 0x7347e0 #4 0x0000000000435ddc in do_search (op=0x98b500, rs=0x7ffff139ea40) at /home/devel/openldap/trunk/servers/slapd/search.c:217 base = {bv_len = 18, bv_val = 0x9ac727 "ou=samba,ou=uni-ak"} siz = 0 i = 140737240492960 #5 0x0000000000433479 in connection_operation (ctx=0x7ffff139eba0, arg_v=<value optimized out>) at /home/devel/openldap/trunk/servers/slapd/connection.c:1109 rc = <value optimized out> cancel = <value optimized out> op = 0x98b500 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 = 0, 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 = 0x7ffff7f3b690 memctx = 0x98e270 memctx_null = 0x0 __PRETTY_FUNCTION__ = "connection_operation" #6 0x0000000000433c65 in connection_read_thread (ctx=<value optimized out>, argv=<value optimized out>) at /home/devel/openldap/trunk/servers/slapd/connection.c:1245 s = 14 I've configured back-sql with suffix 'ou=uni-ak' and am searching for '(&(cn=p0002001)(objectclass=sambasamaccount))' (which doesn't return results) within 'ou=samba,ou=uni-ak', which exists and has ~10k items in the whole tree. The segfault happens on the second such ldapsearch in the slapd's lifetime. Using a filter that returns multiple entries '(&(cn=x0004291)(objectclass=sambasamaccount))', back-sql segfaults already within the first query: #0 slap_sl_free (ptr=0x9dd7f8, ctx=0x98e270) at /home/devel/openldap/trunk/servers/slapd/sl_malloc.c:490 p = 0xffffffc9009cc582 tmpp = <value optimized out> #1 0x00007ffff35f7896 in backsql_free_entryID (id=0x9dd7f8, freeit=1, ctx=0x98e270) at /home/devel/openldap/trunk/servers/slapd/back-sql/entry-id.c:101 next = 0x0 __PRETTY_FUNCTION__ = "backsql_free_entryID" #2 0x00007ffff35f0ee7 in backsql_search (op=0x98b500, rs=0x7ffff139ea40) at /home/devel/openldap/trunk/servers/slapd/back-sql/search.c:2223 dbh = 0x965590 sres = <value optimized out> user_entry = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} base_entry = {e_id = 1, e_name = {bv_len = 18, bv_val = 0x9cc468 "ou=samba,ou=uni-ak"}, e_nname = {bv_len = 18, bv_val = 0x9cc490 "ou=samba,ou=uni-ak"}, e_attrs = 0x82e7b8, e_ocflags = 256, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} manageDSAit = 0 stoptime = 1285164373 bsi = {bsi_op = 0x98b500, bsi_rs = 0x7ffff139ea40, bsi_flags = 1, bsi_base_ndn = 0x98b538, bsi_use_subtree_shortcut = 0, bsi_base_id = {eid_id = 1, eid_keyval = 1, eid_oc_id = 1, eid_oc = 0x98bb50, eid_dn = {bv_len = 18, bv_val = 0x9cc3d8 "ou=samba,ou=uni-ak"}, eid_ndn = {bv_len = 18, bv_val = 0x9cc440 "ou=samba,ou=uni-ak"}, eid_next = 0x0}, bsi_scope = 2, bsi_filter = 0x9bbf98, bsi_stoptime = 1285164373, bsi_id_list = 0x9dcc18, bsi_id_listtail = 0x9dd838, bsi_c_eid = 0x9dd7f8, bsi_n_candidates = -5, bsi_status = 0, bsi_oc = 0x993690, bsi_sel = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_from = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_join_where = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_flt_where = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_filter_oc = 0x0, bsi_dbh = 0x965590, bsi_attrs = 0x0, bsi_e = 0x7ffff139d890} eid = 0x9dd7f8 lastid = 0 #3 0x00000000004355c9 in fe_op_search (op=0x98b500, rs=0x7ffff139ea40) at /home/devel/openldap/trunk/servers/slapd/search.c:366 bd = 0x7347e0 #4 0x0000000000435ddc in do_search (op=0x98b500, rs=0x7ffff139ea40) at /home/devel/openldap/trunk/servers/slapd/search.c:217 base = {bv_len = 18, bv_val = 0x9ac727 "ou=samba,ou=uni-ak"} siz = 0 i = 140737240492960 #5 0x0000000000433479 in connection_operation (ctx=0x7ffff139eba0, arg_v=<value optimized out>) at /home/devel/openldap/trunk/servers/slapd/connection.c:1109 rc = <value optimized out> cancel = <value optimized out> op = 0x98b500 rs = {sr_type = REP_SEARCH, sr_tag = 0, sr_msgid = 0, 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 = 3, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 1} tag = 99 opidx = SLAP_OP_SEARCH conn = 0x7ffff7f3b690 memctx = 0x98e270 memctx_null = 0x0 __PRETTY_FUNCTION__ = "connection_operation" #6 0x0000000000433c65 in connection_read_thread (ctx=<value optimized out>, argv=<value optimized out>) at /home/devel/openldap/trunk/servers/slapd/connection.c:1245 s = 14 A third query for a different mapped object class doesn't lead to a segfault at all (within the 15 tries I tested). I would not exclude an error in the schema mapping, but I'd prefer an error message instead of a segfault ;-) Thanks for your time and work, David
I've tried the same configuration with 2.4.11-1+lenny2 from lenny and it didn't segfault on my test-queries. Regards, David
Please - rebuild with -DSLAP_NO_SL_MALLOC=1 (you only need to recompile sl_malloc.c) - run slapd under valgrind --tool=memcheck --leak-check=full and minimal loglevel (e.g. -d stats) - send valgrind's output (if anything surfaces) Thanks, p.
changed state Open to Suspended
changed state Suspended to Feedback
changed notes
Hi, I've tried to rebuild the slapd (from the debian sources) with -DSLAP_NO_SL_MALLOC=1, but this build doesn't even manage to finish the test-suite which is automatically run. Please see the attached build log for details. The same source tree without -DSLAP_NO_SL_MALLOC=1 builds fine and finishes the test suite. I've tried inserting the valgrind call into the test suite without success. Then I built the package without the testsuite and used the resulting binaries for further tests. Sadly the segfault is not reproducible under -DSLAP_NO_SL_MALLOC=1. Please see the attached valgrind logs for runs with the default debian binaries and the re-compiled version. Best Regards, David
david@dasz.at wrote: > This is a multi-part message in MIME format. > --------------050908020600020509000208 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > Hi, > > I've tried to rebuild the slapd (from the debian sources) with > -DSLAP_NO_SL_MALLOC=1, but this build doesn't even manage to finish the > test-suite which is automatically run. You should never build code with this flag. It's for OpenLDAP developers only, and I personally am deeply opposed to its existence. Its effect on the code is fundamentally wrong. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
> To: david@dasz.at > Cc: openldap-its@openldap.org > > Please > > - rebuild with -DSLAP_NO_SL_MALLOC=1 (you only need to recompile sl_malloc.c) This is not helpful. As noted in #6691, the offending allocation is memory residing on the stack. Changing any malloc behavior will have no effect on any stack-based memory use. > - run slapd under valgrind --tool=memcheck --leak-check=full and minimal > loglevel (e.g. -d stats) > > - send valgrind's output (if anything surfaces) > > Thanks, p. > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On 11/5/2010 12:03 PM, Howard Chu wrote: > david@dasz.at wrote: >> This is a multi-part message in MIME format. >> --------------050908020600020509000208 >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> Content-Transfer-Encoding: 7bit >> >> Hi, >> >> I've tried to rebuild the slapd (from the debian sources) with >> -DSLAP_NO_SL_MALLOC=1, but this build doesn't even manage to finish the >> test-suite which is automatically run. > > You should never build code with this flag. It's for OpenLDAP developers > only, and I personally am deeply opposed to its existence. Its effect on > the code is fundamentally wrong. Dear Howard, does that mean I've wasted a day for nothing? Do you have any better ideas how to debug/fix the original issue? David -- dasz.at OG Tel: +43 (0)664 2602670 Web: http://dasz.at Klosterneuburg UID: ATU64260999 FB-Nr.: FN 309285 g FB-Gericht: LG Korneuburg
ITS#6691 seems to be same issue. I have a patch to fix this. It's available at: http://git.alpinelinux.org/cgit/aports.git/plain/main/openldap/openldap-back-sql-fix-64bit.patch - Timo
timo.teras@iki.fi wrote: > ITS#6691 seems to be same issue. > > I have a patch to fix this. > > It's available at: > http://git.alpinelinux.org/cgit/aports.git/plain/main/openldap/openldap-back-sql-fix-64bit.patch > > - Timo > > > Thanks for the patch, now in git master. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes changed state Feedback to Release moved from Incoming to Software Bugs
On Tue, Jun 14, 2011 at 08:16:18AM +0300, Timo Ter?s wrote: > On 06/13/2011 11:56 PM, Howard Chu wrote: > > timo.teras@iki.fi wrote: > >> ITS#6691 seems to be same issue. > >> > >> I have a patch to fix this. > >> > >> It's available at: > >> http://git.alpinelinux.org/cgit/aports.git/plain/main/openldap/openldap-back-sql-fix-64bit.patch > >> > > Thanks for the patch, now in git master. > > Good. Though, it would have been polite to credit me as the commit author. You were credited in the release branch. In the future use git format-patch and things like this won't get overlooked. > > Thanks, > Timo
On 06/14/2011 08:24 AM, hyc@symas.com wrote: > On Tue, Jun 14, 2011 at 08:16:18AM +0300, Timo Ter?s wrote: >> On 06/13/2011 11:56 PM, Howard Chu wrote: >>> timo.teras@iki.fi wrote: >>>> ITS#6691 seems to be same issue. >>>> >>>> I have a patch to fix this. >>>> >>>> It's available at: >>>> http://git.alpinelinux.org/cgit/aports.git/plain/main/openldap/openldap-back-sql-fix-64bit.patch >>>> >>> Thanks for the patch, now in git master. >> >> Good. Though, it would have been polite to credit me as the commit author. > > You were credited in the release branch. Oh, right. > In the future use git format-patch and things like this won't get overlooked. I did not have the git tree available on the 64-bit machine I was given to work with. And at that point I did not even know which version control you used. git commit does have --author="" switch, so it's very easy to set the patch author properly even if it's not in git patch format.
Timo Teräs wrote: > On 06/14/2011 08:24 AM, hyc@symas.com wrote: >> On Tue, Jun 14, 2011 at 08:16:18AM +0300, Timo Ter?s wrote: >>> On 06/13/2011 11:56 PM, Howard Chu wrote: >>>> timo.teras@iki.fi wrote: >>>>> ITS#6691 seems to be same issue. >>>>> >>>>> I have a patch to fix this. >>>>> >>>>> It's available at: >>>>> http://git.alpinelinux.org/cgit/aports.git/plain/main/openldap/openldap-back-sql-fix-64bit.patch >>>>> >>>> Thanks for the patch, now in git master. >>> >>> Good. Though, it would have been polite to credit me as the commit author. >> >> You were credited in the release branch. > > Oh, right. > >> In the future use git format-patch and things like this won't get overlooked. > > I did not have the git tree available on the 64-bit machine I was given > to work with. And at that point I did not even know which version > control you used. You are expected to have read this already before submitting code: http://www.openldap.org/devel/contributing.html -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes changed state Release to Closed
fixed in master fixed in RE24