openldap-bugs

openldap-bugs@openldap.org

1 participants
20969 discussions

Re: (ITS#7144) reproducible segfault on slave/consumer during sync-replication
by quanah＠zimbra.com 01 Feb '12

01 Feb '12

--On Wednesday, February 01, 2012 10:27 PM +0000 sven(a)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(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.) > 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/h…> --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

1 0

Re: (ITS#7144) reproducible segfault on slave/consumer during sync-replication
by sven＠svenhartge.de 01 Feb '12

01 Feb '12

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.

1 0

(ITS#7145) cn=Connection 0,cn=Connections,cn=Monitor received twice
by michael＠stroeder.com 01 Feb '12

01 Feb '12

Full_Name: Version: RE24 22ee28752e3e0d2a6910a22922fc69befd78578a OS: RHEL 6.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.34.231) When querying cn=Monitor there are two entries returned with the same DN cn=Connection 0,cn=Connections,cn=Monitor This is a MMR setup with two nodes.

1 0

Re: (ITS#7130) OpenLDAP with BackSQL and Postgres. Upper on bigint?
by dermaniac＠gmail.com 01 Feb '12

01 Feb '12

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..

1 0

Re: (ITS#7144) reproducible segfault on slave/consumer during sync-replication
by hyc＠symas.com 01 Feb '12

01 Feb '12

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/

1 0

Re: (ITS#7144) reproducible segfault on slave/consumer during sync-replication
by sven＠svenhartge.de 01 Feb '12

01 Feb '12

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.

1 0

Re: (ITS#7144) reproducible segfault on slave/consumer during sync-replication
by hyc＠symas.com 31 Jan '12

31 Jan '12

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/

1 0

(ITS#7144) reproducible segfault on slave/consumer during sync-replication
by sven＠svenhartge.de 31 Jan '12

31 Jan '12

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?

1 0

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by hyc＠symas.com 31 Jan '12

31 Jan '12

mattias(a)centaurix.com wrote: > On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu<hyc(a)symas.com> wrote: > >> Mattias Andersson wrote: >>> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc(a)symas.com> wrote: >>> >>>> Please provide a full gdb backtrace from the assertion failure. I've >>>> reproduced this configuration locally but see no crash using >>>> ldapsearch. >>>> I don't have the Softerra browser. >>> >>> Ok, see attachment. The problem is not reproducible with ldapsearch. >> >> Please see if the attached patch alters the behavior. Thanks. > > I'm getting an error that MozNSS is not found when I run ./configure. Are you building the latest source? You can use --with-tls=openssl (or gnutls) to explicitly choose. But it shouldn't be defaulting to MozNSS, unless perhaps you're on a Redhat or Fedora system. If worse comes to worse, you can configure --without-tls just to run this test. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by mattias＠centaurix.com 31 Jan '12

31 Jan '12

On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu <hyc(a)symas.com> wrote: > Mattias Andersson wrote: >> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc(a)symas.com> wrote: >> >>> Please provide a full gdb backtrace from the assertion failure. I've >>> reproduced this configuration locally but see no crash using >>> ldapsearch. >>> I don't have the Softerra browser. >> >> Ok, see attachment. The problem is not reproducible with ldapsearch. > > Please see if the attached patch alters the behavior. Thanks. I'm getting an error that MozNSS is not found when I run ./configure. Mattias

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs