Issue 6892 - Segfault in Syncprov overlay
Summary: Segfault in Syncprov overlay
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: 2.4.25
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-06 23:41 UTC by ghola@rebelbase.com
Modified: 2014-08-01 21:04 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 ghola@rebelbase.com 2011-04-06 23:41:27 UTC
Full_Name: Duncan Idaho
Version: 2.4.25
OS: RHEL 5.5
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (204.10.36.147)


In my configuration slapd segfaults within a few hours repeatably when a NULL
value is somehow passed as a filter to test_filter in the syncprov overlay.

I'm running "threads 64" as I have 62 consumers connecting and this was required
to prevent unrelated searches from timing out when all the consumers connect at
once.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x59832940 (LWP 2042)]
test_filter (op=0x59830770, e=0x2aab11861068, f=0x0) at filterentry.c:69
69              if ( f->f_choice & SLAPD_FILTER_UNDEFINED ) {
(gdb) bt
#0  test_filter (op=0x59830770, e=0x2aab11861068, f=0x0) at filterentry.c:69
#1  0x00000000004db315 in syncprov_matchops (op=0x59831130, opc=0xbc91750,
saveit=1) at syncprov.c:1314
#2  0x00000000004db6b5 in syncprov_op_mod (op=0x59831130, rs=<value optimized
out>) at syncprov.c:2124
#3  0x000000000047e62a in overlay_op_walk (op=0x59831130, rs=0x59830f40,
which=op_modify, oi=0x8d7b50, on=0x8dc540) at backover.c:659
#4  0x000000000047ec07 in over_op_func (op=0x59831130, rs=0x59830f40,
which=op_modify) at backover.c:721
#5  0x000000000047404d in syncrepl_updateCookie (si=0x8d74e0, op=0x59831130,
syncCookie=0x59831aa0) at syncrepl.c:3292
#6  0x0000000000479d0d in do_syncrep2 (ctx=<value optimized out>, arg=<value
optimized out>) at syncrepl.c:959
#7  do_syncrepl (ctx=<value optimized out>, arg=<value optimized out>) at
syncrepl.c:1455
#8  0x000000000041f7aa in connection_read_thread (ctx=0x59831d70, argv=<value
optimized out>) at connection.c:1251
#9  0x00000000004ec5ec in ldap_int_thread_pool_wrapper (xpool=0x84de50) at
tpool.c:685
#10 0x000000301b20673d in start_thread (arg=<value optimized out>) at
pthread_create.c:301
#11 0x000000301aad44bd in clone () from /lib64/libc.so.6

Let me know if I can provide more info.
Comment 1 ghola@rebelbase.com 2011-04-08 01:21:44 UTC
More information; This server is both a producer and a consumer.

Here are the logs preceeding the crash:

Apr  8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp:
cookie=rid=001,csn=20110408005040.759389Z#000000#000#000000
Apr  8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp:
cookie=rid=001,csn=20110408005040.759389Z#000000#000#000000
Apr  8 00:50:40 test-ldap01 slapd[8732]: conn=1007 op=1 ENTRY
dn="widget=ldap02,ou=widgets,dc=domain,dc=net"
Apr  8 00:50:40 test-ldap01 slapd[8732]: conn=1005 op=1 ENTRY
dn="widget=ldap02,ou=widgets,dc=domain,dc=net"
Apr  8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp:
cookie=rid=001,csn=20110408005040.759389Z#000000#000#000000
Apr  8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp:
cookie=rid=001,csn=20110408005040.759389Z#000000#000#000000
Apr  8 00:50:40 test-ldap01 slapd[8732]: conn=1004 op=1 ENTRY
dn="widget=ldap02,ou=widgets,dc=domain,dc=net"
Apr  8 00:50:40 test-ldap01 slapd[8732]: conn=1003 op=1 ENTRY
dn="widget=ldap02,ou=widgets,dc=domain,dc=net"
Apr  8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp:
cookie=rid=001,csn=20110408005040.759389Z#000000#000#000000
Apr  8 00:50:40 test-ldap01 slapd[8732]: conn=1002 op=1 ENTRY
dn="widget=ldap02,ou=widgets,dc=domain,dc=net"
Apr  8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp:
cookie=rid=001,csn=20110408005040.759389Z#000000#000#000000
Apr  8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp:
cookie=rid=001,csn=20110408005040.759389Z#000000#000#000000
Apr  8 00:50:40 test-ldap01 slapd[8732]: conn=1001 op=1 ENTRY
dn="widget=ldap02,ou=widgets,dc=domain,dc=net"
Apr  8 00:50:40 test-ldap01 slapd[8732]: slap_graduate_commit_csn: removing
0x20494b70 20110408005040.759389Z#000000#000#000000
Apr  8 00:50:40 test-ldap01 slapd[8732]: conn=1000 op=1 ENTRY
dn="widget=ldap02,ou=widgets,dc=domain,dc=net"
Apr  8 00:50:40 test-ldap01 slapd[8732]: syncrepl_entry: rid=001 be_modify
widget=ldap02,ou=widgets,dc=domain,dc=net (0)
Apr  8 00:50:40 test-ldap01 slapd[8732]: slap_queue_csn: queing 0x2055d810
20110408005040.759389Z#000000#000#000000
Comment 2 Howard Chu 2011-06-10 08:59:17 UTC
ghola@rebelbase.com wrote:
> Full_Name: Duncan Idaho
> Version: 2.4.25
> OS: RHEL 5.5
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (204.10.36.147)
>
>
> In my configuration slapd segfaults within a few hours repeatably when a NULL
> value is somehow passed as a filter to test_filter in the syncprov overlay.
>
> I'm running "threads 64" as I have 62 consumers connecting and this was required
> to prevent unrelated searches from timing out when all the consumers connect at
> once.
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x59832940 (LWP 2042)]
> test_filter (op=0x59830770, e=0x2aab11861068, f=0x0) at filterentry.c:69
> 69              if ( f->f_choice&  SLAPD_FILTER_UNDEFINED ) {
> (gdb) bt
> #0  test_filter (op=0x59830770, e=0x2aab11861068, f=0x0) at filterentry.c:69
> #1  0x00000000004db315 in syncprov_matchops (op=0x59831130, opc=0xbc91750,
> saveit=1) at syncprov.c:1314
> #2  0x00000000004db6b5 in syncprov_op_mod (op=0x59831130, rs=<value optimized
> out>) at syncprov.c:2124
> #3  0x000000000047e62a in overlay_op_walk (op=0x59831130, rs=0x59830f40,
> which=op_modify, oi=0x8d7b50, on=0x8dc540) at backover.c:659
> #4  0x000000000047ec07 in over_op_func (op=0x59831130, rs=0x59830f40,
> which=op_modify) at backover.c:721
> #5  0x000000000047404d in syncrepl_updateCookie (si=0x8d74e0, op=0x59831130,
> syncCookie=0x59831aa0) at syncrepl.c:3292
> #6  0x0000000000479d0d in do_syncrep2 (ctx=<value optimized out>, arg=<value
> optimized out>) at syncrepl.c:959
> #7  do_syncrepl (ctx=<value optimized out>, arg=<value optimized out>) at
> syncrepl.c:1455
> #8  0x000000000041f7aa in connection_read_thread (ctx=0x59831d70, argv=<value
> optimized out>) at connection.c:1251
> #9  0x00000000004ec5ec in ldap_int_thread_pool_wrapper (xpool=0x84de50) at
> tpool.c:685
> #10 0x000000301b20673d in start_thread (arg=<value optimized out>) at
> pthread_create.c:301
> #11 0x000000301aad44bd in clone () from /lib64/libc.so.6
>
> Let me know if I can provide more info.

