Re: (ITS#7144) reproducible segfault on slave/consumer during sync-replication
by sven@svenhartge.de
Um 01:00 Uhr am 01.02.12 schrieb Howard Chu:
> Sven Hartge wrote:
>> On 02/01/12 05:56, Howard Chu wrote:
>>> sven(a)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.
11 years, 7 months
Re: (ITS#7130) OpenLDAP with BackSQL and Postgres. Upper on bigint?
by dermaniac@gmail.com
I'm sorry, I send my issue to the wrong mailinglist at first (to the
bugs list) and then tried to send it to technical twice. It doesnt
seem to go through. Do you have any idea which column it is that
defines this behaviour? I can't seem to find it..
11 years, 7 months
Re: (ITS#7144) reproducible segfault on slave/consumer during sync-replication
by hyc@symas.com
Sven Hartge wrote:
> On 02/01/12 05:56, Howard Chu wrote:
>> sven(a)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/
11 years, 7 months
Re: (ITS#7144) reproducible segfault on slave/consumer during sync-replication
by sven@svenhartge.de
On 02/01/12 05:56, Howard Chu wrote:
> sven(a)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.
11 years, 7 months
Re: (ITS#7144) reproducible segfault on slave/consumer during sync-replication
by hyc@symas.com
sven(a)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/
11 years, 7 months