OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Historical/5452
Full headers

From: quanah@zimbra.com
Subject: seg fault in syncprov_op abandon on master
Compose comment
Download message
State:
0 replies:
4 followups: 1 2 3 4

Major security issue: yes  no

Notes:

Notification:


Date: Thu, 3 Apr 2008 18:41:27 GMT
From: quanah@zimbra.com
To: openldap-its@OpenLDAP.org
Subject: seg fault in syncprov_op abandon on master
Full_Name: Quanah Gibson-Mount
Version: 2.3.41
OS: Linux 2.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (24.23.156.219)


Core was generated by `/opt/zimbra/openldap/libexec/slapd -l LOCAL0 -4 -u zimbra
-h ldap://'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000002a975f21ec in syncprov_op_abandon (op=0x42002b40, rs=0x42002a50) at
syncprov.c:1026
1026                    if ( so->s_op->o_connid == op->o_connid
&&
(gdb) bt
#0  0x0000002a975f21ec in syncprov_op_abandon (op=0x42002b40, rs=0x42002a50) at
syncprov.c:1026
#1  0x000000000049b8dd in overlay_op_walk (op=0x42002b40, rs=0x42002a50,
which=op_abandon, oi=0xde1e00, on=0xde1c40) at backover.c:640
#2  0x000000000049bb39 in over_op_func (op=0x42002b40, rs=0x42002a50,
which=op_abandon) at backover.c:702
#3  0x000000000049bca7 in over_op_abandon (op=0x42002b40, rs=0x42002a50) at
backover.c:760
#4  0x0000000000450729 in fe_op_abandon (op=0x42002b40, rs=0x42002a50) at
abandon.c:115
#5  0x000000000042b249 in connection_abandon (c=0x12603dd0) at connection.c:792
#6  0x000000000042b41c in connection_closing (c=0x12603dd0, why=0x4be9a0
"connection lost") at connection.c:840
#7  0x000000000042ca0f in connection_read (s=38, cri=0x42002d90) at
connection.c:1457
#8  0x000000000042c1f8 in connection_read_thread (ctx=0x42002e10, argv=0x26) at
connection.c:1254
#9  0x0000002a956c3bd7 in ldap_int_thread_pool_wrapper (xpool=0x88ce10) at
tpool.c:478
#10 0x0000003342606137 in ?? ()
#11 0x0000000000000000 in ?? ()

(gdb) frame 0
#0  0x0000002a975f21ec in syncprov_op_abandon (op=0x42002b40, rs=0x42002a50) at
syncprov.c:1026
1026                    if ( so->s_op->o_connid == op->o_connid
&&
(gdb) l
1021            syncops *so, *soprev;
1022
1023            ldap_pvt_thread_mutex_lock( &si->si_ops_mutex );
1024            for ( so=si->si_ops, soprev = (syncops *)&si->si_ops;
so;
1025                    soprev=so, so=so->s_next ) {
1026                    if ( so->s_op->o_connid == op->o_connid
&&
1027                            so->s_op->o_msgid == op->orn_msgid ) {
1028                                    so->s_op->o_abandon = 1;
1029                                    soprev->s_next = so->s_next;
1030                                    break;
(gdb)



Followup 1

Download message
Date: Thu, 03 Apr 2008 20:43:46 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: openldap-its@openldap.org
Subject: Re: (ITS#5452) seg fault in syncprov_op abandon on master
--On Thursday, April 03, 2008 6:41 PM +0000 quanah@zimbra.com wrote:

> Full_Name: Quanah Gibson-Mount
> Version: 2.3.41
> OS: Linux 2.6
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (24.23.156.219)
>
>
> Core was generated by `/opt/zimbra/openldap/libexec/slapd -l LOCAL0 -4 -u
> zimbra -h ldap://'.

also:

(gdb) print so
$1 = (syncops *) 0x12392240
(gdb) print *so
$2 = {s_next = 0x12393510, s_base = {bv_len = 12, bv_val = 0x1238dd50 
"cn=accesslog"}, s_eid = 1, s_op = 0x11d8fc00, s_rid = 100, s_filterstr = 
{bv_len = 0, bv_val = 0x0}, s_flags = 1,
  s_inuse = 1, s_res = 0x0, s_restail = 0x0, s_qtask = 0x0, s_mutex = 
{__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = 
{__status = 0, __spinlock = 0}}}


from frame 0.

--Quanah


--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration



Followup 2

