openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

(ITS#4772) SEGV during DEL/syncprov_qtask
by richton＠nbcs.rutgers.edu 08 Dec '06

08 Dec '06

Full_Name: Aaron Richton Version: 2.3.30 OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/richton-20061208-segv.txt Submission from: (NULL) (68.196.250.61) I realize I've already got #4723 open as "no idea why this is SEGV," but this trace looked notably different, so I'm filing separate. I'm going to continue debugging along the lines of #4723, which was leaning towards OpenSSL. But if anything jumps out at somebody from this trace, feel free to speak up. As it turns out, this was near a batch of a large number of DELs. Might be good to take a glance through slog or similar and see if a memory debugger comes up clean, especially with deletes...

1 0

Re: (ITS#4770) monitoringslapd.sdf patch
by ghenry＠suretecsystems.com 07 Dec '06

07 Dec '06

<quote who="Howard Chu"> > ghenry(a)suretecsystems.com wrote: >> Full_Name: Gavin Henry >> Version: 2.3.30 >> OS: FC6 >> URL: http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch >> Submission from: (NULL) (212.159.59.85) >> >> >> Hi all, >> >> Monitoring section updated. Please review and provide feedback. >> >> Thanks, >> >> Gavin. >> >> (http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch) >> > At the moment the only comment I have is regarding back-monitor itself, > not the doc: I question the decision to define the monitor info > attributes as operational instead of user attributes. Requiring the use > of "+" to return all of the monitored info seems pretty unfriendly, > particularly since it causes the return of actual operational attributes > that are completely irrelevant to the purpose of monitoring. I.e., the > monitor info should be considered to be dynamically generated user > attributes, not operational attributes. OK. So what would be the next step, re-work it? Just let me know the changes so I can document them. There's nothing like documenting a moving target! ;-) Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Re: (ITS#4770) monitoringslapd.sdf patch
by hyc＠symas.com 07 Dec '06

07 Dec '06

ghenry(a)suretecsystems.com wrote: > Full_Name: Gavin Henry > Version: 2.3.30 > OS: FC6 > URL: http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch > Submission from: (NULL) (212.159.59.85) > > > Hi all, > > Monitoring section updated. Please review and provide feedback. > > Thanks, > > Gavin. > > (http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch) > At the moment the only comment I have is regarding back-monitor itself, not the doc: I question the decision to define the monitor info attributes as operational instead of user attributes. Requiring the use of "+" to return all of the monitored info seems pretty unfriendly, particularly since it causes the return of actual operational attributes that are completely irrelevant to the purpose of monitoring. I.e., the monitor info should be considered to be dynamically generated user attributes, not operational attributes. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4771) Memory Leak in connection.c
by marco.dettorre＠sys-net.it 07 Dec '06

07 Dec '06

Full_Name: Marco D'Ettorre Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.214.117.67) There is a memory leak in connection_op_queue (servers/slapd/connection.c +1821). A fix for this: --- servers/slapd/connection.c.orig 2006-12-07 18:30:14.000000000 +0100 +++ servers/slapd/connection.c 2006-12-07 19:07:09.000000000 +0100 @@ -1751,6 +1751,9 @@ { op->o_conn->c_sasl_bindop = NULL; + ch_free( op->o_callback ); + op->o_callback = NULL; + return SLAP_CB_CONTINUE; } Regards Marco

1 0

(ITS#4770) monitoringslapd.sdf patch
by ghenry＠suretecsystems.com 07 Dec '06

07 Dec '06

Full_Name: Gavin Henry Version: 2.3.30 OS: FC6 URL: http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch Submission from: (NULL) (212.159.59.85) Hi all, Monitoring section updated. Please review and provide feedback. Thanks, Gavin. (http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch) -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

freeing mem from ldap_parse_result
by Dale Moore 06 Dec '06

06 Dec '06

I'm trying to write exceptionally correct code with no memory leaks. I'm calling ldap_parse_result(3). And of course one of the parameters is char ***referalsp; The documentation says to free the memory allocated to this data structure by calling the routine ldap_value_free(). But the routine ldap_value_free() is deprecated. My options are - Compile with -DLDAP_DEPRECATED = I hate to create software using deprecated API - Call ber_memvfree((void **)) instead of ldap_value_free() - Use a different mechanism to parse the message The bug I'm reporting here is - a problem with the documentation or - in the premature deprecation of ldap_value_free or - the lack of deprecation of ldap_parse_ressult() I'm not sure which. Looking for advice. Dale Moore

2 1

Re: ITS#3812 database config documentation
by raphael.ouazana＠linagora.com 06 Dec '06

06 Dec '06

On Jeu 16 novembre 2006 12:09, hyc(a)symas.com wrote: > I've committed a preliminary slapd-config.5 manpage to HEAD. In > anticipation of deleting slurpd from RE24, I have commented out all of > the slurpd-related keywords. Most of the text is the same as in > slapd.conf(5) but I've changed the organization to better reflect the > actual implementation. > > There may be options that I've missed. Please review and send patches / > corrections / comments. Thank you very much for this work. I've only some comments. Even if it is shown in the Examples part, I think the use of slapd.conf and slapd.d at the same time should be explained as it is in slapd(8). Furthermore slapd-config(5) make references to slapd-bdb(5), slapd-ldap(5) and others but these pages use old config style. Maybe you could add in a first time a note to indicate that users should add olc prefix to use these directives in cn=config branch. Of course I hope every pages will be updated one day... Raphael Ouazana. PS: I'm not able to see slapd-config(5) with man.cgi on the website (even if I use OpenLDAP 2.X-Devel). Is it normal ?

1 0

(ITS#4769) conditional as macro argument may be invalid
by ando＠sys-net.it 06 Dec '06

06 Dec '06

Full_Name: Pierangelo Masarati Version: HEAD, >= 2.3.29 OS: Solaris 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.214.117.67) There's a conditional in a macro argument in connection.c that gcc (actually, cpp) 3.4.2 doesn't like. The fix will be shortly in HEAD/re23. p.

1 0

(ITS#4768) test043-delta-syncrepl: line 55: 10507 Aborted
by michael＠stroeder.com 05 Dec '06

05 Dec '06

Full_Name: Michael Ströder Version: HEAD OS: SuSE Linux 10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (77.177.36.63) $ ./run -b bdb test043 Cleaning up test run directory leftover from previous run. Running ./scripts/test043-delta-syncrepl... running defines.sh Starting master slapd on TCP/IP port 9011... ./scripts/test043-delta-syncrepl: line 55: 10507 Aborted $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING >$LOG1 2>&1 Using ldapsearch to check that master slapd is running... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ldapsearch failed (255)! ./scripts/test043-delta-syncrepl: line 71: kill: (10507) - No such process

1 0

Re: (ITS#4767) test034-translucent: line 369: 9807 Segmentation fault
by michael＠stroeder.com 05 Dec '06

05 Dec '06

Seems to be ok now (synced HEAD). Ciao, Michael.

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