openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

(ITS#6284) New libtoolized autogroup Makefile broken
by ryans＠aweber.com 04 Sep '09

04 Sep '09

Full_Name: Ryan Steele Version: 2.4.17 OS: Ubuntu 8.04 LTD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (207.106.239.81) The latest Makefile for autogroup in CVS HEAD (v1.2 of the Makefile), which was libtoolized by manu, is broken. See the following output of 'make': mode=link cc -version-info 0:0:0 \ -rpath /lib -module -o autogroup.la autogroup.lo gcc-4.2.real: 0:0:0: No such file or directory gcc-4.2.real: autogroup.lo: No such file or directory gcc-4.2.real: unrecognized option '-version-info' gcc-4.2.real: unrecognized option '-rpath' make: [autogroup.la] Error 1 (ignored) I believe it is because the rule for 'autogroup.la' incorrectly passes the options -version-info and -rpath to gcc. As an independent example of the same type of issue, consider this mailing list posting: http://sourceware.org/ml/automake/1999-04/msg00337.html - the issues are identical.

1 0

Re: (ITS#6281) Duplicate entries when changing DN on newly created consumer
by tjaviss＠gmail.com 04 Sep '09

04 Sep '09

UPDATE: this appears to be a case of user-error the ldapsearch was not pulling the entryUUID because of a malformed search line. The required syntax for the "attrs" (last part of line) should have been '*' '+' when making a dump. Omitting the '+' caused LDAP to regenerate the entryUUIDs on the consumer, which would then subsequently mess up syncing operations Please accept my apologies and close this entry - TJA

1 0

(ITS#6283) Missing $LDAP<option>s
by h.b.furuseth＠usit.uio.no 04 Sep '09

04 Sep '09

Full_Name: Hallvard B Furuseth Version: RE24 OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard env LDAP<option>=value ./ldapsearch ... does not work for these variables: $LDAPGSSAPI_ALLOW_REMOTE_PRINCIPAL (LDAP_OPT_X_GSSAPI_ALLOW_REMOTE_PRINCIPAL) $LDAPGSSAPI_ENCRYPT (LDAP_OPT_ENCRYPT) $LDAPGSSAPI_SIGN (LDAP_OPT_SIGN) $LDAPNETWORK_TIMEOUT (LDAP_OPT_NETWORK_TIMEOUT) $LDAPTIMEOUT (LDAP_OPT_TIMEOUT) $LDAPVERSION (LDAP_OPT_PROTOCOL_VERSION) because libldap/init.c:openldap_ldap_init_w_env() does not handle options with attrs[].type == <ATTR_GSSAPI, ATTR_OPT_TV,ATTR_OPT_INT>.

1 0

Re: (ITS#6282) Assertion failure in openldap clients when server is frozen and limits are in place
by h.b.furuseth＠usit.uio.no 04 Sep '09

04 Sep '09

I think hitting an assert is always a bug, while exit(nonzero) is fine. Looks like a small fix anyway, if that's all there is to it. A quick grep found that back-ldap and back-meta also try to use the result message from ldap_result()==0. -- Hallvard

1 0

Re: (ITS#6282) Assertion failure in openldap clients when server is frozen and limits are in place
by hyc＠symas.com 04 Sep '09

04 Sep '09

Hallvard B Furuseth wrote: > Easily reproducable. Great, thanks. But there's nothing useful to fix here. If the ldap_result call doesn't return a result message, the only thing the client could do is exit(LDAP_LOCAL_ERROR) as the other failure cases do. I.e., because a connection has already been established, the library will not do any fallback. It only tries to fallback if the TCP connection attempt fails. I'm inclined to ignore this ITS since avoiding the assert() won't change the actual outcome of the command. > ./configure --without-tls --without-cyrus-sasl --disable-slapd CFLAGS="-O0 -g" > make -s > > echo TIMEOUT 1> ldaprc > > : Run a listening "server" which just sleeps > python -c 'import time; from socket import *; s = socket(AF_INET, SOCK_STREAM); s.bind(("localhost", 3890)); s.listen(5); time.sleep(9999)'& > > gdb -q clients/tools/ldapsearch > (gdb) run -xh localhost:3890 > ldapsearch: error.c:255: ldap_parse_result: Assertion `r != ((void *)0)' failed. > > (gdb) backtrace > #0 0x00002b811748d265 in raise () from /lib64/libc.so.6 > #1 0x00002b811748ed10 in abort () from /lib64/libc.so.6 > #2 0x00002b81174866e6 in __assert_fail () from /lib64/libc.so.6 > #3 0x0000000000413234 in ldap_parse_result (ld=0x65a7170, r=0x0, errcodep=0x7fffc814f1a8, matcheddnp=0x7fffc814f190, errmsgp=0x7fffc814f188, > referralsp=0x7fffc814f180, serverctrls=0x7fffc814f198, freeit=1) at error.c:255 > #4 0x0000000000408cfd in tool_bind (ld=0x65a7170) at common.c:1422 > #5 0x0000000000403fef in main (argc=3, argv=0x7fffc8153508) at ldapsearch.c:912 > (gdb) frame 4 > #4 0x0000000000408cfd in tool_bind (ld=0x65a7170) at common.c:1422 > 1422 rc = ldap_parse_result( ld, result,&err,&matched,&info,&refs, > (gdb) info locals > err = 0 > msgbuf = "\000\000\000\000\000\000\000\000\0005e\000\000\000\000\000(\000\000\000\021\000\000\000pqZ\006\000\000\000\000Àð\024Èÿ\177\000\000PpZ\006\000\000\000\000 rZ\006\000\000\000\000xqZ\006", '\0'<repeats 12 times>, "0óZ\006\000\000\000\000ðð\024Èÿ\177\000\000\025ú@", '\0'<repeats 13 times>, " ñ\024Èÿ\177\000\000pqZ\006\000\000\000\000\2008e\000\000\000\000\0000ñ\024Èÿ\177\000\000Qû@\000\000\000\000\0000ñ\024Èÿ\177\000\000`\216B\000\000\000\000\000PpZ\006\000\000\000\000ðñ\024Èÿ\177\000\000\003\000\000\000\000\000\000\000pqZ\006\000\000\000\000Pò\024Èÿ\177\000\000°\211@\000\000"... > info = 0x0 > refs = (char **) 0x0 > msgid = 1 > rc = 0 > result = (LDAPMessage *) 0x0 > ctrls = (LDAPControl **) 0x0 > matched = 0x0 > sctrlsp = (LDAPControl **) 0x0 > sctrls = {0x0, 0x65a7020, 0x443b26} > sctrl = {{ldctl_oid = 0xffffffff<Address 0xffffffff out of bounds>, ldctl_value = {bv_len = 0, bv_val = 0x0}, ldctl_iscritical = 0 '\0'}, { > ldctl_oid = 0x65a7050 "ldap://localhost:3890", ldctl_value = {bv_len = 106590352, bv_val = 0x4fc2<Address 0x4fc2 out of bounds>}, > ldctl_iscritical = -43 'Õ'}, {ldctl_oid = 0x65a7170 "0óZ\006", ldctl_value = {bv_len = 388262848, bv_val = 0x7fffc8153420 ""}, > ldctl_iscritical = -110 '\222'}} > nsctrls = 0 > __PRETTY_FUNCTION__ = "tool_bind" > -- -- 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#6282) Assertion failure in openldap clients when server is frozen and limits are in place
by h.b.furuseth＠usit.uio.no 04 Sep '09

04 Sep '09

Meh. Looks like ITS strips the quoted-printable header. Trying again, after editing away strings with 8-bit characters. BTW, this was a RE24 backtrace. Easily reproducable. ./configure --without-tls --without-cyrus-sasl --disable-slapd CFLAGS="-O0 -g" make -s echo TIMEOUT 1 > ldaprc : Run a listening "server" which just sleeps python -c 'import time; from socket import *; s = socket(AF_INET, SOCK_STREAM); s.bind(("localhost", 3890)); s.listen(5); time.sleep(9999)' & gdb -q clients/tools/ldapsearch (gdb) run -xh localhost:3890 ldapsearch: error.c:255: ldap_parse_result: Assertion `r != ((void *)0)' failed. (gdb) backtrace #0 0x00002b811748d265 in raise () from /lib64/libc.so.6 #1 0x00002b811748ed10 in abort () from /lib64/libc.so.6 #2 0x00002b81174866e6 in __assert_fail () from /lib64/libc.so.6 #3 0x0000000000413234 in ldap_parse_result (ld=0x65a7170, r=0x0, errcodep=0x7fffc814f1a8, matcheddnp=0x7fffc814f190, errmsgp=0x7fffc814f188, referralsp=0x7fffc814f180, serverctrls=0x7fffc814f198, freeit=1) at error.c:255 #4 0x0000000000408cfd in tool_bind (ld=0x65a7170) at common.c:1422 #5 0x0000000000403fef in main (argc=3, argv=0x7fffc8153508) at ldapsearch.c:912 (gdb) frame 4 #4 0x0000000000408cfd in tool_bind (ld=0x65a7170) at common.c:1422 1422 rc = ldap_parse_result( ld, result, &err, &matched, &info, &refs, (gdb) info locals err = 0 msgbuf = ... info = 0x0 refs = (char **) 0x0 msgid = 1 rc = 0 result = (LDAPMessage *) 0x0 ctrls = (LDAPControl **) 0x0 matched = 0x0 sctrlsp = (LDAPControl **) 0x0 sctrls = {0x0, 0x65a7020, 0x443b26} sctrl = {{ldctl_oid = 0xffffffff <Address 0xffffffff out of bounds>, ldctl_value = {bv_len = 0, bv_val = 0x0}, ldctl_iscritical = 0 '\0'}, { ldctl_oid = 0x65a7050 "ldap://localhost:3890", ldctl_value = {bv_len = 106590352, bv_val = 0x4fc2 <Address 0x4fc2 out of bounds>}, ldctl_iscritical = -43}, {ldctl_oid = 0x65a7170, ldctl_value = {bv_len = 388262848, bv_val = 0x7fffc8153420 ""}, ldctl_iscritical = -110 '\222'}} nsctrls = 0 __PRETTY_FUNCTION__ = "tool_bind" -- Hallvard

1 0

Re: (ITS#6282) Assertion failure in openldap clients when server is frozen and limits are in place
by h.b.furuseth＠usit.uio.no 04 Sep '09

04 Sep '09

Easily reproducable. ./configure --without-tls --without-cyrus-sasl --disable-slapd CFLAGS=3D= "-O0 -g" make -s echo TIMEOUT 1 > ldaprc : Run a listening "server" which just sleeps python -c 'import time; from socket import *; s =3D socket(AF=5FINET, S= OCK=5FSTREAM); s.bind(("localhost", 3890)); s.listen(5); time.sleep(999= 9)' & gdb -q clients/tools/ldapsearch (gdb) run -xh localhost:3890 ldapsearch: error.c:255: ldap=5Fparse=5Fresult: Assertion `r !=3D ((voi= d *)0)' failed. (gdb) backtrace #0 0x00002b811748d265 in raise () from /lib64/libc.so.6 #1 0x00002b811748ed10 in abort () from /lib64/libc.so.6 #2 0x00002b81174866e6 in =5F=5Fassert=5Ffail () from /lib64/libc.so.6 #3 0x0000000000413234 in ldap=5Fparse=5Fresult (ld=3D0x65a7170, r=3D0x= 0, errcodep=3D0x7fffc814f1a8, matcheddnp=3D0x7fffc814f190, errmsgp=3D0x= 7fffc814f188,=20 referralsp=3D0x7fffc814f180, serverctrls=3D0x7fffc814f198, freeit=3D= 1) at error.c:255 #4 0x0000000000408cfd in tool=5Fbind (ld=3D0x65a7170) at common.c:1422= #5 0x0000000000403fef in main (argc=3D3, argv=3D0x7fffc8153508) at lda= psearch.c:912 (gdb) frame 4 #4 0x0000000000408cfd in tool=5Fbind (ld=3D0x65a7170) at common.c:1422= 1422 rc =3D ldap=5Fparse=5Fresult( ld, result, &err,= &matched, &info, &refs, (gdb) info locals err =3D 0 msgbuf =3D "\000\000\000\000\000\000\000\000\0005e\000\000\000\000\000(= \000\000\000\021\000\000\000pqZ\006\000\000\000\000=C0=F0\024=C8=FF\177= \000\000PpZ\006\000\000\000\000=A0rZ\006\000\000\000\000xqZ\006", '\0' = <repeats 12 times>, "0=F3Z\006\000\000\000\000=F0=F0\024=C8=FF\177\000\= 000\025=FA@", '\0' <repeats 13 times>, " =F1\024=C8=FF\177\000\000pqZ\0= 06\000\000\000\000\2008e\000\000\000\000\0000=F1\024=C8=FF\177\000\000Q= =FB@\000\000\000\000\0000=F1\024=C8=FF\177\000\000`\216B\000\000\000\00= 0\000PpZ\006\000\000\000\000=F0=F1\024=C8=FF\177\000\000\003\000\000\00= 0\000\000\000\000pqZ\006\000\000\000\000P=F2\024=C8=FF\177\000\000=B0\2= 11@\000\000"... info =3D 0x0 refs =3D (char **) 0x0 msgid =3D 1 rc =3D 0 result =3D (LDAPMessage *) 0x0 ctrls =3D (LDAPControl **) 0x0 matched =3D 0x0 sctrlsp =3D (LDAPControl **) 0x0 sctrls =3D {0x0, 0x65a7020, 0x443b26} sctrl =3D {{ldctl=5Foid =3D 0xffffffff <Address 0xffffffff out of bound= s>, ldctl=5Fvalue =3D {bv=5Flen =3D 0, bv=5Fval =3D 0x0}, ldctl=5Fiscri= tical =3D 0 '\0'}, { ldctl=5Foid =3D 0x65a7050 "ldap://localhost:3890", ldctl=5Fvalue =3D= {bv=5Flen =3D 106590352, bv=5Fval =3D 0x4fc2 <Address 0x4fc2 out of bo= unds>},=20 ldctl=5Fiscritical =3D -43 '=D5'}, {ldctl=5Foid =3D 0x65a7170 "0=F3= Z\006", ldctl=5Fvalue =3D {bv=5Flen =3D 388262848, bv=5Fval =3D 0x7fffc= 8153420 ""},=20 ldctl=5Fiscritical =3D -110 '\222'}} nsctrls =3D 0 =5F=5FPRETTY=5FFUNCTION=5F=5F =3D "tool=5Fbind" --=20 Hallvard

1 0

Re: (ITS#6282) Assertion failure in openldap clients when server is frozen and limits are in place
by Guillaume.Rousse＠inria.fr 04 Sep '09

04 Sep '09

Howard Chu a écrit : > Please provide the stack trace from this assert. Too late... Let's wait for next occurence of the problem. -- BOFH excuse #176: vapors from evaporating sticky-note adhesives

1 0

Re: (ITS#6282) Assertion failure in openldap clients when server is frozen and limits are in place
by hyc＠symas.com 04 Sep '09

04 Sep '09

Guillaume.Rousse(a)inria.fr wrote: > Full_Name: Guillaume Rousse > Version: 2.4.17 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.55.250.67) > > > With a frozen server, the following client configuration make ldapsearch fails > an assertion: > BASE dc=futurs,dc=inria,dc=fr > URI ldap://ldap.saclay.inria.fr ldap://ldap.lille.inria.fr > TLS_CACERTDIR /etc/pki/tls/rootcerts > TLS_REQCERT demand > NETWORK_TIMEOUT 2 > TIMEOUT 2 > TIMELIMIT 2 > > [rousse@stalingrad Desktop]$ ldapsearch -x > ldapsearch: error.c:272: ldap_parse_result: Assertion `r != ((void *)0)' > failed. > Abandon Please provide the stack trace from this assert. -- -- 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#6282) Assertion failure in openldap clients when server is frozen and limits are in place
by Guillaume.Rousse＠inria.fr 04 Sep '09

04 Sep '09

Full_Name: Guillaume Rousse Version: 2.4.17 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.55.250.67) With a frozen server, the following client configuration make ldapsearch fails an assertion: BASE dc=futurs,dc=inria,dc=fr URI ldap://ldap.saclay.inria.fr ldap://ldap.lille.inria.fr TLS_CACERTDIR /etc/pki/tls/rootcerts TLS_REQCERT demand NETWORK_TIMEOUT 2 TIMEOUT 2 TIMELIMIT 2 [rousse@stalingrad Desktop]$ ldapsearch -x ldapsearch: error.c:272: ldap_parse_result: Assertion `r != ((void *)0)' failed. Abandon Such error prevent the client to fallback on second server. And a graceful exit would be more appropriate. A network capture of the client-server exchange is available at http://www.zarb.org/~guillomovitch/out

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