openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#7529) mdb.c missing #if MDB_DEBUG at line 3514
by mark＠ibiblio.org 19 Feb '13

19 Feb '13

Thanks for the follow up Howard. I'm busy cranking out a number of dependent packages to compile some software, OpenLDAP being one of many. We have an aversion to the use of GCC here so situations like this compilation fail are somewhat common. It's nice though when code is kept simple and portable as it makes life easier. I don't normally spend much time debugging code and shipping fixes in a nice box with a pretty bow on it, I've just cut and pasted the two lines I used to allow compilation, part of the compile recipe used to crank out this 2.4.33 release. Hopefully that's enough to update your git archives. ta, Mark. On Wed, Feb 20, 2013 at 3:20 PM, Howard Chu <hyc(a)symas.com> wrote: > mark(a)ibiblio.org wrote: >> >> Full_Name: Mark >> Version: 2.4.33 >> OS: Solaris 10 & 11 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (203.63.89.15) >> >> >> The stock 2.4.33 fails to compile mdb with this error: >> >> cc -I/usr/local/include -L/usr/local/lib -I../../../include >> -I../../../include >> -I.. -I./.. -I./../../../libraries/libmdb -I/usr/local/include >> -L/usr/local/lib >> -c ./../../../libraries/libmdb/mdb.c -o mdb.o >> "./../../../libraries/libmdb/mdb.c", line 3514: undefined symbol: top >> "./../../../libraries/libmdb/mdb.c", line 3514: left operand of "->" must >> be >> pointer to struct/union >> cc: acomp failed for ./../../../libraries/libmdb/mdb.c >> >> The problem is top is defined inside #if MDB_DEBUG but used without the >> same #if >> qualifier. > > > Normally the DPRINTF macro would just expand to ((void) 0) if MDB_DEBUG is > not defined, so no, top is not being used without MDB_DEBUG. But looking > closer, I see this requires a C preprocessor that supports vararg macros. > Don't you have a C99-compatible toolchain on Solaris? > >> The fix is: >> /bin/perl -pe '($. == 3514) && s%^%#if MDB_DEBUG\n%' -i >> libraries/libmdb/mdb.c >> /bin/perl -pe '($. == 3517) && s%^%#endif\n%' -i >> libraries/libmdb/mdb.c > > > In the future, please use unified diff format. Preferably just use "git > format-patch" like it says on > http://www.openldap.org/devel/contributing.html > > We don't make changes in already released code, and line numbers alone are a > poor reference in development code. > > -- > -- 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#7529) mdb.c missing #if MDB_DEBUG at line 3514
by hyc＠symas.com 19 Feb '13

19 Feb '13

mark(a)ibiblio.org wrote: > Full_Name: Mark > Version: 2.4.33 > OS: Solaris 10 & 11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.63.89.15) > > > The stock 2.4.33 fails to compile mdb with this error: Fixed in git rev 0108327c274a4b260b5b355d2a7c3ffc3a85f4c1 2012-10-25, closing this ITS. > > cc -I/usr/local/include -L/usr/local/lib -I../../../include -I../../../include > -I.. -I./.. -I./../../../libraries/libmdb -I/usr/local/include -L/usr/local/lib > -c ./../../../libraries/libmdb/mdb.c -o mdb.o > "./../../../libraries/libmdb/mdb.c", line 3514: undefined symbol: top > "./../../../libraries/libmdb/mdb.c", line 3514: left operand of "->" must be > pointer to struct/union > cc: acomp failed for ./../../../libraries/libmdb/mdb.c > > The problem is top is defined inside #if MDB_DEBUG but used without the same #if > qualifier. > > The fix is: > /bin/perl -pe '($. == 3514) && s%^%#if MDB_DEBUG\n%' -i > libraries/libmdb/mdb.c > /bin/perl -pe '($. == 3517) && s%^%#endif\n%' -i libraries/libmdb/mdb.c > > -- -- 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#7529) mdb.c missing #if MDB_DEBUG at line 3514
by hyc＠symas.com 19 Feb '13

