openldap-bugs

openldap-bugs@openldap.org

1 participants
20962 discussions

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by michael＠stroeder.com 09 Apr '12

09 Apr '12

This is a cryptographically signed message in MIME format. --------------ms000408080902010107050201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable masarati(a)aero.polimi.it wrote: > In general, I also prefer to have NO matching rules associated to attrs= > designed for purposes that do not require matching Why? As said it's useful for collision detection in case of a modify. So at le= ast every multi-valued attribute should have an EQUALITY matching rule. If in doubt which matching rule to use one could choose the stricter one = as default, e.g. prefer caseExact over caseIgnore. Ciao, Michael. --------------ms000408080902010107050201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQwOTE0MDMzN1owIwYJKoZIhvcNAQkEMRYE FA/Qy+ARPwJkPevCeC+L6wyIRj0kMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAGTlcNhwACV1MtWV3357kkJD4g8XzJiMqBalX91sbDNJB1nMxa0T7bL/9EjphF2x848kZ cigt+EvFku6zt2zYTfhtmO4BS2kapufb5FeWfZ0YhBUFHJapvs91bLo07zkeW22Q2JxEbMhc YFAiulZZz8IunikRpC8HT5tFfj/lbdskKllS7Y7p/4lBjyOf/a98+wKLPLt4AhDG6oIDufSr slldCFo6EQ5Gtj6CoF821/No4zIQRWVjjtx1Xzdy6ie395ebvejF1WuX+vIkbTbSPwR4HAF7 zgrUr5tXwI9W1N/nrYQ1eRLuZ3r4Aot/5CxqJ5UtZntIfXx+RWXZ2TE4hQAAAAAAAA== --------------ms000408080902010107050201--

1 0

