openldap-bugs October 2008

openldap-bugs@openldap.org

36 participants
187 discussions

Re: (ITS#5744) Automatically close issues when no feedback is received within a reasonable time
by quanah＠zimbra.com 17 Oct '08

17 Oct '08

--On Thursday, October 16, 2008 12:12 PM +0000 ando(a)sys-net.it wrote: > The ITS is polluted by issues opened, considered by developers, and > pending feedback since ever. I suggest the ITS automatically closes > issues not fed back after a reasonable amount of time. Closed issues can > always be re-opened if issueers wake up and respond. The problem I see with this is we have a number of ITS' that are open because the work was partially done, but there is work remaining to be done, and that needs to be tracked. I'm not sure if "Open" is the best state, but they definitely shouldn't be "closed" either. I feel what we really need is a much improved bug tracking system where we can do things like assign target releases to bugs, keywords, and have better-tuned states. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5745) slapcat doesn't return correct error status for bdb fatal error
by Guillaume.Rousse＠inria.fr 17 Oct '08

17 Oct '08

Full_Name: Guillaume Rousse Version: 2.4.12 OS: URL: Submission from: (NULL) (193.55.250.67) [root@etoile ~]# slapcat -b dc=msr-inria,dc=inria,dc=fr ... bdb(dc=msr-inria,dc=inria,dc=fr): pthread lock failed: Invalid argument bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: Invalid argument bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: DB_RUNRECOVERY: Fatal error, run database recovery bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: fatal region error detected; run recovery bdb_db_close: database "dc=msr-inria,dc=inria,dc=fr": close failed: DB_RUNRECOVERY: Fatal error, run database recovery (-30975) [root@etoile ~]# echo $? 0 It makes a bit difficult to know if slapcat-based backup were successful.

1 0

Re: (ITS#5744) Automatically close issues when no feedback is received within a reasonable time
by ando＠sys-net.it 17 Oct '08

17 Oct '08

michael(a)stroeder.com wrote: > Although I try to keep up with testing sometimes 30 days could be a > little bit short. > > Anyway I wonder what the state "Feedback" really means. I've checked if > there are still open issues in this state submitted by me. The only one > seems to be ITS#5574, but I can't resolve this since assigning the > official OID needed in this case is not something I can do. I could only > test something and give feedback. It means some feedback is expected from the submitter. In ITS#5574 case, the most appropriate status is "suspended" (just changed). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5744) Automatically close issues when no feedback is received within a reasonable time
by michael＠stroeder.com 17 Oct '08

17 Oct '08

Frank.Swasey(a)uvm.edu wrote: > On 10/16/08 8:12 AM, ando(a)sys-net.it wrote: >> The ITS is polluted by issues opened, considered by developers, and pending >> feedback since ever. I suggest the ITS automatically closes issues not fed back >> after a reasonable amount of time. Closed issues can always be re-opened if >> issueers wake up and respond. > > As a user... I would completely agree with this and suggest that 30 days > is a "reasonable amount of time" Although I try to keep up with testing sometimes 30 days could be a little bit short. Anyway I wonder what the state "Feedback" really means. I've checked if there are still open issues in this state submitted by me. The only one seems to be ITS#5574, but I can't resolve this since assigning the official OID needed in this case is not something I can do. I could only test something and give feedback. Ciao, Michael.

1 0

Re: (ITS#5744) Automatically close issues when no feedback is received within a reasonable time
by Frank.Swasey＠uvm.edu 16 Oct '08

16 Oct '08

On 10/16/08 8:12 AM, ando(a)sys-net.it wrote: > The ITS is polluted by issues opened, considered by developers, and pending > feedback since ever. I suggest the ITS automatically closes issues not fed back > after a reasonable amount of time. Closed issues can always be re-opened if > issueers wake up and respond. > > As a user... I would completely agree with this and suggest that 30 days is a "reasonable amount of time" -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

1 0

(ITS#5744) Automatically close issues when no feedback is received within a reasonable time
by ando＠sys-net.it 16 Oct '08

16 Oct '08

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.7) The ITS is polluted by issues opened, considered by developers, and pending feedback since ever. I suggest the ITS automatically closes issues not fed back after a reasonable amount of time. Closed issues can always be re-opened if issueers wake up and respond. p.

1 0

Re: (ITS#5740) slapd-tester fails on windows
by ando＠sys-net.it 15 Oct '08

15 Oct '08

----- quanah(a)zimbra.com wrote: > > Could it be because liblutil comes after liblber? > > Yep, putting liblber after liblutil, things finish. The error seems to be the dependence of liblutil on ber memory routines. What memory routines is liblutil supposed to use, then? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5740) slapd-tester fails on windows
by quanah＠zimbra.com 15 Oct '08

15 Oct '08

--On Wednesday, October 15, 2008 4:05 PM +0000 ando(a)sys-net.it wrote: > > ----- quanah(a)zimbra.com wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.12 >> OS: Windows XP >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.29.239) >> >> >> gcc -g -O2 -o .libs/slapd-tester slapd-tester.o slapd-common.o >> -L/opt/zimbra/bdb-4.6.21.3/lib -L/opt/zimbra/openssl-0.9.8h/lib >> ../../libraries/libldap/.libs/libldap.dll.a >> /home/quanah/openldap-2.4.12/libraries/liblber/.libs/liblber.dll.a >> ../../libraries/liblber/.libs/liblber.dll.a >> ../../libraries/liblutil/liblutil.a > > Could it be because liblutil comes after liblber? Yep, putting liblber after liblutil, things finish. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5740) slapd-tester fails on windows
by ando＠sys-net.it 15 Oct '08

15 Oct '08

----- quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.12 > OS: Windows XP > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > gcc -g -O2 -o .libs/slapd-tester slapd-tester.o slapd-common.o > -L/opt/zimbra/bdb-4.6.21.3/lib -L/opt/zimbra/openssl-0.9.8h/lib > ../../libraries/libldap/.libs/libldap.dll.a > /home/quanah/openldap-2.4.12/libraries/liblber/.libs/liblber.dll.a > ../../libraries/liblber/.libs/liblber.dll.a > ../../libraries/liblutil/liblutil.a Could it be because liblutil comes after liblber? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5743) SIGSEGV in ldapsearch
by ando＠sys-net.it 15 Oct '08

