Issue 7144 - reproducible segfault on slave/consumer during sync-replication
Summary: reproducible segfault on slave/consumer during sync-replication
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: 2.4.28
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-31 19:49 UTC by sven@svenhartge.de
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 sven@svenhartge.de 2012-01-31 19:49:04 UTC
Full_Name: Sven Hartge
Version: 2.4.28
OS: Debian Squeeze
URL: 
Submission from: (NULL) (2a01:198:329:1::14)


I experience an easy to reproduce and consistent segfault when I setup a slapd  
                   
syncrepl consumer on Squeeze.                                                   
                   
                                                                                
                   
This segfault always happens during the replication of the same object, but the 
                   
slapd version in Lenny has no problems with same DIT.                           
                   
                                                                                
                   
My oldstable replicas currently run a self-backported version of                
                   
2.4.21-1~dvz50+1, but both 2.4.17-2.1~bpo50+1 and 2.4.11-1+lenny2.1 are also    
                   
fine.                                                                           
                   
                                                                                
                   
2.4.23-7.2 shows the segfault as all versions up to 2.4.28-1.1 do. Even if I    
                   
disable all indices and strip my configuration to the bare minimum needed (i.e. 
                   
self-defined objectclasses and attributes) I get the segfault.                  
                   

I also did da -O0 rebuild of the Debian-2.4.28 and this also segfaults in the
same way as 2.4.23 did. I have yet to test the latest RelEng24 from GIT, but I
wanted to submit this issue so someone may have a look at the backtrace in
parallel to my further tests.
                                                                                
                   
I am aware the problem my lie in my self-defined objectclasses and attributes,  
                   
but then slapd should throw an error and exit instead of replicating 1/3 of the 
                   
DIT and then segfault.                                                          
                   
                                                                                
                   
I get a very good backtrace, but since this backtrace contains internal         
                   
information I am a bit hesitant to attach this backtrace to a public bug-report.
                   
                                                                                
                   
Is there a way to privatly submit this data (backtrace and additional schemas)  
                   
so you can have look at the problem?

Comment 1 Howard Chu 2012-02-01 04:56:01 UTC
sven@svenhartge.de wrote:
> Full_Name: Sven Hartge
> Version: 2.4.28
> OS: Debian Squeeze
> URL:
> Submission from: (NULL) (2a01:198:329:1::14)
>
>
> I experience an easy to reproduce and consistent segfault when I setup a slapd
>
> syncrepl consumer on Squeeze.
>
>
>
> This segfault always happens during the replication of the same object, but the
>
> slapd version in Lenny has no problems with same DIT.

> I get a very good backtrace, but since this backtrace contains internal
>
> information I am a bit hesitant to attach this backtrace to a public bug-report.

The backtrace you sent shows the crash at a line of code which was already 
patched in RE24 due to ITS#7132. I believe this bug is already fixed.

> Is there a way to privatly submit this data (backtrace and additional schemas)
>
> so you can have look at the problem?


-- 
   -- 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 2 Howard Chu 2012-02-01 04:56:37 UTC
changed notes
changed state Open to Feedback
Comment 3 sven@svenhartge.de 2012-02-01 08:54:52 UTC
On 02/01/12 05:56, Howard Chu wrote:
> sven@svenhartge.de wrote:

>> I get a very good backtrace, but since this backtrace contains internal
>> information I am a bit hesitant to attach this backtrace to a public
>> bug-report.
>
> The backtrace you sent shows the crash at a line of code which was
> already patched in RE24 due to ITS#7132. I believe this bug is already
> fixed.

This is good news. Do you have any commit ID so I can try to backport 
this fix to the version currently in Debian Squeeze?

Grüße,
Sven.

Comment 4 Howard Chu 2012-02-01 09:00:13 UTC
Sven Hartge wrote:
> On 02/01/12 05:56, Howard Chu wrote:
>> sven@svenhartge.de wrote:
>
>>> I get a very good backtrace, but since this backtrace contains internal
>>> information I am a bit hesitant to attach this backtrace to a public
>>> bug-report.
>>
>> The backtrace you sent shows the crash at a line of code which was
>> already patched in RE24 due to ITS#7132. I believe this bug is already
>> fixed.
>
> This is good news. Do you have any commit ID so I can try to backport
> this fix to the version currently in Debian Squeeze?