Re: (ITS#7224) Core dump while trying to run slapd
by masarati＠aero.polimi.it 09 Apr '12

09 Apr '12

> On 4/6/2012 10:22 AM, Howard Chu wrote: >> >> Find out why oc->oc_names is NULL. It should not be. Seems like you >> have an invalid schema definition. >> > I have fixed the objectClasses that were violating by adding > "extensibleObject". ObjectClass with OID '1.3.6.1.4.1.6152.10.3.2.16'. Can you provide its definition? Apparently, oc_names is NULL, i.e. no names are defined for that class. > Also, the slapadd-ing should not "core", and give the right error message. Allowing us to reproduce and fix the issue would help us prevent issues like this. p.

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by masarati＠aero.polimi.it 09 Apr '12

09 Apr '12

> quanah(a)zimbra.com wrote: >> --On Thursday, April 05, 2012 7:38 PM +0000 h.b.furuseth(a)usit.uio.no >> wrote: >> >>> On Thu, 5 Apr 2012 13:12:31 GMT, michael(a)stroeder.com wrote: >>>> hyc(a)symas.com wrote: >>>>> michael(a)stroeder.com wrote: >>>>>> 2. add an equality matching rule. >>>>> >>>>> My approach with config attrs has been to skip the equality rule for >>>>> single-valued attrs. Since they are single-valued, there's obviously >>>>> no need >>>>> to allow for comparing multiple values. >>> >>> Users always find more ways to use a feature than its creator >>> imagined. >>> >>> I wish people would give attributes all matching rules they can. >>> Equality, ordering, substring. Except when: >>> - flexibility would be a misfeature, e.g. SUBSTR for userPassword, >>> - or it's unclear which rules to choose, e.g. caseIgnore vs >>> caseExact. >> >> I agree. I think defining matching rules where possible is extremely >> useful. > > Patch welcome. This is a pretty trivial patch to write, but I have more > urgent > things to attend to. In general, I also prefer to have NO matching rules associated to attrs designed for purposes that do not require matching (this is often the case of configuration-specific attributes mostly if not only intended for internal use). Whenever one needs to search them, extensible filtering is your friend. p.

1 0

Re: (ITS#7238) Multiple txns in same thread break mdb
by h.b.furuseth＠usit.uio.no 09 Apr '12

09 Apr '12

I wrote: > Related doc bug: > > I expect it should be "only one thread at a time". I doubt > it's about pinning some operation to a particular thread:-) Argh, something ate the part which says what I'm talking about: mdb_open() and mdb_close(), and partly mdb_drop() Hallvard

1 0

Re: (ITS#7238) Multiple txns in same thread break mdb
by hyc＠symas.com 09 Apr '12

09 Apr '12

h.b.furuseth(a)usit.uio.no wrote: > Related doc bug: > > I expect it should be "only one thread at a time". I doubt > it's about pinning some operation to a particular thread:-) Wrong. For write txns I suppose that could be relaxed. For readers, the reader slot is set when the txn is created, and that slot is owned by a particular thread. > However, maybe it should rather be something like "No other > transaction doing mdb_open() may exist at the same time, nor > a write transaction (since that also updates the databases), > nor may such a transaction exist during mdb_close()" ? > > I note mdb_drop() also updates the databases and can > likely not coexist with the others, but that's covered by > mentioning write txns. > > Regarding mdb_drop(), while I'm at it: > @brief Delete a database and/or free all its pages. > @param[in] del non-zero to delete the DB from > the environment, otherwise just free its pages. > Free which pages? In the DB, or some malloced ones? This is single-level-store, there is no distinction. In the DB or in memory, all the same. -- -- 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#7237) Crash abandoning freed/unused operation
by h.b.furuseth＠usit.uio.no 09 Apr '12

09 Apr '12

On Sun, 8 Apr 2012 00:49:28 GMT, h.b.furuseth(a)usit.uio.no wrote: > './run -b ldif test045-syncreplication-proxied' crashed > in connection_abandon() with LDAP_MEMORY_DEBUG: > It dereferenced o_hdr which is NULL in the uninitialized or > freed op 'o'. (op 'o' is full of 0xFF bytes, which I > assume is the poiosin from liblber/memory.c.) Reproduced with bdb. It's a freed op sitting in the c->c_ops list when entering connection_abandon(). (Checked my modifying the "poison" in liblber and inspecting the list before the be_abandon loop.) Not reproduced under valgrind so far. -- Hallvard

1 0

Re: (ITS#7238) Multiple txns in same thread break mdb
by h.b.furuseth＠usit.uio.no 09 Apr '12

09 Apr '12

Related doc bug: I expect it should be "only one thread at a time". I doubt it's about pinning some operation to a particular thread:-) However, maybe it should rather be something like "No other transaction doing mdb_open() may exist at the same time, nor a write transaction (since that also updates the databases), nor may such a transaction exist during mdb_close()" ? I note mdb_drop() also updates the databases and can likely not coexist with the others, but that's covered by mentioning write txns. Regarding mdb_drop(), while I'm at it: @brief Delete a database and/or free all its pages. @param[in] del non-zero to delete the DB from the environment, otherwise just free its pages. Free which pages? In the DB, or some malloced ones? I expect it should be "delete a database or empty its contents", and "del non-zero ... otherwise just empty the database." -- Hallvard

1 0

Re: (ITS#7238) Multiple txns in same thread break mdb
by hyc＠symas.com 09 Apr '12

09 Apr '12

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: > OS: > URL: > Submission from: (NULL) (195.1.106.125) > Submitted by: hallvard > > > mdb.h says a transaction must only be used by a single thread, > but libmdb also assumes a thread only has one transaction: Yes, this is a design requirement. Doc should be updated if it doesn't already state this explicitly. -- -- 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#7238) Multiple txns in same thread break mdb
by h.b.furuseth＠usit.uio.no 08 Apr '12

08 Apr '12

Full_Name: Hallvard B Furuseth Version: OS: URL: Submission from: (NULL) (195.1.106.125) Submitted by: hallvard mdb.h says a transaction must only be used by a single thread, but libmdb also assumes a thread only has one transaction: If there have been some commits since the oldest txn, and a new txn then starts in the same thread as an oldest txn, the oldest txnid is overwritten in the reader table. Writers can then modify pages the oldest txn still uses. Example: This should print A, but prints AEFG. It commits an "A", starts a reader and reads the A, then several commits delete the lowest letter and add two newer letter: -A +BC, -B +DE, -C +FG... while starting new readers, then reads more with 1st reader. #include "mdb.h" #include <assert.h> #include <pthread.h> #include <stdio.h> #include <unistd.h> #define E(expr) assert(!(expr)) enum { Count = 6 }; static char dbname[] = "testdb.mdb"; static MDB_env *env; static MDB_dbi dbi; static pthread_barrier_t barrier; static void *reader(void *arg) { int i, rc; MDB_txn *txns[Count]; MDB_cursor *cursor; MDB_val key, data; pthread_barrier_wait(&barrier); E(mdb_txn_begin(env, NULL, MDB_RDONLY, &txns[0])); E(mdb_cursor_open(txns[0], dbi, &cursor)); E(mdb_cursor_get(cursor, &key, &data, MDB_NEXT)); fputs((char *) key.mv_data, stdout); pthread_barrier_wait(&barrier); for (i = 1; i < Count; i++) { pthread_barrier_wait(&barrier); E(mdb_txn_begin(env, NULL, MDB_RDONLY, &txns[i])); pthread_barrier_wait(&barrier); } while ((rc = mdb_cursor_get(cursor, &key, &data, MDB_NEXT)) == 0) fputs((char *) key.mv_data, stdout); puts("."); assert(rc == MDB_NOTFOUND); return arg; } int main(void) { char add[2] = "A", del[2] = "A"; MDB_val key = {2, add}, dkey = {2, del}, data = {3, "Hi"}; MDB_txn *txn; pthread_t tid; int i; unlink(dbname); E(mdb_env_create(&env)); E(mdb_env_open(env, dbname, MDB_NOSUBDIR, 0660)); E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_open(txn, NULL, 0, &dbi)); E(mdb_put(txn, dbi, &key, &data, 0)); ++*add; E(mdb_txn_commit(txn)); E(pthread_barrier_init(&barrier, NULL, 2)); E(pthread_create(&tid, NULL, reader, NULL)); pthread_barrier_wait(&barrier); for (i = 1; i < Count; i++) { pthread_barrier_wait(&barrier); E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_del(txn, dbi, &dkey, NULL )); ++*del; E(mdb_put(txn, dbi, &key, &data, 0)); ++*add; E(mdb_put(txn, dbi, &key, &data, 0)); ++*add; E(mdb_txn_commit(txn)); pthread_barrier_wait(&barrier); } pthread_barrier_wait(&barrier); E(pthread_join(tid, NULL)); return 0; } I have not looked at what happens if some of the readers are in the same thread as the writer.

1 0

Re: (ITS#7222) Slapd hangs on high load
by hrvoje.habjanic＠zg.t-com.hr 08 Apr '12

08 Apr '12

On 04.04.2012 17:45, Hrvoje Habjanić wrote: > On 03.04.2012 17:41, Howard Chu wrote: >> You may be able to avoid this bug by using an alternate malloc >> library, such as Google tcmalloc. >> > Hi. > > I did try - using tcmalloc. And this time, i got SIGSEGV. Odd thing is > that this happened in "pthread_mutex_lock" which is in libpthread.so ...? > > Another bug in centos libs? I would appreciate if you could take a look. > > Thx. > > H. > > p.s. url -> http://free-zg.t-com.hr/HrvojeHabjanic/hang3.log Hi. And, one more SIGSEGV ... Should i open a new ITS? H. p.s. http://free-zg.t-com.hr/HrvojeHabjanic/openldap/ssegv.log

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