15 Oct '08

Full_Name: Pierangelo Masarati Version: re24 OS: CentOS 5.2 on i386 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.6) Submitted by: ando While chasing referrals (-C) to non-responding hosts (see also ITS#5742, unrelated but same scenario), I got the following: #0 0x0084b402 in __kernel_vsyscall () #1 0x00c9ad20 in raise () from /lib/libc.so.6 #2 0x00c9c631 in abort () from /lib/libc.so.6 #3 0x00c9416b in __assert_fail () from /lib/libc.so.6 #4 0x0807e58b in ber_sockbuf_ctrl (sb=0x0, opt=19658, arg=0x0) at sockbuf.c:88 #5 0x0805672a in try_read1msg (ld=0x90502a8, msgid=8, all=1, lcp=0xbf8957c8, result=0xbf895820) at result.c:1190 #6 0x08057952 in ldap_result (ld=0x90502a8, msgid=8, all=1, timeout=0xbf895810, result=0xbf895820) at result.c:402 #7 0x08064635 in ldap_new_connection (ld=0x90502a8, srvlist=0xbf895904, use_ldsb=0, connect=1, bind=0xbf8958f0) at request.c:501 #8 0x08064b2d in ldap_send_server_request (ld=0x90502a8, ber=0x905ab20, msgid=7, parentreq=0x90594d8, srvlist=0xbf895904, lc=0x0, bind=0xbf8958f0) at request.c:207 #9 0x08065acc in ldap_chase_v3referrals (ld=0x90502a8, lr=0x905a7c0, refs=0x905aa50, sref=1, errstrp=0x905a7e4, hadrefp=0xbf895a1c) at request.c:1139 #10 0x08056a6d in try_read1msg (ld=0x90502a8, msgid=6, all=1, lcp=0xbf895a88, result=0xbf895ae0) at result.c:729 #11 0x08057952 in ldap_result (ld=0x90502a8, msgid=6, all=1, timeout=0xbf895ad0, result=0xbf895ae0) at result.c:402 #12 0x08064635 in ldap_new_connection (ld=0x90502a8, srvlist=0xbf895bc4, use_ldsb=0, connect=1, bind=0xbf895bb0) at request.c:501 #13 0x08064b2d in ldap_send_server_request (ld=0x90502a8, ber=0x905b7f8, msgid=5, parentreq=0x90594d8, srvlist=0xbf895bc4, lc=0x0, bind=0xbf895bb0) at request.c:207 #14 0x08065acc in ldap_chase_v3referrals (ld=0x90502a8, lr=0x905a7c0, refs=0x905a8f0, sref=1, errstrp=0x905a7e4, hadrefp=0xbf895cdc) at request.c:1139 #15 0x08056a6d in try_read1msg (ld=0x90502a8, msgid=-1, all=0, lcp=0xbf895d48, result=0xbf895ff8) at result.c:729 #16 0x08057952 in ldap_result (ld=0x90502a8, msgid=-1, all=0, timeout=0x0, result=0xbf895ff8) at result.c:402 #17 0x0804b362 in dosearch (ld=0x90502a8, base=0x904f180 "dc=ericsson,dc=com", scope=2, filtpatt=0x0, value=0x10 <Address 0x10 out of bounds>, attrs=0x0, attrsonly=0, sctrls=0x0, cctrls=0x0, timeout=0x0, sizelimit=-1) at ldapsearch.c:1198 #18 0x0804d3ce in main (argc=Cannot access memory at address 0x4cca ) at ldapsearch.c:1031 Frame #4 clearly shows that ber_sockbuf_ctrl() is passed a null sb, which is lc->lconn_sb. I could not track, right now, where that pointer was zeroed out. I have binary and core available, if anything is needed. What I'm missing right now is time and connectivity (via ssh, and most of the time via http). p.

1 0

← Newer
1
...
10
11
12
13
14
15
16
...
19
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2008