- openldap-bugs - openldap.org

Re: (ITS#5640) slapd scans too many objects at startup
by hyc＠symas.com 18 Nov '08

18 Nov '08

ali.pouya(a)free.fr wrote: > So I checked out the HEAD last night. > The good news is that the problem is fixed now and every thing seems OK (six new > modifications have been made to syncprov.c since Nov 2, one of which being made > by Quanah and related to this issue). Not sure what you're looking at, but the CVS log clearly shows that this bug was fixed in revision 1.251 on November 2. http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/overlays/syncprov.c?… The updates after 1.252 are merely copying from HEAD to the RE24 branch. You said you pulled from HEAD on November 3, and still saw the problem. Either your checkout was wrong, or your configuration was wrong, because the fix was definitely present in HEAD by then. > So the issue can be closed :-) > Thanks again > Best Regards > Ali -- -- 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#5640) slapd scans too many objects at startup
by hyc＠symas.com 18 Nov '08

18 Nov '08

Ali Pouya wrote: > Hi Howard, > Sorry for being back again but I think that a residue of the problem of > whole tree scanning persists : > The improvement is that it only happens once if the mirrors are not > synchronized (the later statups are OK). That's the normal behavior for the syncrepl protocol. Read the Admin Guide or RFC4533 for details. -- -- 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#5818) Limits chapter for Admin Guide
by ghenry＠OpenLDAP.org 18 Nov '08

18 Nov '08

----- "andrew findlay" <andrew.findlay(a)skills-1st.co.uk> wrote: > Full_Name: Andrew Findlay > Version: HEAD > OS: Linux > URL: > ftp://ftp.openldap.org/incoming/andrew-findlay-limits.sdf-20081118 > Submission from: (NULL) (88.97.25.132) > > > The Admin Guide says very little about size limits and time limits. > I have supplied a chapter to remedy the lack: I suggest putting it in > after the > Access Control chapter: > > ftp://ftp.openldap.org/incoming/andrew-findlay-limits.sdf-20081118 > > Please check the section on limits for paged results extra carefully. > I found the definition in slapd.conf(5) a little ambiguous. > > I have also provided patches to the master sdf file and to the two > config > directive > chapters: > > ftp://ftp.openldap.org/incoming/andrew-findlay-limits-patch-20081118 > > Andrew Thanks Andrew, I'll review and get back to when possible. Gavin. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#5818) Limits chapter for Admin Guide
by andrew.findlay＠skills-1st.co.uk 18 Nov '08

18 Nov '08

Full_Name: Andrew Findlay Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/andrew-findlay-limits.sdf-20081118 Submission from: (NULL) (88.97.25.132) The Admin Guide says very little about size limits and time limits. I have supplied a chapter to remedy the lack: I suggest putting it in after the Access Control chapter: ftp://ftp.openldap.org/incoming/andrew-findlay-limits.sdf-20081118 Please check the section on limits for paged results extra carefully. I found the definition in slapd.conf(5) a little ambiguous. I have also provided patches to the master sdf file and to the two config directive chapters: ftp://ftp.openldap.org/incoming/andrew-findlay-limits-patch-20081118 Andrew

1 0

Re: (ITS#5817) ldapadd crashes with '-' in input
by ando＠sys-net.it 18 Nov '08

18 Nov '08

jsafrane(a)redhat.com wrote: > Full_Name: Jan Safranek > Version: 2.4.12 > OS: Linux (Fedora 9) > URL: > Submission from: (NULL) (89.102.11.105) > > > ldapadd crashes with assertion 'ldapadd: encode.c:392: ber_put_string: Assertion > `str != ((void *)0)' failed.' on following input: > > dn: nisMapName=netgroup.byhost,dc=my-domain,dc=com > nismapname: netgroup.byhost > objectClass: top > objectClass: nisMap > - > > The reason is probably at ldapmodify.c:445, where the lines containing dash are > skipped, apparently for modify operations: > > if ( line[0] == '-' && !line[1] ) { > BER_BVZERO( btype+i ); > freeval[i] = 0; > continue; > } > > ldap_add_ext() seems not to like these empty spaces. I think the fix belongs to ldap_add_ext(), as other applications may well call it with invalid parameters. I've applied a fix to HEAD code, please test. The fix is Checking in libraries/libldap/add.c; /repo/OpenLDAP/pkg/ldap/libraries/libldap/add.c,v <-- add.c new revision: 1.32; previous revision: 1.31 It hould apply straightforwardly to the release you're using. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5817) ldapadd crashes with '-' in input
by jsafrane＠redhat.com 18 Nov '08

18 Nov '08

Full_Name: Jan Safranek Version: 2.4.12 OS: Linux (Fedora 9) URL: Submission from: (NULL) (89.102.11.105) ldapadd crashes with assertion 'ldapadd: encode.c:392: ber_put_string: Assertion `str != ((void *)0)' failed.' on following input: dn: nisMapName=netgroup.byhost,dc=my-domain,dc=com nismapname: netgroup.byhost objectClass: top objectClass: nisMap - The reason is probably at ldapmodify.c:445, where the lines containing dash are skipped, apparently for modify operations: if ( line[0] == '-' && !line[1] ) { BER_BVZERO( btype+i ); freeval[i] = 0; continue; } ldap_add_ext() seems not to like these empty spaces. Full backtrace: (gdb) bt full #0 0x0000003ea4832215 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x0000003ea4833d83 in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x0000003ea482b039 in __assert_fail () from /lib64/libc.so.6 No symbol table info available. #3 0x0000000000440e0e in ber_put_string (ber=0x1573390, str=0x0, tag=18446744073709551615) at encode.c:392 __PRETTY_FUNCTION__ = "ber_put_string" #4 0x0000000000441f5e in ber_printf (ber=0x1573390, fmt=0x44b34e "s[V]N}") at encode.c:809 ap = {{gp_offset = 24, fp_offset = 48, overflow_arg_area = 0x7fffeaf5ed80, reg_save_area = 0x7fffeaf5ecc0}} s = 0x0 ss = (char **) 0x0 bv = (struct berval *) 0x7fffeaf5ecf0 bvp = (struct berval **) 0x157b718 rc = 0 i = 2 len = 0 __PRETTY_FUNCTION__ = "ber_printf" #5 0x0000000000414edd in ldap_add_ext (ld=0x15731d0, dn=0x157c714 "nisMapName=netgroup.byhost,dc=my-domain,dc=com", attrs=0x157b6e8, sctrls=0x0, cctrls=0x0, msgidp=0x7fffeaf5ee6c) at add.c:154 ber = (BerElement *) 0x1573390 i = 2 rc = 30 id = 2 __PRETTY_FUNCTION__ = "ldap_add_ext" #6 0x0000000000406c07 in domodify (dn=0x157c714 "nisMapName=netgroup.byhost,dc=my-domain,dc=com", pmods=0x157b6e8, pctrls=0x0, newentry=1) at ldapmodify.c:1094 msgid = 0 rc = -352981360 i = 3 j = 4474435 k = 0 notascii = 976894522 op = 0 bvp = (struct berval *) 0xa0 #7 0x00000000004063e9 in process_ldif_rec (rbuf=0x157c786 "", linenum=1) at ldapmodify.c:866 line = 0x0 dn = 0x157c714 "nisMapName=netgroup.byhost,dc=my-domain,dc=com" newrdn = 0x0 newsup = 0x0 rc = 0 modop = 0 expect_modop = 0 expect_sep = 0 deleteoldrdn = 1 new_entry = 1 delete_entry = 0 got_all = 0 pmods = (LDAPMod **) 0x157b6e8 lm = (LDAPMod *) 0x157b6a0 version = 0 pctrls = (LDAPControl **) 0x0 i = 5 j = 3 k = 6 lines = 5 idn = 1 nmods = 3 btype = (struct berval *) 0x157b5d0 vals = (struct berval *) 0x157b630 bvl = (struct berval **) 0x157b708 bv = {bv_len = 0, bv_val = 0x0} freeval = 0x157b690 "" mops = (unsigned char *) 0x0 #8 0x000000000040458b in main (argc=11, argv=0x7fffeaf5f178) at ldapmodify.c:341 rbuf = 0x157c710 "dn" rejbuf = 0x0 rejfp = (FILE *) 0x0 ldiffp = (struct LDIFFP *) 0x1572e50 ldifdummy = {fp = 0x0, prev = 0x0} matched_msg = 0x4473c0 "H\211l$�L\211|$�H\215-/\034!" error_msg = 0x0 rc = 0 retval = 0 len = 32767 i = 0 lineno = 1 nextline = 6 lmax = 4147 c = {{ldctl_oid = 0x7fffeaf5f020 "\214�|�����3\020", ldctl_value = {bv_len = 226974810936, bv_val = 0x3ea480ae20 "\016\001"}, ldctl_iscritical = 0 '\0'}}

1 0

RE: (ITS#5805) Problem when modifying access control
by emmanuel.duru＠atosorigin.com 18 Nov '08

18 Nov '08

Sorry the command to create the initial database is not slapadd -f configdb -l initialdatabase.ldif but slapadd -F configdb -l initialdatabase.ldif

1 0

RE: (ITS#5805) Problem when modifying access control
by emmanuel.duru＠atosorigin.com 18 Nov '08

18 Nov '08

OK, my mistake, here follows a completely detailed description. * I have a slapd.conf as follows -----------------begin slapd.conf include schema/core.schema include schema/cosine.schema include schema/inetorgperson.schema pidfile slapd.pid argsfile slapd.args access to * attrs=userPassword by self write by anonymous auth by * none access to dn=cn=manager,c=fr by self write by * none access to * by self write by users read by anonymous read by * none database bdb suffix "c=fr" rootdn "cn=manager,c=fr" cachesize 20000 checkpoint 10000 10 directory db index objectClass,entryCSN,entryUUID eq index cn,sn eq,sub -----------------end slapd.conf * I convert this slapd.conf to a configdb: slapd -f slapd.conf -F configdb * I stop slapd. * I create the initial database with the following LDIF file: -----------------begin initial database dn: c=fr objectClass: country c: fr dn: cn=manager,c=fr objectClass: person cn: manager sn: manager userPassword:: c2VjcmV0 dn: cn=user,c=fr objectClass: person cn: user sn: user userPassword:: dXNlcg== dn: cn=user2,c=fr objectClass: person cn: user2 sn: user2 userPassword:: dXNlcjI= -----------------end initial database slapadd -f configdb -l initialdatabase.ldif * I edit olcDatabase={0}config.ldif file to replace olcRootDN: cn=config by olcRootDN: cn=manager,c=fr * I start slapd slapd -d 256 -F configdb * I try to bind : ldapsearch.exe -x -D cn=manager,c=fr -w secret -s base -b "" objectclass=* + It works fine. * I perform the ldap modifications with this LDIF file: -----------------begin LDAP modifications dn: olcDatabase={-1}frontend,cn=config changetype: modify replace: olcAccess olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * no ne olcAccess: {1}to dn=cn=manager,c=fr by self write by * none olcAccess: {2}to * by self write by users read by anonymous read by * none dn: olcDatabase={0}config,cn=config changetype: modify replace: olcAccess olcAccess: {0}to * by * none -----------------end LDAP modifications ldapmodify -x -D cn=manager,c=fr -w secret -f LDAPmodifications.ldif * I try to bind : ldapsearch.exe -x -D cn=manager,c=fr -w secret -s base -b "" objectclass=* + I get: ldap_bind: Invalid credentials (49) * I stop slapd I get: filter_free: unknown filter type=19008 filter_free: unknown filter type=13304 slapd stopped. filter_free: unknown filter type=13744 filter_free: unknown filter type=1264 filter_free: unknown filter type=13744 filter_free: unknown filter type=1264 and slapd crashes. * I restart slapd * I try to bind : ldapsearch.exe -x -D cn=manager,c=fr -w secret -s base -b "" objectclass=* + It works fine.

1 0

(ITS#5816) back-ldap stops searching if send_search_entry() returns harmless errors (like insufficientAccess)
by ando＠sys-net.it 17 Nov '08

17 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando To trigger: define acls that block one entry, and the search will stop at that entry. A fix is coming... p.

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by ali.pouya＠free.fr 17 Nov '08

17 Nov '08

Hi Howard, Sorry for being back again but I think that a residue of the problem of whole tree scanning persists : The improvement is that it only happens once if the mirrors are not synchronized (the later statups are OK). I uploaded the new archive file ITS_5640_new.tar.gz to the FTP server (incoming directory). To reproduce the problem y can proceed as explained in folowwup 9. Thanks Best Regards Ali

1 0

Re: (ITS#5796) back-sql intermittently failing
by robb＠wtg.cw.com 17 Nov '08

17 Nov '08

Pierangelo Masarati wrote: > OK, this makes sense. In fact, back-sql does not seem to specifically > handle broken connections to the odbc. It appears it would need > something similar to idle-timeout as in back-ldap and back-meta. current work-around is to set "idletimeout" in openldap shorter than mysql's "wait_timeout" (default 8hrs).

1 0

Re: (ITS#5805) Problem when modifying access control
by ando＠sys-net.it 17 Nov '08

17 Nov '08

emmanuel.duru(a)atosorigin.com wrote: > I'm sorry, but I don't. > cn=manager,c=fr was already the rootdn of config database (as well as rootdn > of c=fr database) before doing the test, with no rootpw in the config > database. > My first test consisted in modifying both olcAccess and olcRootDn for all > databases (if present) without changing any value (replacing the existing > values with the same ones). Then I made another test, with olcAccess > modifications only (on both frontend and config databases), and the problem > still appears. It only appears if I modify olcAccess of both databases, and > in this order: frontend then config. Well, I simply followed what you described in your bug report (at least what I understood). Next time, please provide a full featured script that fires up slapd and performs the offending writes. I'll change "cannot reproduce" to "report obscure". 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#5805) Problem when modifying access control
by h.b.furuseth＠usit.uio.no 17 Nov '08

17 Nov '08

Please post your configuration (minus any passwords) so it's possible to test what you are doing. Makes for less guesswork too. -- Hallvard

1 0

RE: (ITS#5805) Problem when modifying access control
by emmanuel.duru＠atosorigin.com 17 Nov '08

17 Nov '08

I'm sorry, but I don't. cn=manager,c=fr was already the rootdn of config database (as well as rootdn of c=fr database) before doing the test, with no rootpw in the config database. My first test consisted in modifying both olcAccess and olcRootDn for all databases (if present) without changing any value (replacing the existing values with the same ones). Then I made another test, with olcAccess modifications only (on both frontend and config databases), and the problem still appears. It only appears if I modify olcAccess of both databases, and in this order: frontend then config. > > You do, since you modify the configuration using the cn=config rootdn in > order to modify itself, and set it to cn=manager,c=fr. So in the first > place you had a rootdn in cn=config, with a rootpw. And the > modification you posted did not remove the rootpw.

1 0

Re: (ITS#5805) Problem when modifying access control
by ando＠sys-net.it 17 Nov '08

17 Nov '08

emmanuel.duru(a)atosorigin.com wrote: >> Emmanuel Duru wrote: >>> I wouldn't say that it is harmless. >> I'm not saying your problem is harmless. I'm saying that having a >> rootdn of cn=config that is not within cn=config but with the rootpw is >> a violation of slapd's configuration rules (when the rootdn is not >> within the naming context, it cannot have a rootpw set). >> > > But I don't. > My rootdn is cn=manager,c=fr which is a real entry in the c=fr database > (bdb) with the password in the entry and no rootpw neither in c=fr nor in > cn=config. You do, since you modify the configuration using the cn=config rootdn in order to modify itself, and set it to cn=manager,c=fr. So in the first place you had a rootdn in cn=config, with a rootpw. And the modification you posted did not remove the rootpw. 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#5805) Problem when modifying access control
by emmanuel.duru＠atosorigin.com 17 Nov '08

17 Nov '08

> Emmanuel Duru wrote: > > I wouldn't say that it is harmless. > > I'm not saying your problem is harmless. I'm saying that having a > rootdn of cn=config that is not within cn=config but with the rootpw is > a violation of slapd's configuration rules (when the rootdn is not > within the naming context, it cannot have a rootpw set). > But I don't. My rootdn is cn=manager,c=fr which is a real entry in the c=fr database (bdb) with the password in the entry and no rootpw neither in c=fr nor in cn=config.

1 0

Re: (ITS#5805) Problem when modifying access control
by ando＠sys-net.it 17 Nov '08

17 Nov '08

Emmanuel Duru wrote: > I wouldn't say that it is harmless. I'm not saying your problem is harmless. I'm saying that having a rootdn of cn=config that is not within cn=config but with the rootpw is a violation of slapd's configuration rules (when the rootdn is not within the naming context, it cannot have a rootpw set). > To sum up, the problem is that when I modify frontend access control and > then config access control (olcAccess attribute in both cases), I can not > bind any more (neither with rootdn nor with any other dn). > Concerning further releases, I will try later. Maybe I will wait for the > 2.4.13... Fine. 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#5805) Problem when modifying access control
by emmanuel.duru＠atosorigin.com 17 Nov '08

17 Nov '08

I wouldn't say that it is harmless. To sum up, the problem is that when I modify frontend access control and then config access control (olcAccess attribute in both cases), I can not bind any more (neither with rootdn nor with any other dn). Concerning further releases, I will try later. Maybe I will wait for the 2.4.13... > -----Message d'origine----- > De : Pierangelo Masarati [mailto:ando@sys-net.it] > Envoyé : dimanche 16 novembre 2008 22:01 > À : emmanuel.duru(a)atosorigin.com > Cc : openldap-its(a)openldap.org > Objet : Re: (ITS#5805) Problem when modifying access control > > emmanuel.duru(a)atosorigin.com wrote: > > Full_Name: Emmanuel Duru > > Version: 2.4.11 > > OS: Windows > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (80.78.0.137) > > > > > > I have a single BDB database directory with root DN as a physical entry. > My > > access control is defined as follows in olcDatabase={-1}frontend: > > olcAccess: {0}to attrs=userPassword by self write by anonymous auth > by * no > > ne > > olcAccess: {1}to dn=cn=manager,c=fr by self write by * none > > olcAccess: {2}to * by self write by users read by anonymous read by > * none > > > > I perform a modify operation as follows: > > dn: olcDatabase={-1}frontend,cn=config > > changetype: modify > > replace: olcAccess > > olcAccess: {0}to attrs=userPassword by self write by anonymous auth > by * no > > ne > > olcAccess: {1}to dn=cn=manager,c=fr by self write by * none > > olcAccess: {2}to * by self write by users read by anonymous read by > * none > > > > dn: olcDatabase={0}config,cn=config > > changetype: modify > > replace: olcAccess > > olcAccess: {0}to * by * none > > - > > replace: olcRootDN > > olcRootDN: cn=manager,c=fr > > > > then I can not bind any more to the directory (invalid credentials). > > The log says (do notice the line dn: [1]... with non printable > characters): > > do_bind: version=3 dn="cn=manager,c=fr" method=128 > > ==> bdb_bind: dn: cn=manager,c=fr > > bdb_dn2entry("cn=manager,c=fr") > > => access_allowed: auth access to "cn=manager,c=fr" "userPassword" > requested > > => dn: [1] <some non printable characters>anager,c=fr > > => acl_get: [2] attr userPassword > > => slap_access_allowed: result not in cache (userPassword) > > => acl_mask: access to entry "cn=manager,c=fr", attr "userPassword" > requested > > => acl_mask: to value by "", (=0) > > <= check a_dn_pat: * > > <= acl_mask: [1] applying none(=0) (stop) > > <= acl_mask: [1] mask: none(=0) > > => slap_access_allowed: auth access denied by none(=0) > > => access_allowed: no more rules > > > > When I stop the directory, the log says (filter_free lines may vary): > > bdb_db_close: database "c=fr": alock_close failed > > filter_free: unknown filter type=20224 > > filter_free: unknown filter type=496 > > slapd stopped. > > filter_free: unknown filter type=29776 > > filter_free: unknown filter type=13944 > > filter_free: unknown filter type=29496 > > > > When I restart slapd, all is fine: the access control is OK and I can > bind. > > I can't confirm your report with HEAD code. I suggest you retry with > either 2.4.12 or (better) re24, which is about to be released as 2.4.13. > I note that by performing the operations you indicate, the cn=config > database (dn: olcDatabase={0}config,cn=config) ends up in an > inconsistent state, because the rootdn does not belong to its naming > context, but the rootpw is set, which should not be allowed. A check > for this does not exist, while it should. In any case, this is harmless. > > 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

Posible bug with alias
by Alberto Gomez 17 Nov '08

17 Nov '08

Hi, I have found a possible bug on OpenLDAP when querying an entry which is an alias. This is the query: ldapsearch -x -h localhost -L -b "msisdn=911,dc=msisdn,ou=aliases,dc=mybasedn" -s subtree -a search # # LDAPv3 # base <msisdn=911,dc=msisdn,ou=aliases,dc=mybasedn> with scope subtre e # filter: (objectclass=*) # requesting: ALL # # 111, realentries, mybasedn dn: subsId=111,ou=realentries,dc=mybasedn objectClass: top objectClass: RealEntry subsId: 111 # 911, msisdn, aliases, mybasedn dn: MSISDN=911,dc=msisdn,ou=aliases,dc=mybasedn objectClass: top objectClass: alias objectClass: MSISDN MSISDN: 911 aliasedObjectName: subsId=111,ou=realentries,dc=mybasedn CDC: 0 usageCnt: 1 # search result # numResponses: 3 # numEntries: 2 What I would expect is the alias entry to be returned (as the derefAlias=search) but instead I get the alias entry and the aliased entry. I am using OpenLDAP 2.3.43-1 on cygwin. Is this a bug? Best regards, Alberto Gómez

1 0

Re: (ITS#5814) concurrent access to connections
by ando＠sys-net.it 16 Nov '08

16 Nov '08

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> Hallvard B Furuseth wrote: >>> test036-meta-concurrency just crashed with fresh HEAD code. >>> I suppose that's the same as this ITS. >> Looks like. However, now I thought my FIXME were little more than a >> precaution. In fact, right now the only places where c_struct_state can >> be modified are protected by a mutex on connections_mutex; this should >> prevent changing the state of a connection during a connection_next() >> call. Do you see a thread waiting on >> ldap_pvt_thread_mutex_lock(&connections_mutex ); at connection.c:427 or >> connection.c:514? If that's the case, we probably need to move >> c->c_conn_state = SLAP_C_INACTIVE; inside the mutex in order to be able >> to safely assert in connection_next(). Is it worth? > > That should not be necessary. c_struct_state is supposed to be protected by > connections_mutex, while c_conn_state is supposed to be protected by > c->c_mutex. As already described in the comments at the top of the file. What seesm to happen is that c_conn_state is changed, then connections_mutex prevents from changing c_struct_state. As a consequence, connection_next() treats a connection structure based on its c_struct_state, which is now correctly protected, but then asserts on its c_conn_state, which has already been modified. So we are asserting on the state of a connection that is being modified, and is by design in a temporarily inconsistent state. Now things should be safe, though. 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#5814) concurrent access to connections
by hyc＠symas.com 16 Nov '08

16 Nov '08

ando(a)sys-net.it wrote: > Hallvard B Furuseth wrote: >> test036-meta-concurrency just crashed with fresh HEAD code. >> I suppose that's the same as this ITS. > > Looks like. However, now I thought my FIXME were little more than a > precaution. In fact, right now the only places where c_struct_state can > be modified are protected by a mutex on connections_mutex; this should > prevent changing the state of a connection during a connection_next() > call. Do you see a thread waiting on > ldap_pvt_thread_mutex_lock(&connections_mutex ); at connection.c:427 or > connection.c:514? If that's the case, we probably need to move > c->c_conn_state = SLAP_C_INACTIVE; inside the mutex in order to be able > to safely assert in connection_next(). Is it worth? That should not be necessary. c_struct_state is supposed to be protected by connections_mutex, while c_conn_state is supposed to be protected by c->c_mutex. As already described in the comments at the top of the file. -- -- 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#5814) concurrent access to connections
by h.b.furuseth＠usit.uio.no 16 Nov '08

16 Nov '08

Pierangelo Masarati writes: > Do you see a thread waiting on > ldap_pvt_thread_mutex_lock( &connections_mutex ); at connection.c:427 or > connection.c:514? Yes, thread 4: (gdb) thread apply all backtrace Thread 10 (process 8228): #0 0x00000038cf6075b5 in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000042afa2 in slapd_daemon () at daemon.c:2656 #2 0x00000000004198c4 in main (argc=8, argv=0x7fff65271058) at main.c:948 Thread 9 (process 8245): #0 0x00000038cead1f58 in epoll_wait () from /lib64/libc.so.6 #1 0x000000000042d2bb in slapd_daemon_task (ptr=<value optimized out>) at daemon.c:2291 #2 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #3 0x00000038cead1b6d in clone () from /lib64/libc.so.6 Thread 8 (process 8260): #0 0x00000038ceab8947 in sched_yield () from /lib64/libc.so.6 #1 0x00002acc4bb99bd0 in meta_back_search (op=0x14f7c4b0, rs=0x42f23ca0) at search.c:1542 #2 0x0000000000432276 in fe_op_search (op=0x14f7c4b0, rs=0x42f23ca0) at search.c:366 #3 0x0000000000432a07 in do_search (op=0x14f7c4b0, rs=0x42f23ca0) at search.c:217 #4 0x0000000000430331 in connection_operation (ctx=0x42f23df0, arg_v=<value optimized out>) at connection.c:1090 #5 0x000000000043077d in connection_read_thread (ctx=0x42f23df0, argv=<value optimized out>) at connection.c:1216 #6 0x00002acc4584a1aa in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:663 #7 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #8 0x00000038cead1b6d in clone () from /lib64/libc.so.6 Thread 7 (process 8261): #0 0x00000038ceac9016 in poll () from /lib64/libc.so.6 #1 0x00002acc4584d142 in ldap_result (ld=0x15815910, msgid=346, all=1, timeout=<value optimized out>, result=0x437249e8) at result.c:355 #2 0x00002acc4bb9afa8 in meta_back_op_result (mc=0x15815810, op=0x1507ca40, rs=0x43724ca0, candidate=1, msgid=346, timeout=0, sendok=LDAP_BACK_SENDRESULT) at bind.c:1004 #3 0x00002acc4bb9e731 in meta_back_modrdn (op=0x1507ca40, rs=0x43724ca0) at modrdn.c:141 #4 0x000000000044874a in fe_op_modrdn (op=0x1507ca40, rs=0x43724ca0) at modrdn.c:314 #5 0x00000000004491b4 in do_modrdn (op=0x1507ca40, rs=0x43724ca0) at modrdn.c:186 #6 0x0000000000430331 in connection_operation (ctx=0x43724df0, arg_v=<value optimized out>) at connection.c:1090 #7 0x000000000043077d in connection_read_thread (ctx=0x43724df0, argv=<value optimized out>) at connection.c:1216 #8 0x00002acc4584a1aa in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:663 #9 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #10 0x00000038cead1b6d in clone () from /lib64/libc.so.6 Thread 6 (process 8391): #0 0x00000038ceac9016 in poll () from /lib64/libc.so.6 #1 0x00002acc4584d142 in ldap_result (ld=0x1519d440, msgid=87, all=2, timeout=<value optimized out>, result=0x41b015f0) at result.c:355 #2 0x00002acc4bb9773c in meta_back_search (op=0x41b01640, rs=0x41b017b0) at search.c:1027 #3 0x00002acc4bba07a3 in meta_back_get_candidate (op=0x151c0b70, rs=0x41b01ca0, ndn=0x41b019a0) at conn.c:891 #4 0x00002acc4bba26fa in meta_back_getconn (op=0x151c0b70, rs=0x41b01ca0, candidate=0x0, sendok=LDAP_BACK_BINDING) at conn.c:1325 #5 0x00002acc4bb9c4cb in meta_back_bind (op=0x151c0b70, rs=0x41b01ca0) at bind.c:96 #6 0x000000000044b52e in fe_op_bind (op=0x151c0b70, rs=0x41b01ca0) at bind.c:383 #7 0x000000000044bf2f in do_bind (op=0x151c0b70, rs=0x41b01ca0) at bind.c:205 #8 0x0000000000430331 in connection_operation (ctx=0x41b01df0, arg_v=<value optimized out>) at connection.c:1090 #9 0x000000000043077d in connection_read_thread (ctx=0x41b01df0, argv=<value optimized out>) at connection.c:1216 #10 0x00002acc4584a1aa in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:663 #11 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #12 0x00000038cead1b6d in clone () from /lib64/libc.so.6 Thread 5 (process 8392): #0 0x00000038cf60c888 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 #1 0x00000038cf6088a5 in _L_mutex_lock_107 () from /lib64/libpthread.so.0 #2 0x00000038cf608333 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00002acc4bdb2b57 in monitor_cache_lock (e=<value optimized out>) at cache.c:117 #4 0x00002acc4bdb1f9f in monitor_send_children (op=0x152cf4f0, rs=0x43f25ca0, e_parent=<value optimized out>, sub=1) at search.c:144 #5 0x00002acc4bdb2017 in monitor_send_children (op=0x152cf4f0, rs=0x43f25ca0, e_parent=<value optimized out>, sub=1) at search.c:123 #6 0x00002acc4bdb23a7 in monitor_back_search (op=0x152cf4f0, rs=0x43f25ca0) at search.c:245 #7 0x0000000000432276 in fe_op_search (op=0x152cf4f0, rs=0x43f25ca0) at search.c:366 #8 0x0000000000432a07 in do_search (op=0x152cf4f0, rs=0x43f25ca0) at search.c:217 #9 0x0000000000430331 in connection_operation (ctx=0x43f25df0, arg_v=<value optimized out>) at connection.c:1090 #10 0x000000000043077d in connection_read_thread (ctx=0x43f25df0, argv=<value optimized out>) at connection.c:1216 #11 0x00002acc4584a1aa in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:663 #12 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #13 0x00000038cead1b6d in clone () from /lib64/libc.so.6 Thread 4 (process 8393): #0 0x00000038cf60c888 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 #1 0x00000038cf6088a5 in _L_mutex_lock_107 () from /lib64/libpthread.so.0 #2 0x00000038cf608333 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x0000000000431775 in connection_init (s=31, listener=0x14e3b280, dnsname=0x4c39b5 "unknown", peername=0x447258a0 "IP=127.0.0.1:50895", flags=0, ssf=0, authid=0x0) at connection.c:514 #4 0x000000000042b40a in slap_listener_thread (ctx=<value optimized out>, ptr=<value optimized out>) at daemon.c:1965 #5 0x00002acc4584a1aa in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:663 #6 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #7 0x00000038cead1b6d in clone () from /lib64/libc.so.6 Thread 3 (process 8395): #0 0x00000038ceac9016 in poll () from /lib64/libc.so.6 #1 0x00002acc4584d142 in ldap_result (ld=0x152cda90, msgid=529, all=2, timeout=<value optimized out>, result=0x44f275f0) at result.c:355 #2 0x00002acc4bb9773c in meta_back_search (op=0x44f27640, rs=0x44f277b0) at search.c:1027 #3 0x00002acc4bba07a3 in meta_back_get_candidate (op=0x154d8a90, rs=0x44f27ca0, ndn=0x44f279a0) at conn.c:891 #4 0x00002acc4bba26fa in meta_back_getconn (op=0x154d8a90, rs=0x44f27ca0, candidate=0x0, sendok=LDAP_BACK_BINDING) at conn.c:1325 #5 0x00002acc4bb9c4cb in meta_back_bind (op=0x154d8a90, rs=0x44f27ca0) at bind.c:96 #6 0x000000000044b52e in fe_op_bind (op=0x154d8a90, rs=0x44f27ca0) at bind.c:383 #7 0x000000000044bf2f in do_bind (op=0x154d8a90, rs=0x44f27ca0) at bind.c:205 #8 0x0000000000430331 in connection_operation (ctx=0x44f27df0, arg_v=<value optimized out>) at connection.c:1090 #9 0x000000000043077d in connection_read_thread (ctx=0x44f27df0, argv=<value optimized out>) at connection.c:1216 #10 0x00002acc4584a1aa in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:663 #11 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #12 0x00000038cead1b6d in clone () from /lib64/libc.so.6 Thread 2 (process 8497): #0 0x00000038cf60a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002acc4584a1f8 in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:654 #2 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #3 0x00000038cead1b6d in clone () from /lib64/libc.so.6 Thread 1 (process 8498): #0 0x00000038cea30155 in raise () from /lib64/libc.so.6 #1 0x00000038cea31bf0 in abort () from /lib64/libc.so.6 #2 0x00000038cea295d6 in __assert_fail () from /lib64/libc.so.6 #3 0x0000000000431122 in connection_next (c=0x2acc4bfcad90, index=0x45f28a7c) at connection.c:877 #4 0x00002acc4bdb774f in monitor_subsys_conn_update (op=<value optimized out>, rs=<value optimized out>, e=0x14f10c88) at conn.c:230 #5 0x00002acc4bdb39cb in monitor_entry_update (op=0x2024, rs=0x45f29ca0, e=0x6) at entry.c:59 #6 0x00002acc4bdb1fd0 in monitor_send_children (op=0x15714210, rs=0x45f29ca0, e_parent=0x14f10c88, sub=1) at search.c:88 #7 0x00002acc4bdb2017 in monitor_send_children (op=0x15714210, rs=0x45f29ca0, e_parent=<value optimized out>, sub=1) at search.c:123 #8 0x00002acc4bdb23a7 in monitor_back_search (op=0x15714210, rs=0x45f29ca0) at search.c:245 #9 0x0000000000432276 in fe_op_search (op=0x15714210, rs=0x45f29ca0) at search.c:366 #10 0x0000000000432a07 in do_search (op=0x15714210, rs=0x45f29ca0) at search.c:217 #11 0x0000000000430331 in connection_operation (ctx=0x45f29df0, arg_v=<value optimized out>) at connection.c:1090 #12 0x000000000043077d in connection_read_thread (ctx=0x45f29df0, argv=<value optimized out>) at connection.c:1216 #13 0x00002acc4584a1aa in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:663 #14 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #15 0x00000038cead1b6d in clone () from /lib64/libc.so.6 (gdb) thread 4 (gdb) frame 3 #3 0x0000000000431775 in connection_init (s=31, listener=0x14e3b280, dnsname=0x4c39b5 "unknown", peername=0x447258a0 "IP=127.0.0.1:50895", flags=0, ssf=0, authid=0x0) at connection.c:514 514 ldap_pvt_thread_mutex_lock( &connections_mutex ); (gdb) p c $4 = (Connection *) 0x2acc4bfcad90 (gdb) p *c $5 = {c_struct_state = 1, c_conn_state = 1, c_conn_idx = 31, c_sd = 31, c_close_reason = 0x4c355a "?", c_mutex = {__data = {__lock = 1, __count = 0, __owner = 8393, __nusers = 1, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = "\001\000\000\000\000\000\000\000É \000\000\001", '\0' <repeats 26 times>, __align = 1}, c_sb = 0x2aaab0009680, c_starttime = 1226874133, c_activitytime = 1226874133, c_connid = 46, c_peer_domain = {bv_len = 7, bv_val = 0x14f72e90 "unknown"}, c_peer_name = {bv_len = 18, bv_val = 0x1581ecc0 "IP=127.0.0.1:50895"}, c_listener = 0x14e3b280, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 128, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x2acc4bfcaea8}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x2acc4bfcaeb8}, c_write_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\0' <repeats 39 times>, __align = 0}, c_write_cv = {__data = {__lock = 0, __futex = 2, __total_seq = 1, __wakeup_seq = 1, __woken_seq = 1, __mutex = 0x2acc4bfcada8, __nwaiters = 0, __broadcast_seq = 0}, __size = "\000\000\000\000\002\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000šüKÌ*\000\000\000\000\000\000\000\000\000", __align = 8589934592}, c_currentber = 0x0, c_sasl_bind_in_progress = 0 '\0', c_writewaiter = 0 '\0', c_is_tls = 0 '\0', c_needs_tls_accept = 0 '\0', c_sasl_layers = 0 '\0', c_sasl_done = 0 '\0', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_txn = 0, c_txn_backend = 0x0, c_txn_ops = {stqh_first = 0x0, stqh_last = 0x2acc4bfcaf60}, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x441cb0 <slap_send_ldap_result>, c_send_search_entry = 0x43f700 <slap_send_search_entry>, c_send_search_reference = 0x43f050 <slap_send_search_reference>, c_send_ldap_extended = 0x441810 <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x4416c0 <slap_send_ldap_intermediate>} -- Hallvard

1 0

Re: (ITS#5814) concurrent access to connections
by ando＠sys-net.it 16 Nov '08

16 Nov '08

Hallvard B Furuseth wrote: > test036-meta-concurrency just crashed with fresh HEAD code. > I suppose that's the same as this ITS. Looks like. However, now I thought my FIXME were little more than a precaution. In fact, right now the only places where c_struct_state can be modified are protected by a mutex on connections_mutex; this should prevent changing the state of a connection during a connection_next() call. Do you see a thread waiting on ldap_pvt_thread_mutex_lock( &connections_mutex ); at connection.c:427 or connection.c:514? If that's the case, we probably need to move c->c_conn_state = SLAP_C_INACTIVE; inside the mutex in order to be able to safely assert in connection_next(). Is it worth? 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#5814) concurrent access to connections
by h.b.furuseth＠usit.uio.no 16 Nov '08

16 Nov '08

test036-meta-concurrency just crashed with fresh HEAD code. I suppose that's the same as this ITS. #3 0x0000000000431122 in connection_next (c=0x2acc4bfcad90, index=0x45f28a7c) at connection.c:877 877 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); (gdb) bt #0 0x00000038cea30155 in raise () from /lib64/libc.so.6 #1 0x00000038cea31bf0 in abort () from /lib64/libc.so.6 #2 0x00000038cea295d6 in __assert_fail () from /lib64/libc.so.6 #3 0x0000000000431122 in connection_next (c=0x2acc4bfcad90, index=0x45f28a7c) at connection.c:877 #4 0x00002acc4bdb774f in monitor_subsys_conn_update (op=<value optimized out>, rs=<value optimized out>, e=0x14f10c88) at conn.c:230 #5 0x00002acc4bdb39cb in monitor_entry_update (op=0x2024, rs=0x45f29ca0, e=0x6) at entry.c:59 #6 0x00002acc4bdb1fd0 in monitor_send_children (op=0x15714210, rs=0x45f29ca0, e_parent=0x14f10c88, sub=1) at search.c:88 #7 0x00002acc4bdb2017 in monitor_send_children (op=0x15714210, rs=0x45f29ca0, e_parent=<value optimized out>, sub=1) at search.c:123 #8 0x00002acc4bdb23a7 in monitor_back_search (op=0x15714210, rs=0x45f29ca0) at search.c:245 #9 0x0000000000432276 in fe_op_search (op=0x15714210, rs=0x45f29ca0) at search.c:366 #10 0x0000000000432a07 in do_search (op=0x15714210, rs=0x45f29ca0) at search.c:217 #11 0x0000000000430331 in connection_operation (ctx=0x45f29df0, arg_v=<value optimized out>) at connection.c:1090 #12 0x000000000043077d in connection_read_thread (ctx=0x45f29df0, argv=<value optimized out>) at connection.c:1216 #13 0x00002acc4584a1aa in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:663 #14 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #15 0x00000038cead1b6d in clone () from /lib64/libc.so.6 (gdb) p *index $2 = 31 (gdb) p connections[*index] $3 = {c_struct_state = 1, c_conn_state = 1, c_conn_idx = 31, c_sd = 31, c_close_reason = 0x4c355a "?", c_mutex = {__data = {__lock = 1, __count = 0, __owner = 8393, __nusers = 1, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = "\001\000\000\000\000\000\000\000É \000\000\001", '\0' <repeats 26 times>, __align = 1}, c_sb = 0x2aaab0009680, c_starttime = 1226874133, c_activitytime = 1226874133, c_connid = 46, c_peer_domain = {bv_len = 7, bv_val = 0x14f72e90 "unknown"}, c_peer_name = {bv_len = 18, bv_val = 0x1581ecc0 "IP=127.0.0.1:50895"}, c_listener = 0x14e3b280, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 128, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x2acc4bfcaea8}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x2acc4bfcaeb8}, c_write_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\0' <repeats 39 times>, __align = 0}, c_write_cv = {__data = {__lock = 0, __futex = 2, __total_seq = 1, __wakeup_seq = 1, __woken_seq = 1, __mutex = 0x2acc4bfcada8, __nwaiters = 0, __broadcast_seq = 0}, __size = "\000\000\000\000\002\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000šüKÌ*\000\000\000\000\000\000\000\000\000", __align = 8589934592}, c_currentber = 0x0, c_sasl_bind_in_progress = 0 '\0', c_writewaiter = 0 '\0', c_is_tls = 0 '\0', c_needs_tls_accept = 0 '\0', c_sasl_layers = 0 '\0', c_sasl_done = 0 '\0', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_txn = 0, c_txn_backend = 0x0, c_txn_ops = {stqh_first = 0x0, stqh_last = 0x2acc4bfcaf60}, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x441cb0 <slap_send_ldap_result>, c_send_search_entry = 0x43f700 <slap_send_search_entry>, c_send_search_reference = 0x43f050 <slap_send_search_reference>, c_send_ldap_extended = 0x441810 <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x4416c0 <slap_send_ldap_intermediate>} -- Hallvard

1 0

(ITS#5815) typo in os-ip.c (MAXHOSTNAMELEN)
by h.b.furuseth＠usit.uio.no 16 Nov '08

16 Nov '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard #elif defined( MAXHOSTNAMELEN should be #elif defined( MAXHOSTNAMELEN ) Reported in Debian bug 505421. Fixing.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs