[Date Prev][Date Next] [Chronological] [Thread] [Top]

Fwd: Re: (ITS#6821) ldap modify with ndb backend causes segfault



This is a multi-part message in MIME format.
--------------080208070703090506020001
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Confirmation...

--------------080208070703090506020001
Content-Type: message/rfc822;
 name="Re: (ITS#6821) ldap modify with ndb backend causes segfault.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename*0="Re: (ITS#6821) ldap modify with ndb backend causes segfault.";
 filename*1="eml"

X-Account-Key: account3
X-Mozilla-Keys:                                                                                 
Return-path: <anderson@vailsys.com>
Envelope-to: hyc@symas.com
Delivery-date: Wed, 02 Feb 2011 15:44:52 -0800
Received: from chrobd01.vailsys.com ([63.210.102.138] helo=dprobd02.vailsys.com)
	by lirone.symas.net with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72)
	(envelope-from <anderson@vailsys.com>)
	id 1PkmNX-0006Dz-C1
	for hyc@symas.com; Wed, 02 Feb 2011 15:44:52 -0800
Received: from dpluser01.vail (dpluser01.vail [192.168.129.158])
	by dprobd02.vailsys.com (Postfix) with ESMTP id A301E8A5C6C
	for <hyc@symas.com>; Wed,  2 Feb 2011 17:44:49 -0600 (CST)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by dpluser01.vail (Postfix) with ESMTP id 792731C810E
	for <hyc@symas.com>; Wed,  2 Feb 2011 17:44:49 -0600 (CST)
X-Virus-Scanned: amavisd-new at vail
Received: from dpluser01.vail ([127.0.0.1])
	by localhost (dpluser01.vail [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id z0mdB0KuN0MP for <hyc@symas.com>;
	Wed,  2 Feb 2011 17:44:49 -0600 (CST)
Received: from [172.29.10.129] (anderson-vpn.vail [172.29.10.129])
	by dpluser01.vail (Postfix) with ESMTP id E068F1C810B
	for <hyc@symas.com>; Wed,  2 Feb 2011 17:44:48 -0600 (CST)
Subject: Re: (ITS#6821) ldap modify with ndb backend causes segfault
From: Nathanael Anderson <anderson@vailsys.com>
To: Howard Chu <hyc@symas.com>
In-Reply-To: <4D49DDA7.90402@symas.com>
References: <201102012257.p11MvJ92053380@boole.openldap.org>
	 <4D49282B.7060603@symas.com> <1296657834.10413.0.camel@Yume>
	 <4D49CA7F.7020804@symas.com> <1296684181.10413.1.camel@Yume>
	 <4D49D4E9.70606@symas.com> <1296685813.10413.3.camel@Yume>
	 <4D49DDA7.90402@symas.com>
Content-Type: text/plain; charset="UTF-8"
Organization: Vail Systems
Date: Wed, 02 Feb 2011 17:44:48 -0600
Message-ID: <1296690288.10413.6.camel@Yume>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Content-Transfer-Encoding: 7bit
X-Spam_score: -1.9
X-Spam_score_int: -18
X-Spam_bar: -

The fix commited to cvs resolved this issue.

On Wed, 2011-02-02 at 14:41 -0800, Howard Chu wrote:
> Nathanael Anderson wrote:
> > Let me know if this doesn't have what you need.
> 
> Can you also print *ml and *ml->sml_desc ? It looks like you're performing a 
> modify on an attribute that back-ndb doesn't already know about.
> >
> > Program terminated with signal 11, Segmentation fault.
> > #0  0x000000000050cce9 in ndb_modify_internal (op=0x12daaf0,
> >      NA=0x7fa45b342570, text=0x7fa45b343a30,
> >      textbuf=0x7fa45b3425e0 "\340\345R\001", textlen=256) at
> > modify.cpp:397
> > 397			if ( modai[nai]->na_flag&  NDB_INFO_INDEX )
> > (gdb) bt
> > #0  0x000000000050cce9 in ndb_modify_internal (op=0x12daaf0,
> >      NA=0x7fa45b342570, text=0x7fa45b343a30,
> >      textbuf=0x7fa45b3425e0 "\340\345R\001", textlen=256) at
> > modify.cpp:397
> > #1  0x000000000050d769 in ndb_back_modify (op=0x12daaf0,
> > rs=0x7fa45b343a10)
> >      at modify.cpp:594
> > #2  0x0000000000466510 in fe_op_modify (op=0x12daaf0, rs=0x7fa45b343a10)
> >      at modify.c:303
> > #3  0x0000000000465d80 in do_modify (op=0x12daaf0, rs=0x7fa45b343a10)
> >      at modify.c:177
> > #4  0x00000000004452b8 in connection_operation (ctx=0x7fa45b343b50,
> >      arg_v=0x12daaf0) at connection.c:1113
> > #5  0x0000000000445856 in connection_read_thread (ctx=0x7fa45b343b50,
> > argv=0xe)
> >      at connection.c:1249
> > #6  0x00007fa4602b9e09 in ldap_int_thread_pool_wrapper (xpool=0x11b83f0)
> >      at tpool.c:685
> > #7  0x00007fa45eab29ca in start_thread () from /lib/libpthread.so.0
> > #8  0x00007fa45d27a70d in clone () from /lib/libc.so.6
> > #9  0x0000000000000000 in ?? ()
> >
> >
> > On Wed, 2011-02-02 at 14:04 -0800, Howard Chu wrote:
> >> Nathanael Anderson wrote:
> >>> I tried to build openldap without compilier optimiations, but its
> >>> ignoring CFLAGS and CXXFLAGS when i set them to
> >>>
> >>> export CFLAGS = "-g -ggdb"
> >>>
> >>> export CXXFLAGS=$CFLAGS
> >>
> >> use
> >> 	make AC_CFLAGS=-g
> >>
> >>> and still passes -O2, doesn't pass -ggdb. what am I missing to disable
> >>> optimizations when building.
> >>>
> >>> On Wed, 2011-02-02 at 13:19 -0800, Howard Chu wrote:
> >>>> Unfortunately this trace is nonsensical because of the compiler optimizations.
> >>>> It shows a call path that simply doesn't exist (connection_read ->   syslog ->
> >>>> connection_operation).
> >>>>
> >>>> Please try again with all optimization turned off in your build.
> >>>>
> >>>> Nathanael Anderson wrote:
> >>>>> Program terminated with signal 11, Segmentation fault.
> >>>>> #0  0x00000000004c4a2d in ndb_modify_internal (op=0x1ae74c0, NA=0x0,
> >>>>> text=<value optimized out>, textbuf=<value optimized out>,
> >>>>> textlen=<value optimized out>)
> >>>>>        at modify.cpp:416
> >>>>> 416			for ( i=0; i<nai; i++ ) {
> >>>>> (gdb) bt
> >>>>> #0  0x00000000004c4a2d in ndb_modify_internal (op=0x1ae74c0, NA=0x0,
> >>>>> text=<value optimized out>, textbuf=<value optimized out>,
> >>>>> textlen=<value optimized out>)
> >>>>>        at modify.cpp:416
> >>>>> #1  0x00000000004c5605 in ndb_back_modify (op=0x1bcd940,
> >>>>> rs=0x7f1d3a7bd9f0) at modify.cpp:646
> >>>>> #2  0x0000000000450141 in fe_op_modify (op=0x1bcd940, rs=0x7f1d3a7bd9f0)
> >>>>> at modify.c:211
> >>>>> #3  0x0000000000450a96 in do_modify (op=0x1bcd940, rs=0x7f1d3a7bd9f0) at
> >>>>> modify.c:142
> >>>>> #4  0x0000000000437b78 in connection_operation (ctx=0x7f1d3a7bdb50,
> >>>>> arg_v=<value optimized out>) at connection.c:1129
> >>>>> #5  0x000000000043876d in syslog (ctx=<value optimized out>, argv=<value
> >>>>> optimized out>) at /usr/include/bits/syslog.h:32
> >>>>> #6  connection_read (ctx=<value optimized out>, argv=<value optimized
> >>>>> out>) at connection.c:1429
> >>>>> #7  connection_read_thread (ctx=<value optimized out>, argv=<value
> >>>>> optimized out>) at connection.c:1242
> >>>>> #8  0x00007f1d3ef30b48 in ldap_int_thread_pool_wrapper (xpool=<value
> >>>>> optimized out>) at tpool.c:685
> >>>>> #9  0x00007f1d3d72b9ca in start_thread () from /lib/libpthread.so.0
> >>>>> #10 0x00007f1d3bef370d in clone () from /lib/libc.so.6
> >>>>> #11 0x0000000000000000 in ?? ()
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Wed, 2011-02-02 at 01:47 -0800, Howard Chu wrote:
> >>>>>> This trace has no line numbers, so it's not very useful. Make sure you
> >>>>>> use an
> >>>>>> unstripped binary.
> >>>>>>
> >>>>>>> Program terminated with signal 11, Segmentation fault.
> >>>>>>> #0  0x00000000004c491d in ndb_modify_internal ()
> >>>>>>> (gdb) bt
> >>>>>>> #0  0x00000000004c491d in ndb_modify_internal ()
> >>>>>>> #1  0x00000000004c5515 in ndb_back_modify ()
> >>>>>>> #2  0x0000000000450001 in fe_op_modify ()
> >>>>>>> #3  0x0000000000450956 in do_modify ()
> >>>>>>> #4  0x0000000000437ad8 in ?? ()
> >>>>>>> #5  0x00000000004386cd in ?? ()
> >>>>>>> #6  0x00007ff79450ab08 in ldap_int_thread_pool_wrapper (xpool=<value
> >>>>>> optimized
> >>>>>>> out>) at tpool.c:685
> >>>>>>> #7  0x00007ff792d059ca in start_thread () from /lib/libpthread.so.0
> >>>>>>> #8  0x00007ff7914cd70d in clone () from /lib/libc.so.6
> >>>>>>> #9  0x0000000000000000 in ?? ()
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
> 
> 




--------------080208070703090506020001--