A patch to avoid this particular crash is now in git master. However, it's 
still not clear to me why it occurred. Can you get this info from gdb:
	frame 1
	print *ss


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Comment 3 Howard Chu 2011-06-10 08:59:53 UTC
changed state Open to Active
Comment 4 ghola@rebelbase.com 2011-06-10 21:27:25 UTC
> A patch to avoid this particular crash is now in git master. However, it's still not clear to me why it occurred. Can you get this info from gdb:
>        frame 1
>        print *ss

Thanks Howard, here is the info you requested:

(gdb) bt
#0  test_filter (op=0x40fff7f0, e=0x2aab116ab068, f=0x0) at filterentry.c:69
#1  0x00000000004db315 in syncprov_matchops (op=0x410001b0,
opc=0xb096e0, saveit=1) at syncprov.c:1314
#2  0x00000000004db6b5 in syncprov_op_mod (op=0x410001b0, rs=<value
optimized out>) at syncprov.c:2124
#3  0x000000000047e62a in overlay_op_walk (op=0x410001b0,
rs=0x40ffffc0, which=op_modify, oi=0x8d7ab0,
    on=0x8dc4f0) at backover.c:659
#4  0x000000000047ec07 in over_op_func (op=0x410001b0, rs=0x40ffffc0,
which=op_modify) at backover.c:721
#5  0x000000000047404d in syncrepl_updateCookie (si=0x8d74d0,
op=0x410001b0, syncCookie=0x41000b20)
    at syncrepl.c:3292
#6  0x0000000000478462 in do_syncrep2 (ctx=<value optimized out>,
arg=<value optimized out>)
    at syncrepl.c:1097
#7  do_syncrepl (ctx=<value optimized out>, arg=<value optimized out>)
at syncrepl.c:1455
#8  0x00000000004ec5ec in ldap_int_thread_pool_wrapper
(xpool=0x84daf0) at tpool.c:685
#9  0x000000301b20673d in start_thread (arg=<value optimized out>) at
pthread_create.c:301
#10 0x000000301aad44bd in clone () from /lib64/libc.so.6
(gdb) frame 1
#1  0x00000000004db315 in syncprov_matchops (op=0x410001b0,
opc=0xb096e0, saveit=1) at syncprov.c:1314
1314				rc = test_filter( &op2, e, op2.ors_filter );
(gdb) print *ss
$1 = {s_next = 0x2aab502177f0, s_base = {bv_len = 16, bv_val =
0x2aab730920e0 "dc=test12,dc=net"},
  s_eid = 1, s_op = 0x230ea90, s_rid = 1, s_sid = -1, s_filterstr =
{bv_len = 15,
    bv_val = 0x230f7d0 "(objectClass=*)"}, s_flags = 1, s_inuse = 1,
s_res = 0x2aababca90f0,
  s_restail = 0x2aabc320d920, s_mutex = {__data = {__lock = 0, __count
= 0, __owner = 0, __nusers = 0,
      __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}},
    __size = '\000' <repeats 39 times>, __align = 0}}

Comment 5 Howard Chu 2011-06-14 20:34:12 UTC
changed notes
changed state Active to Test
moved from Incoming to Software Bugs
Comment 6 Quanah Gibson-Mount 2011-06-14 21:35:36 UTC
changed notes
changed state Test to Release
Comment 7 ghola@rebelbase.com 2011-06-15 17:35:03 UTC
I'm unable to reproduce this problem with the latest syncrepl.c from git.

Comment 8 Quanah Gibson-Mount 2011-07-18 19:53:10 UTC
changed notes
changed state Release to Closed
Comment 9 OpenLDAP project 2014-08-01 21:04:37 UTC
fixed in master
fixed in RE24