commit 42faa8393e6cd41a837b526777110b892541773a

-- 
   -- 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 5 sven@svenhartge.de 2012-02-01 22:27:27 UTC
Um 01:00 Uhr am 01.02.12 schrieb Howard Chu:
> Sven Hartge wrote:
>> On 02/01/12 05:56, Howard Chu wrote:
>>> sven@svenhartge.de wrote:
 
>> > > I get a very good backtrace, but since this backtrace contains internal
>> > > information I am a bit hesitant to attach this backtrace to a public
>> > > bug-report.
>> > 
>> > The backtrace you sent shows the crash at a line of code which was
>> > already patched in RE24 due to ITS#7132. I believe this bug is already
>> > fixed.
>> 
>> This is good news. Do you have any commit ID so I can try to backport
>> this fix to the version currently in Debian Squeeze?
> 
> commit 42faa8393e6cd41a837b526777110b892541773a

This simple patch applies flawless on 2.4.23 but still segfaults. Will try 
on top of 2.4.28 tomorrow, backtraces will follow then, after I verified 
my findings.


(Reason for trying this on top of 2.4.23 is because this is the version in 
Debian Squeeze and I want to provide the DDs with a fix for Squeeze. I 
fully understand that is not supported by OpenLDAP.)

Grüße,
Sven.

Comment 6 Quanah Gibson-Mount 2012-02-01 22:47:27 UTC
--On Wednesday, February 01, 2012 10:27 PM +0000 sven@svenhartge.de wrote:

> Um 01:00 Uhr am 01.02.12 schrieb Howard Chu:
>> Sven Hartge wrote:
>>> On 02/01/12 05:56, Howard Chu wrote:
>>>> sven@svenhartge.de wrote:
>
>>> > > I get a very good backtrace, but since this backtrace contains
>>> > > internal information I am a bit hesitant to attach this backtrace
>>> > > to a public bug-report.
>>> >
>>> > The backtrace you sent shows the crash at a line of code which was
>>> > already patched in RE24 due to ITS#7132. I believe this bug is already
>>> > fixed.
>>>
>>> This is good news. Do you have any commit ID so I can try to backport
>>> this fix to the version currently in Debian Squeeze?
>>
>> commit 42faa8393e6cd41a837b526777110b892541773a
>
> This simple patch applies flawless on 2.4.23 but still segfaults. Will
> try  on top of 2.4.28 tomorrow, backtraces will follow then, after I
> verified  my findings.
>
>
> (Reason for trying this on top of 2.4.23 is because this is the version
> in  Debian Squeeze and I want to provide the DDs with a fix for Squeeze.
> I  fully understand that is not supported by OpenLDAP.)
>

Could you *please* try the RE24 checkout from GIT rather than 2.4.28? 
Thanks.  That is substantially more useful than patching 2.4.28.

You can check out an tarball of current RE24 with:

git archive --format=tar --remote=git.openldap.org:~git/git/openldap.git 
OPENLDAP_REL_ENG_2_4 > openldap-2.4.29.tar

Or via the web with:

<http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/heads/OPENLDAP_REL_ENG_2_4;sf=tgz>

--Quanah



--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration

Comment 7 Howard Chu 2012-02-02 10:54:39 UTC
changed state Feedback to Test
moved from Incoming to Software Bugs
Comment 8 Howard Chu 2012-02-02 11:00:30 UTC
Sven Hartge wrote:
> On 02.02.2012 11:25, Howard Chu wrote:
>> Sven Hartge wrote:
>>> Um 14:47 Uhr am 01.02.12 schrieb Quanah Gibson-Mount:
>>>
>>>> Could you *please* try the RE24 checkout from GIT rather than 2.4.28?
>>>> Thanks.
>>>> That is substantially more useful than patching 2.4.28.
>>>
>>> I'm sorry to report: still segfaults, backtrace is attached.
>>
>> This patch should take care of that crash.
>
> Yes, works. Thank you very much!

Thanks for the confirmation, committed to 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/

Comment 9 Quanah Gibson-Mount 2012-02-02 20:20:50 UTC
changed notes
changed state Test to Release
Comment 10 Quanah Gibson-Mount 2012-02-13 19:10:28 UTC
changed notes
changed state Release to Closed
Comment 11 OpenLDAP project 2014-08-01 21:04:40 UTC
fixed in master
fixed in RE24