19 Feb '13

mark(a)ibiblio.org wrote: > Full_Name: Mark > Version: 2.4.33 > OS: Solaris 10 & 11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.63.89.15) > > > The stock 2.4.33 fails to compile mdb with this error: > > cc -I/usr/local/include -L/usr/local/lib -I../../../include -I../../../include > -I.. -I./.. -I./../../../libraries/libmdb -I/usr/local/include -L/usr/local/lib > -c ./../../../libraries/libmdb/mdb.c -o mdb.o > "./../../../libraries/libmdb/mdb.c", line 3514: undefined symbol: top > "./../../../libraries/libmdb/mdb.c", line 3514: left operand of "->" must be > pointer to struct/union > cc: acomp failed for ./../../../libraries/libmdb/mdb.c > > The problem is top is defined inside #if MDB_DEBUG but used without the same #if > qualifier. Normally the DPRINTF macro would just expand to ((void) 0) if MDB_DEBUG is not defined, so no, top is not being used without MDB_DEBUG. But looking closer, I see this requires a C preprocessor that supports vararg macros. Don't you have a C99-compatible toolchain on Solaris? > The fix is: > /bin/perl -pe '($. == 3514) && s%^%#if MDB_DEBUG\n%' -i > libraries/libmdb/mdb.c > /bin/perl -pe '($. == 3517) && s%^%#endif\n%' -i libraries/libmdb/mdb.c In the future, please use unified diff format. Preferably just use "git format-patch" like it says on http://www.openldap.org/devel/contributing.html We don't make changes in already released code, and line numbers alone are a poor reference in development code. -- -- 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#7529) mdb.c missing #if MDB_DEBUG at line 3514
by mark＠ibiblio.org 19 Feb '13

19 Feb '13

Full_Name: Mark Version: 2.4.33 OS: Solaris 10 & 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.63.89.15) The stock 2.4.33 fails to compile mdb with this error: cc -I/usr/local/include -L/usr/local/lib -I../../../include -I../../../include -I.. -I./.. -I./../../../libraries/libmdb -I/usr/local/include -L/usr/local/lib -c ./../../../libraries/libmdb/mdb.c -o mdb.o "./../../../libraries/libmdb/mdb.c", line 3514: undefined symbol: top "./../../../libraries/libmdb/mdb.c", line 3514: left operand of "->" must be pointer to struct/union cc: acomp failed for ./../../../libraries/libmdb/mdb.c The problem is top is defined inside #if MDB_DEBUG but used without the same #if qualifier. The fix is: /bin/perl -pe '($. == 3514) && s%^%#if MDB_DEBUG\n%' -i libraries/libmdb/mdb.c /bin/perl -pe '($. == 3517) && s%^%#endif\n%' -i libraries/libmdb/mdb.c

1 0

