openldap-bugs May 2007

openldap-bugs@openldap.org

42 participants
156 discussions

Re: Re: (ITS#4960) the memory increase qu ickly and not can be released sometime.
by hoverwf＠126.com 14 May '07

14 May '07

--Boundary-=_SZaDxDIRyRIDxknkKcOniAdrRNpg Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable more infomation: =20 =20 NOTE 1: i comment the code in the inner for loop of attribute. =20 NOTE 2: the output of valgrind shows: =3D=3D879=3D=3D=20 =3D=3D879=3D=3D 62,130 bytes in 6,013 blocks are definitely lost in loss = record 10 of 10 =3D=3D879=3D=3D at 0x401B704: malloc (vg_replace_malloc.c:149) =3D=3D879=3D=3D by 0x4441987: ber_memalloc_x (in /usr/lib/liblber-2.3.= so.0.2.9) =3D=3D879=3D=3D by 0x443ECA6: ber_get_stringbv (in /usr/lib/liblber-2.= 3.so.0.2.9) =3D=3D879=3D=3D by 0x443ED1E: ber_get_stringa (in /usr/lib/liblber-2.3= =2Eso.0.2.9) =3D=3D879=3D=3D by 0x443F3EE: ber_scanf (in /usr/lib/liblber-2.3.so.0.= 2.9) =3D=3D879=3D=3D by 0x4161C67: ldap_next_attribute (in /usr/lib/libldap= -2.3.so.0.2.9) =3D=3D879=3D=3D by 0x80AC0E0: search_node_bydn (myprogram.c:1744) =20 =20 =20 =20 =D4=DA2007-05-14=A3=ACopenldap-its(a)openldap.org =D0=B4=B5=C0=A3=BA *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#4960. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#4960) in the subject will automatically be attached to the issue report. =09mailto:openldap-its@openldap.org?subject=3D(ITS#4960) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=3D4960 Please remember to retain your issue tracking number (ITS#4960) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. =09http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2006 The OpenLDAP Foundation, All Rights Reserved. --Boundary-=_SZaDxDIRyRIDxknkKcOniAdrRNpg Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable <DIV>more infomation:</DIV> <DIV> </DIV> <DIV> </DIV> <DIV>NOTE 1:  i comment the code in the inner for loop of attribute.= </DIV> <DIV> </DIV> <DIV>NOTE 2: the output of valgrind shows:</DIV> <DIV>=3D=3D879=3D=3D <BR>=3D=3D879=3D=3D 62,130 bytes in 6,013 blocks are= definitely lost in loss record 10 of 10<BR>=3D=3D879=3D=3D  &n= bsp; at 0x401B704: malloc (vg_replace_malloc.c:149)<BR>=3D=3D879=3D=3D&nb= sp;   by 0x4441987: ber_memalloc_x (in /usr/lib/liblber-2.3.so.= 0.2.9)<BR>=3D=3D879=3D=3D    by 0x443ECA6: ber_get_stringb= v (in /usr/lib/liblber-2.3.so.0.2.9)<BR>=3D=3D879=3D=3D   = by 0x443ED1E: ber_get_stringa (in /usr/lib/liblber-2.3.so.0.2.9)<BR>=3D=3D= 879=3D=3D    by 0x443F3EE: ber_scanf (in /usr/lib/liblber-= 2.3.so.0.2.9)<BR>=3D=3D879=3D=3D    by 0x4161C67: ldap_nex= t_attribute (in /usr/lib/libldap-2.3.so.0.2.9)<BR>=3D=3D879=3D=3D &n= bsp;  by 0x80AC0E0: search_node_bydn (myprogram.c:1744)</DIV> <DIV><BR> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV ></DIV><BR>=D4=DA2007-05-14=A3=ACopenldap-its(a)openldap.org =D0=B4=B5= =C0=A3=BA<BR> <BLOCKQUOTE style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER= -LEFT: #ccc 1px solid"><PRE style=3D"WORD-WRAP: break-word">*** THIS IS A= N AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#4960. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#4960) in the subject will automatically be attached to the issue report. =09<A href=3D"mailto:openldap-its@openldap.org?subject=3D" target=3D_new>= mailto:openldap-its@openldap.org?subject=3D</A>(ITS#4960) You may follow the progress of this report by loading the following URL in a web browser: <A href=3D"http://www.openldap.org/its/index.cgi?findid=3D4960" targe= t=3D_new>http://www.OpenLDAP.org/its/index.cgi?findid=3D4960</A> Please remember to retain your issue tracking number (ITS#4960) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. =09<A href=3D"http://www.openldap.org/support/" target=3D_new>http://www.= OpenLDAP.org/support/</A> -------------- Copyright 1998-2006 The OpenLDAP Foundation, All Rights Reserved. </PRE></BLOCKQUOTE><br><br><hr> <a style=3D"font-size:14px;line-height:15px; color:#000; text-decoration:= none" href=3D"http://event.mail.163.com/chanel/xyq.htm?from=3D126" target= =3D"_blank"><span style=3D"text-decoration:underline; color:blue">=C3=E2=B7= =D1=CA=D4=CD=E62006=D6=D0=B9=FA=D7=EE=BC=D1=CD=F8=C2=E7=D3=CE=CF=B7--=C3=CE= =BB=C3=CE=F7=D3=CE </span> </a> --Boundary-=_SZaDxDIRyRIDxknkKcOniAdrRNpg--

1 0

(ITS#4963) Sub-second ldap_search timeout accuracy
by cs＠unc.edu 14 May '07

14 May '07

Full_Name: Christian Schlatter Version: CVS HEAD (Mon May 14 15:21:36 EDT 2007) OS: ubuntu dapper URL: http://www.unc.edu/~cschlatt/openldap/result.patch Submission from: (NULL) (152.2.199.72) I'm developing an LDAP module for the OpenSER SIP server using OpenLDAP libldap. Since this is a real-time application I need to be able to set LDAP timeouts to a value less than a second. This isn't possible with the existing libldap ldap_result(...timeout...) implementation. In particular, the timeout check at the end of function wait4msg(..) in result.c only has an accuracy of one second. This lead to unexpected behavior for timeout values that are less than a second. I've added a patch for your consideration that adds sub-second accuracy to wait4msg. The code works for me but I don't have experience with the OpenLDAP source code and any coding guidelines. Nevertheless, I'd be very glad if this functionality could be incorporated in a future OpenLDAP release. Christian

1 0

(ITS#4962) inconsistent Bind(rootdn) behavior
by h.b.furuseth＠usit.uio.no 14 May '07

14 May '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard Backends are quite inconsistent about how Bind treats rootdn/rootpw. After a quick browse of the HEAD code, it looks like this - I'll investigate closer if needed: rootpw supported: Yes: config, bdb, meta, monitor, ldif, HEAD:null, sql, overlay retcode. No: dnssrv, ldap?, RE23:null, perl, relay, shell. (Bind not supported: passwd). Rootpw vs. normal Bind as rootdn (typically when rootdn names an entry): config, bdb, null, sql, overlay retcode (I think): Try rootpw first, then if failure try normal Bind (even if rootpw exists but the Bind password does not match it). ldif: Do not try rootpw if rootdn names an existing entry. meta: Fail if rootpw is missing or does not match, more complicated otherwise. monitor: Fine - there are no entries with passwords. The manpage is (fortunately:-) unclear on what happens in this case. Check if op->orb_method == LDAP_AUTH_SIMPLE: Yes: config, bdb, meta, monitor. No: ldif, null, sql, overlay retcode. Set op->orb_edn (op->oq_bind.rb_edn) from be_root_dn() on success: config, bdb, monitor, sql. Set op->orb_edn on failure: bdb: Sometimes, from &e->e_name. sql: Always, from op->o_req_ndn. Set rs->sr_err = LDAP_SUCCESS on success: ldif, meta Reset rs->sr_text: meta Which behavior is right? I'm wondering if Bind should fail if rootpw exists but the Bind password does not match it. In any case, methinks we need a be_rootpw_bind(op, rs) function which takes care of this consistently, so bi_op_bind in most cases can just do if (be_rootpw_bind(op, rs)) return rs->sr_err; If needed it could accept rs==NULL to just check the password - like be_isroot_pw() but with more return codes to distinguish different cases.

1 0

(ITS#4961) If database suffix is "" slapd cannot update ContextCSN
by ali.pouya＠free.fr 14 May '07

14 May '07

Full_Name: Ali Pouya Version: 2.4.4alpha OS: Linux RedHat AS4 (kernel 2.6) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.3.30) I'm esting OpenLdap 2.4.4alpha with syncrepl for future use. If the BDB data base suffix is "" then slapd cannot update the ContextCSN attribute (while with OpenLdap 2.3.35 it's OK). This makes impossible replica syncronization. When I stop slapd I see the following lines in the log. I can submit more information if required. Thanks Best Regards Ali ============================ Log Extract : daemon: shutdown requested and initiated. daemon: closing 7 slapd shutdown: waiting for 0 threads to terminate slapd shutdown: initiated bdb_modify: bdb_dn2entry("") bdb_modify_internal: 0x00000000: <= acl_access_allowed: granted to database root bdb_modify_internal: replace contextCSN is_entry_objectclass("", "2.5.17.0") no objectClass attribute No objectClass for entry () entry failed schema check: no objectClass attribute bdb_modify: modify failed (65) send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=65 matched="" text="no objectClass attribute" ====> bdb_cache_release_all slapd destroy: freeing system resources. slapd stopped.

1 0

(ITS#4960) the memory increase quickly and not can be released sometime.
by hoverwf＠126.com 14 May '07

14 May '07

Full_Name: wang fei Version: OpenLDAP 2.3.21 OS: slackware URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (220.167.25.214) descirption: i use the following code to get the info of the entry whose DN matches "search dn". the problem: when i call this function many times(eg: more then 1000 times), the result will be correct, but for about one or two times, after i call ldap_search_ext_s(). the memory will increase dramitically (usually 128K, i use system("ps aux | grep /myprogram") to find the memory it is used). and when i ldap_msgfree(res). it only 4K memory is released. but the other 998 times does not has this problem(the memory will not increase). All these nodes have similar attribute except dn and cn. when i disable the code of the inner for loop. this problem appear less frequently. when i disable the code which get the attribute value of entry, in other word, both the for loop. this problem seems disappeared, but it maybe it will appear again if it is runed more times. // portion code of the program static int search_node_bydn(char *search_dn) { int ret; char *a = NULL, *attrs[10], *dn; char filter[1024]; LDAPMessage *e=NULL, *res = NULL; LDAP *ld = NULL; struct timeval timeout; // open the connection... // bind ... // then search the node.... attrs[0] = "objectGUID"; attrs[1] = "modifyTimeStamp"; attrs[2] = "cn"; attrs[3] = "sAMAccountName"; attrs[4] = "objectClass"; attrs[5] = "name"; attrs[6] = NULL; snprintf(filter, 1024, "(objectClass=*)"); timeout.tv_sec = 1000; system("ps aux | grep /myprogram"); ret = ldap_search_ext_s(ld, search_dn, LDAP_SCOPE_BASEOBJECT,filter, attrs, 0, NULL, NULL, &timeout, 0, &res); if (ret != LDAP_SUCCESS) { printf("search node %s error: %s\n", search_dn, ldap_err2string(ret)); ldap_msgfree(res); ldap_unbind_ext(ld, NULL, NULL); return (-1); } system("ps aux | grep /myprogram"); #if 1 // get the attribute value of entry. for (e = ldap_first_entry(ld, res); e != NULL; e = ldap_next_entry(ld, e)) { #if 1 BerElement *ptr = NULL; for (a = ldap_first_attribute(ld, e, &ptr); a != NULL; a = ldap_next_attribute(ld, e, ptr)) { // do sth with the attribute. }// inner for loop if(ptr != NULL) { ber_free(ptr,0); } #endif }// outer for loop #endif system("ps aux | grep /myprogram"); ldap_msgfree(res); res = NULL; system("ps aux | grep /myprogram"); ldap_unbind_ext(ld, NULL, NULL); return OK; }

1 0

(ITS#4959) replica seg faults if syncrepl searchbase =""
by ali.pouya＠free.fr 14 May '07

14 May '07

Full_Name: Ali Pouya Version: 2.4.4alpha OS: Linux RedHat AS4 (kernel 2.6) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.3.30) I'm testing OpenLdap 2.4.4alpha for future use. I have a master and a replica. In the replica's syncrepl configuration has searchbase="" then the replica seg faults after connecting to the master. The core backtrace shows very little information : (gdb) bt #0 0x00179d5a in strcmp () from /lib/tls/libc.so.6 #1 0x08068ede in ?? () #2 0x098c0d50 in ?? () #3 0x00000000 in ?? () (gdb) Below I add the end of the slapd detailed log. I can send any other information required. Thanks and best regards Ali Pouya Log extract : ** ld 0x991dcf8 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x991dcf8 request count 1 (abandoned 0) ** ld 0x991dcf8 Response Queue: Empty ld 0x991dcf8 response count 0 ldap_chkResponseList ld 0x991dcf8 msgid 1 all 1 ldap_chkResponseList returns ld 0x991dcf8 NULL ldap_int_select read1msg: ld 0x991dcf8 msgid 1 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 01 61 07 0a 0....a.. ldap_read: want=6, got=6 0000: 01 00 04 00 04 00 ...... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0x099270b8 ptr=0x099270b8 end=0x099270c4 len=12 0000: 02 01 01 61 07 0a 01 00 04 00 04 00 ...a........ read1msg: ld 0x991dcf8 msgid 1 message type bind ber_scanf fmt ({eAA) ber: ber_dump: buf=0x099270b8 ptr=0x099270bb end=0x099270c4 len=9 0000: 61 07 0a 01 00 04 00 04 00 a........ read1msg: ld 0x991dcf8 0 new referrals read1msg: mark request completed, ld 0x991dcf8 msgid 1 request done: ld 0x991dcf8 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x099270b8 ptr=0x099270bb end=0x099270c4 len=9 0000: 61 07 0a 01 00 04 00 04 00 a........ ber_scanf fmt (}) ber: ber_dump: buf=0x099270b8 ptr=0x099270c4 end=0x099270c4 len=0 ldap_msgfree Erreur de segmentation (core dumped)

1 0

(ITS#4958) slapd segfaults when overlay rwm, suffixmassage is used in conjunction with empty suffix
by nvoutsin＠noc.uoa.gr 14 May '07

14 May '07

Full_Name: Nikos Voutsinas Version: 2.3.35 OS: Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.134.100.39) As ando already said: .....it tries to lookup a database to relay for when unbinding, but unbind has no DN, so a strcmp on NULL is performed. This does not happen when using the "relay" directive because relay database selection does not occur for each operation.... configuration example: database bdb suffix "dc=real,dc=naming,dc=context" .... .... .... database relay suffix "" overlay rwm suffixmassage "dc=real,dc=naming,dc=context"

1 0

Re: (ITS#4930) slaptest should be quiet on success
by jsafrane＠redhat.com 14 May '07

14 May '07

On Fri, 2007-05-11 at 22:07 +0200, Pierangelo Masarati wrote: > jsafranek(a)redhat.com wrote: > > > The 'slaptest' tool is a bit verbose, it sends 'config file testing succeeded' > > to stderr. IMHO it should do not output anything, especially to stderr, if > > everything is all right. > > > > Here is a small patch, causing the slaptest to display the aforementioned > > message only if -v switch is used: > > Your issue may make sense in some cases, but I'd rather reverse its > logic and avoid printing any message only when explicitly requested to > be "quiet" (e.g. adding a -Q switch?) Why not, I have basically nothing against -Q switch, but it would require a bit more changes in the current sources. I just needed something quick-and-not-so-dirty. Jan

1 0

Re: (ITS#4951) [contrib] RADIUS password module fixes
by ando＠sys-net.it 13 May '07

13 May '07

richton(a)nbcs.rutgers.edu wrote: > * libradius makes use of MT-Unsafe calls, so a protecting mutex is added. applied to HEAD > * config_filename could be passed to rad_config without initialization (when > accepting the default). rejected: global variables are always zeroed. Please test. Thanks, 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4957) destroying uninitialized mutexed after failed startup
by ando＠sys-net.it 13 May '07

13 May '07

h.b.furuseth(a)usit.uio.no wrote: > (I haven't committed to non-HEAD for ages, I don't rememer if I > just commit it or if there are more formalities involved?) Commit; if appropriate, note in CHANGES. Someone else (the Chief Architect) will move tags. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

← Newer
1
...
8
9
10
11
12
13
14
15
16
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 May 2007