Download message
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
Date: Fri, 4 Apr 2008 13:23:31 +0200
To: quanah@zimbra.com
Cc: openldap-its@openldap.org
Subject: Re: (ITS#5452) seg fault in syncprov_op abandon on master
Since it crashes on
	if ( so->s_op->o_connid == op->o_connid &&
	     so->s_op->o_msgid == op->orn_msgid   )
please try
	frame 0
        print *op
        print *so->s_op
and maybe
	backtrace full
while you are at it.

-- 
Hallvard



Followup 3

Download message
Date: Fri, 04 Apr 2008 09:19:11 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
cc: openldap-its@openldap.org
Subject: Re: (ITS#5452) seg fault in syncprov_op abandon on master
--On Friday, April 04, 2008 1:23 PM +0200 Hallvard B Furuseth 
<h.b.furuseth@usit.uio.no> wrote:

> Since it crashes on
> 	if ( so->s_op->o_connid == op->o_connid &&
> 	     so->s_op->o_msgid == op->orn_msgid   )
> please try
> 	frame 0
>         print *op
>         print *so->s_op
> and maybe
> 	backtrace full
> while you are at it.

#0  0x0000002a975f21ec in syncprov_op_abandon (op=0x42002b40, 
rs=0x42002a50) at syncprov.c:1026
1026                    if ( so->s_op->o_connid == op->o_connid
&&
(gdb) frame 0
#0  0x0000002a975f21ec in syncprov_op_abandon (op=0x42002b40, 
rs=0x42002a50) at syncprov.c:1026
1026                    if ( so->s_op->o_connid == op->o_connid
&&
(gdb) print *op
$1 = {o_hdr = 0x42002ac0, o_tag = 80, o_time = 0, o_tincr = 0, o_bd = 
0x42002830, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, 
bv_val = 0x0}, o_request = {oq_add = {
      rs_e = 0x4, rs_modlist = 0x0}, oq_bind = {rb_method = 4, rb_cred = 
{bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 
0, rb_tmp_mech = {bv_len = 0,
        bv_val = 0x0}}, oq_compare = {rs_ava = 0x4}, oq_modify = 
{rs_modlist = 0x4, rs_increment = 0}, oq_modrdn = {rs_newrdn = {bv_len = 4, 
bv_val = 0x0}, rs_nnewrdn = {bv_len = 0,
        bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0, rs_deleteoldrdn = 
0}, oq_search = {rs_scope = 4, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, 
rs_limit = 0x0, rs_attrsonly = 0,
      rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 
0x0}}, oq_abandon = {rs_msgid = 4}, oq_cancel = {rs_msgid = 4}, oq_extended 
= {rs_reqoid = {bv_len = 4,
        bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = 
{rs_extended = {rs_reqoid = {bv_len = 4, bv_val = 0x0}, rs_flags = 0, 
rs_reqdata = 0x0}, rs_old = {bv_len = 0,
        bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, 
rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, 
o_do_not_cache = 0 '\0',
  o_is_auth_check = 0 '\0', o_nocaching = 0 '\0', o_delete_glue_parent = 0 
'\0', o_no_schema_check = 0 '\0', o_ctrlflag = '\0' <repeats 31 times>, 
o_controls = 0x0, o_authz = {
    sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len 
= 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, 
sai_transport_ssf = 0, sai_tls_ssf = 0,
    sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 
0x42002810, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 
0x0, o_next = {stqe_next = 0x0}}
(gdb) print *so->s_op
$2 = {o_hdr = 0x11d8fd60, o_tag = 0, o_time = 0, o_tincr = 0, o_bd = 0x0, 
o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 
0x0}, o_request = {oq_add = {rs_e = 0x0,
      rs_modlist = 0x0}, oq_bind = {rb_method = 0, rb_cred = {bv_len = 0, 
bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_tmp_mech 
= {bv_len = 0, bv_val = 0x0}},
    oq_compare = {rs_ava = 0x0}, oq_modify = {rs_modlist = 0x0, 
rs_increment = 0}, oq_modrdn = {rs_newrdn = {bv_len = 0, bv_val = 0x0}, 
rs_nnewrdn = {bv_len = 0, bv_val = 0x0},
      rs_newSup = 0x0, rs_nnewSup = 0x0, rs_deleteoldrdn = 0}, oq_search = 
{rs_scope = 0, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, 
rs_attrsonly = 0, rs_attrs = 0x0,
      rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, 
oq_abandon = {rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, oq_extended = 
{rs_reqoid = {bv_len = 0, bv_val = 0x0},
      rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = 
{rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, 
rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {
        bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, 
o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', 
o_is_auth_check = 0 '\0', o_nocaching = 0 '\0',
  o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_ctrlflag = 
'\0' <repeats 31 times>, o_controls = 0x11d8fdd8, o_authz = {sai_method = 
0, sai_mech = {bv_len = 0,
      bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len 
= 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, 
sai_sasl_ssf = 0}, o_ber = 0x0,
  o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = 0, 
bv_val = 0x0}, o_private = 0x0, o_next = {stqe_next = 0x12307c00}}



(gdb) backtrace full
#0  0x0000002a975f21ec in syncprov_op_abandon (op=0x42002b40, 
rs=0x42002a50) at syncprov.c:1026
        on = (slap_overinst *) 0xde1c40
        si = (syncprov_info_t *) 0xde2ee0
        so = (syncops *) 0x12392240
        soprev = (syncops *) 0x12394bd0
#1  0x000000000049b8dd in overlay_op_walk (op=0x42002b40, rs=0x42002a50, 
which=op_abandon, oi=0xde1e00, on=0xde1c40) at backover.c:640
        func = (BI_op_bind **) 0xde1c98
        rc = 32768
#2  0x000000000049bb39 in over_op_func (op=0x42002b40, rs=0x42002a50, 
which=op_ab

Message of length 11068 truncated


Followup 4

Download message
Date: Wed, 09 Apr 2008 04:45:17 -0700
From: Howard Chu <hyc@symas.com>
To: quanah@zimbra.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#5452) seg fault in syncprov_op abandon on master
quanah@zimbra.com wrote:
> --On Friday, April 04, 2008 1:23 PM +0200 Hallvard B Furuseth
> <h.b.furuseth@usit.uio.no>  wrote:
>
>> Since it crashes on
>> 	if ( so->s_op->o_connid == op->o_connid&&
>> 	so->s_op->o_msgid == op->orn_msgid   )
>> please try
>> 	frame 0
>>          print *op
>>          print *so->s_op
>> and maybe
>> 	backtrace full
>> while you are at it.

So far there don't appear to be any invalid pointers anywhere, so there's no 
clue why you hit a SEGV here. Can you reproduce this situation using valgrind?
-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org