Re: (ITS#7515) Nested liblmdb transaction bugs
by h.b.furuseth＠usit.uio.no 19 Feb '13

19 Feb '13

mdb_txn_commit(nested transaction) has more problems: - If the commit fails, it may modify the parent txn anyway. - The code to merge dirty_list into the parent is strange. I think it assumes that the dirty pages are either dirty in the parent, or have a higher page numbers than the parent's dirty pages parent. That can be wrong if a new freelist entry was used, or a "multi-page page". Branch mdb/tweaks2 in <http://folk.uio.no/hbf/OpenLDAP/openldap.git> includes a suggested fix, but could use some review - and testing by someone who actually uses nested txns. -- Hallvard

1 0

Re: (ITS#7525) Bad conversion to cn=config format - another issue
by francesco.policastro＠selex-es.com 18 Feb '13

18 Feb '13

--=_mixed 0029F46EC1257B17_= Content-Type: multipart/alternative; boundary="=_alternative 0029F470C1257B17_=" --=_alternative 0029F470C1257B17_= Content-Type: text/plain; charset="US-ASCII" Hi, I am going on with my configuration and I realized that the subtree-include directives I use in my meta backend are not converted at all to cn=config. I cannot find them in cn=config tree. I don't know if you decide to open a new ITS or not. My slapd.conf is attached below. The slapd version is 2.4.33 as patched after ITS#7525 (openldap-648d28f.tar.gz) Did anyone use subtrees with cn=config? Francesco Policastro --=_alternative 0029F470C1257B17_= Content-Type: text/html; charset="US-ASCII" Hi, I am going on with my configuration and I realized that the subtree-include directives I use in my meta backend are not converted at all to cn=config. I cannot find them in cn=config tree. I don't know if you decide to open a new ITS or not. My slapd.conf is attached below. The slapd version is 2.4.33 as patched after ITS#7525 ( <form action=http://www.openldap.org/its/index.cgi/Software%20Bugs method=post>openldap-648d28f.tar.gz</form>)   Did anyone use subtrees with cn=config? Francesco Policastro --=_alternative 0029F470C1257B17_=-- --=_mixed 0029F46EC1257B17_= Content-Type: application/octet-stream; name="slapd.conf" Content-Disposition: attachment; filename="slapd.conf" Content-Transfer-Encoding: base64 IwojIFNlZSBzbGFwZC5jb25mKDUpIGZvciBkZXRhaWxzIG9uIGNvbmZpZ3VyYXRpb24gb3B0aW9u cy4KIyBUaGlzIGZpbGUgc2hvdWxkIE5PVCBiZSB3b3JsZCByZWFkYWJsZS4KIwppbmNsdWRlCQkv dXNyL2xvY2FsL2V0Yy9vcGVubGRhcC9zY2hlbWEvY29yZS5zY2hlbWEKaW5jbHVkZQkJL3Vzci9s b2NhbC9ldGMvb3BlbmxkYXAvc2NoZW1hL2Nvc2luZS5zY2hlbWEKaW5jbHVkZQkJL3Vzci9sb2Nh bC9ldGMvb3BlbmxkYXAvc2NoZW1hL2luZXRvcmdwZXJzb24uc2NoZW1hCmluY2x1ZGUJCS91c3Iv bG9jYWwvZXRjL29wZW5sZGFwL3NjaGVtYS9keW5ncm91cC5zY2hlbWEKCmF0dHJpYnV0ZXR5cGUg KCAxLjIuODQwLjExMzU1Ni4xLjQuMjIxIE5BTUUgJ3NBTUFjY291bnROYW1lJyAKCUVRVUFMSVRZ IGNhc2VFeGFjdE1hdGNoIAoJU1lOVEFYICcxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4xNScg U0lOR0xFLVZBTFVFICkKCmF0dHJpYnV0ZXR5cGUgKCAxLjIuODQwLjExMzU1Ni4xLjQuMzUgTkFN RSAnZW1wbG95ZWVJRCcgCglFUVVBTElUWSBjYXNlRXhhY3RNYXRjaCAKCVNZTlRBWCAnMS4zLjYu MS40LjEuMTQ2Ni4xMTUuMTIxLjEuMTUnIFNJTkdMRS1WQUxVRSApCgphdHRyaWJ1dGV0eXBlICgg MS4yLjg0MC4xMTM1NTYuMS40LjggTkFNRSAndXNlckFjY291bnRDb250cm9sJyAKCUVRVUFMSVRZ IGludGVnZXJNYXRjaCAKCVNZTlRBWCAnMS4zLjYuMS40LjEuMTQ2Ni4xMTUuMTIxLjEuMjcnIFNJ TkdMRS1WQUxVRSApCgphdHRyaWJ1dGV0eXBlICggMS4yLjg0MC4xMTM1NTYuMS40LjY1NiBOQU1F ICd1c2VyUHJpbmNpcGFsTmFtZScKCUVRVUFMSVRZIGNhc2VFeGFjdE1hdGNoIAoJU1lOVEFYICcx LjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4xNScgU0lOR0xFLVZBTFVFICkKCgojIEFsbG93IExE QVB2MiBjbGllbnQgY29ubmVjdGlvbnMuICBUaGlzIGlzIE5PVCB0aGUgZGVmYXVsdC4KYWxsb3cg YmluZF92MgoKcGlkZmlsZQkJL3Zhci9ydW4vc2xhcGQucGlkCgojIC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0KYmFja2VuZAkJbWV0YQpiYWNrZW5kCQloZGIKIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t CgojIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KZGF0YWJhc2UJbWV0YQojIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0Kc3VmZml4CQkiZGM9bmV3Y28sZGM9Y29tIgpyZWFkb25seQlvbgpyb290ZG4JCSJj bj1MZGFwQmluZFVzZXIsZGM9bmV3Y28sZGM9Y29tIgpyb290cHcJCXNlY3JldDEKCiMgbm8gYW5v bnltb3VzIGJpbmQKcmVxdWlyZSBhdXRoYwpjb25uLXR0bCAyNW0KCmRuY2FjaGUtdHRsIGRpc2Fi bGVkCgphY2Nlc3MgdG8gKgogYnkgKiBub25lCgojIGZpcnN0IGRvbWFpbgoKdXJpICJsZGFwOi8v c2VydmVyMS5pdC5kb21haW4xLmNvbS9kYz1maXJzdCxkYz1uZXdjbyxkYz1jb20iCmlkYXNzZXJ0 LWJpbmQgYmluZG1ldGhvZD1zaW1wbGUgYmluZGRuPSJjbj1MREFQIFVzZXIsb3U9SVRTdGFmZixk Yz1pdCxkYz1kb21haW4xLGRjPWNvbSIgY3JlZGVudGlhbHM9c2VjcmV0MgpjaGFzZS1yZWZlcnJh bHMgbm8KcmViaW5kLWFzLXVzZXIgdHJ1ZQptYXAgb2JqZWN0Y2xhc3MgZ3JvdXBPZk5hbWVzICoK bWFwIG9iamVjdGNsYXNzIHBlcnNvbiAqCnN1ZmZpeG1hc3NhZ2UgImRjPWZpcnN0LGRjPW5ld2Nv LGRjPWNvbSIgImRjPWl0LGRjPWRvbWFpbjEsZGM9Y29tIgpzdWJ0cmVlLWluY2x1ZGUgIm91PUFw cGxpY2F0aW9ucyxvdT1Hcm91cHMgU2hhcmVkLGRjPWZpcnN0LGRjPW5ld2NvLGRjPWNvbSIKc3Vi dHJlZS1pbmNsdWRlICJvdT1Vc2VycyxvdT0xc3QtbG9jYXRpb24sZGM9Zmlyc3QsZGM9bmV3Y28s ZGM9Y29tIgpzdWJ0cmVlLWluY2x1ZGUgIm91PVVzZXJzLG91PTJuZC1sb2NhdGlvbixkYz1maXJz dCxkYz1uZXdjbyxkYz1jb20iCnN1YnRyZWUtaW5jbHVkZSAib3U9VXNlcnMsb3U9M3JkLWxvY2F0 aW9uLGRjPWZpcnN0LGRjPW5ld2NvLGRjPWNvbSIKCiMgbWFwIHZpc2libGUgYXR0cmlidXRlcyB0 byBtYXRjaGluZyBhdHRyaWJ1dGVzIG9uIGJhY2tlbmQKbWFwIGF0dHJpYnV0ZSBkaXN0aW5ndWlz aGVkTmFtZSAqCm1hcCBhdHRyaWJ1dGUgZ2l2ZW5OYW1lICoKbWFwIGF0dHJpYnV0ZSBkZXNjcmlw dGlvbiAqCm1hcCBhdHRyaWJ1dGUgc24gKgptYXAgYXR0cmlidXRlIGNuICoKbWFwIGF0dHJpYnV0 ZSBtYWlsICoKbWFwIGF0dHJpYnV0ZSBzYW1BY2NvdW50TmFtZSAqCm1hcCBhdHRyaWJ1dGUgdXNl ckFjY291bnRDb250cm9sICoKbWFwIGF0dHJpYnV0ZSBlbXBsb3llZUlEICoKbWFwIGF0dHJpYnV0 ZSB1c2VyUHJpbmNpcGFsTmFtZSAqCgojIG1hcCBldmVyeXRoaW5nIGVsc2UgdG8gbnVsbAptYXAg YXR0cmlidXRlICoKCiMgc2Vjb25kIGRvbWFpbgoKdXJpICJsZGFwOi8vc2VydmVyMi5kb21haW4y Lm5ldC9vdT1vcmdhbml6YXRpb25hbFVuaXQsZGM9c2Vjb25kLGRjPW5ld2NvLGRjPWNvbSIKaWRh c3NlcnQtYmluZCBiaW5kbWV0aG9kPXNpbXBsZSBiaW5kZG49ImNuPWxkYXAtMixjbj1Vc2Vycyxk Yz1kb21haW4yLGRjPW5ldCIgY3JlZGVudGlhbHM9c2VjcmV0MwpjaGFzZS1yZWZlcnJhbHMgbm8K cmViaW5kLWFzLXVzZXIgdHJ1ZQptYXAgb2JqZWN0Y2xhc3MgZ3JvdXBPZk5hbWVzICoKbWFwIG9i amVjdGNsYXNzIHBlcnNvbiAqCnN1ZmZpeG1hc3NhZ2UgImRjPXNlY29uZCxkYz1uZXdjbyxkYz1j b20iICJkYz1kb21haW4yLGRjPW5ldCIKc3VidHJlZS1pbmNsdWRlICJvdT1Vc2VycyxvdT0xc3Qt bG9jYXRpb24sb3U9b3JnYW5pemF0aW9uYWxVbml0LGRjPXNlY29uZCxkYz1uZXdjbyxkYz1jb20i CnN1YnRyZWUtaW5jbHVkZSAib3U9TXktb3Usb3U9MXN0LWxvY2F0aW9uLG91PW9yZ2FuaXphdGlv bmFsVW5pdCxkYz1zZWNvbmQsZGM9bmV3Y28sZGM9Y29tIgpzdWJ0cmVlLWluY2x1ZGUgIm91PVJl bW90ZSBTaXRlcyxvdT1vcmdhbml6YXRpb25hbFVuaXQsZGM9c2Vjb25kLGRjPW5ld2NvLGRjPWNv bSIKCiMgbWFwIHZpc2libGUgYXR0cmlidXRlcyB0byBtYXRjaGluZyBhdHRyaWJ1dGVzIG9uIGJh Y2tlbmQKbWFwIGF0dHJpYnV0ZSBkaXN0aW5ndWlzaGVkTmFtZSAqCm1hcCBhdHRyaWJ1dGUgZ2l2 ZW5OYW1lICoKbWFwIGF0dHJpYnV0ZSBkZXNjcmlwdGlvbiAqCm1hcCBhdHRyaWJ1dGUgc24gKgpt YXAgYXR0cmlidXRlIGNuICoKbWFwIGF0dHJpYnV0ZSBtYWlsICoKbWFwIGF0dHJpYnV0ZSBzYW1B Y2NvdW50TmFtZSAqCm1hcCBhdHRyaWJ1dGUgdXNlckFjY291bnRDb250cm9sICoKbWFwIGF0dHJp YnV0ZSBlbXBsb3llZUlEIHBhZ2VyCm1hcCBhdHRyaWJ1dGUgdXNlclByaW5jaXBhbE5hbWUgKgoK IyBtYXAgZXZlcnl0aGluZyBlbHNlIHRvIG51bGwKbWFwIGF0dHJpYnV0ZSAqCgojIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KZGF0YWJhc2UJaGRiCiMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpzdWZm aXgJCWRjPWRvbWFpbi1ncm91cHMsZGM9Y29tIgpyb290ZG4JCSJjbj1ncm91cHNSb290LGRjPWRv bWFpbi1ncm91cHMsZGM9Y29tIgpyb290cHcJCXNlY3JldDQKb3ZlcmxheQkJZHlubGlzdAoKZHlu bGlzdC1hdHRyc2V0IGdyb3VwT2ZVUkxzIG1lbWJlclVSTCBtZW1iZXIKZGlyZWN0b3J5CS91c3Iv bG9jYWwvdmFyL29wZW5sZGFwLWRhdGEKCg== --=_mixed 0029F46EC1257B17_=--

1 0

Re: (ITS#7515) Nested liblmdb transaction bugs
by h.b.furuseth＠usit.uio.no 18 Feb '13

18 Feb '13

I wrote: >> Can't use a DBI from an aborted child txn, unlike aborted main txn: > (...) > Well, closing the DBI in mdb_txn_abort() caused problems. A fix > in the opposite direction is easy, if we want DBIs to work that > way: mdb_env_open() can open the DBI in any parent txns too. To get more consistent behavior, if that wasn't clear: Any parent txn will receive the DBI independently of commit/abort, just like the MDB_env. Future children of a preexisting txn still differ, which is probably for the best. Changing that would take locking. -- Hallvard

1 0

Re: (ITS#7515) Nested liblmdb transaction bugs
by h.b.furuseth＠usit.uio.no 18 Feb '13

18 Feb '13

I wrote: > Fixed in mdb.master, except: > >> Can't use a DBI from an aborted child txn, unlike aborted main txn: Yet it may be possible to use the DBI in the parent txn if mdb_dbi_open() reused a closed DBI - but it may have the wrong flags and cmp functions, or also wrong MDB_db if the close happened after txn_begin. > Fixing this caused problems and got reverted. > The DBI is available to next non-nested txn Well, closing the DBI in mdb_txn_abort() caused problems. A fix in the opposite direction is easy, if we want DBIs to work that way: mdb_env_open() can open the DBI in any parent txns too. ldbm.h: "[The database handle] denotes the name and parameters of a database, independently of whether such a database exists. It will not exist if the transaction which created it aborted, nor if another process deleted it. Preexisting transactions, other than the current transaction and any parents, must not use the new handle. Nor must their children." -- Hallvard

1 0

Re: (ITS#7525) Bad conversion to cn=config format - solved
by francesco.policastro＠selex-es.com 18 Feb '13

18 Feb '13

--=_alternative 0039EFE9C1257B16_= Content-Type: text/plain; charset="US-ASCII" My suggestion is to modify the test suite to include an uri containing spaces, just to avoid regressions. Ciao, Francesco Policastro --=_alternative 0039EFE9C1257B16_= Content-Type: text/html; charset="US-ASCII" My suggestion is to modify the test suite to include an uri containing spaces, just to avoid regressions. Ciao, Francesco Policastro --=_alternative 0039EFE9C1257B16_=--

1 0

Re: (ITS#7517) mdb_dbi_close(dbi updated in existing txn) breaks
by h.b.furuseth＠usit.uio.no 17 Feb '13

17 Feb '13

Related: If a DB is dropped (and thus the DBI closed) in a txn which has modified it, mdb_txn_commit attempted to save the DB. This could corrupt another DB if mdb_dbi_open() in another thread had reused the DBI. This is now fixed in mdb.master. -- Hallvard

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