openldap-bugs November 2012

openldap-bugs@openldap.org

30 participants
100 discussions

Re: (ITS#7448) "assertion failed" in MDB
by hyc＠symas.com 21 Nov '12

21 Nov '12

More information is needed than this. Your stack traces aren't even complete. What was the workload leading up to this? Give us a sample configuration that reproduces the assert. artemciy(a)gmail.com wrote: > Full_Name: Artem Grinblat > Version: git, commit be781ab8081d7e9ad1eb89da81077c7f936a5604 > OS: Debian Wheezy > URL: > Submission from: (NULL) (213.108.212.44) > > > MDB works okay for some time, then crashes with > > mdb.c:3778: mdb_page_search_root: Assertion `(((mp)->mp_pb.pb.pb_lower - > ((unsigned) __builtin_offsetof (MDB_page, mp_ptrs))) >> 1) > 1' failed. > > (gdb) bt > #0 WriteCoreDump (file_name=0x7f1f1f705fa0 "/tmp/tntnet.5541.core") at > src/coredumper.c:192 > #1 0x00007f1f4b163da9 in img2::writeCore (path=0x7f1f1f705fa0 > "/tmp/tntnet.5541.core") at src/conf.cpp:49 > #2 0x00007f1f4b16145d in img2::custom_sigaction (signum=6) at src/conf.cpp:89 > #3 <signal handler called> > #4 0x00007f1f469ba475 in *__GI_raise (sig=<optimized out>) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > #5 0x00007f1f469bd6f0 in *__GI_abort () at abort.c:92 > #6 0x00007f1f469b3621 in *__GI___assert_fail ( > assertion=assertion@entry=0x7f1f4155cdb0 "(((mp)->mp_pb.pb.pb_lower - > ((unsigned) __builtin_offsetof (MDB_page, mp_ptrs))) >> 1) > 1", file=<optimized > out>, > file@entry=0x7f1f4155cb30 "mdb.c", line=line@entry=3778, > function=function@entry=0x7f1f4155d360 "mdb_page_search_root") at assert.c:81 > #7 0x00007f1f41555ccd in mdb_page_search_root (mc=mc@entry=0x7f1f1f708500, > key=key@entry=0x0, modify=modify@entry=0) at mdb.c:3778 > #8 0x00007f1f4155467a in mdb_page_search (mc=mc@entry=0x7f1f1f708500, > key=key@entry=0x0, flags=flags@entry=0) at mdb.c:3908 > #9 0x00007f1f41554a07 in mdb_cursor_first (mc=0x7f1f1f708500, > key=key@entry=0x7f1f1f7070f0, data=data@entry=0x0) at mdb.c:4354 > #10 0x00007f1f4155517e in mdb_cursor_set (mc=mc@entry=0x7f1f1f708370, > key=key@entry=0x7f1f1f708770, data=data@entry=0x7f1f1f7070f0, > op=op@entry=MDB_SET, > exactp=exactp@entry=0x7f1f1f7070d4) at mdb.c:4307 > #11 0x00007f1f41559c8d in mdb_cursor_put (mc=0x7f1f1f708370, key=0x7f1f1f708770, > data=0x7f1f1f708790, flags=0) at mdb.c:4672 > #12 0x00007f1f4155bdc9 in mdb_put (txn=<optimized out>, dbi=<optimized out>, > key=0x7f1f1f708770, data=0x7f1f1f708790, flags=<optimized out>) at mdb.c:6599 > > Also under Valgrind: > ==7503== Warning: set address range perms: large range [0x3959d000, 0x7959d000) > (defined) > **7503** custom_sigaction, signal 6 at 0x51B6EEC: > VALGRIND_PRINTF_BACKTRACE(char const*, ...) (valgrind.h:3771) > ==7503== by 0x51B72A1: img2::custom_sigaction(int) (conf.cpp:77) > ==7503== by 0x985B4EF: ??? (in /lib/x86_64-linux-gnu/libc-2.13.so) > ==7503== by 0x985B474: raise (raise.c:64) > ==7503== by 0x985E6EF: abort (abort.c:92) > ==7503== by 0x9854620: __assert_fail (assert.c:81) > ==7503== by 0xEDD9CCC: mdb_page_search_root (mdb.c:3778) > ==7503== by 0xEDD8679: mdb_page_search (mdb.c:3908) > ==7503== by 0xEDD8F78: mdb_cursor_set (mdb.c:4268) > ==7503== by 0xEDD8EB0: mdb_cursor_set (mdb.c:4316) > ==7503== by 0xEDDFCA8: mdb_del (mdb.c:6165) > > -- -- 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#7428) libldap: use non-blocking IO during TLS handshake
by rhafer＠suse.de 21 Nov '12

21 Nov '12

I just pushed latest incarnation of my patch to master. The code in currently hidden behind #ifdefs (mainly for the NSS issues outlined on -devel) and I switch back again to using LDAP_OPT_NETWORK_TIMEOUT for TLS handshake timeouts. regards, Ralf On Thu, Nov 01, 2012 at 05:22:42PM +0000, rhafer(a)suse.de wrote: > > Currently libldap is using blocking IO when performing the SSL handshake for > ldaps:// connections (and when performing the StartTLS operation). The can lead > to the client blocking forever in the ssl lib (in SSL_connect in case of > openssl) if e.g. the server for whatever reason stops responding. It would be > very helpful if libldap would use non-blocking IO during the handshake at least > when LDAP_OPT_NETWORK_TIMEOUT (or LDAP_OPT_TIMEOUT?) are set.

1 0

(ITS#7448) "assertion failed" in MDB
by artemciy＠gmail.com 20 Nov '12

20 Nov '12

Full_Name: Artem Grinblat Version: git, commit be781ab8081d7e9ad1eb89da81077c7f936a5604 OS: Debian Wheezy URL: Submission from: (NULL) (213.108.212.44) MDB works okay for some time, then crashes with mdb.c:3778: mdb_page_search_root: Assertion `(((mp)->mp_pb.pb.pb_lower - ((unsigned) __builtin_offsetof (MDB_page, mp_ptrs))) >> 1) > 1' failed. (gdb) bt #0 WriteCoreDump (file_name=0x7f1f1f705fa0 "/tmp/tntnet.5541.core") at src/coredumper.c:192 #1 0x00007f1f4b163da9 in img2::writeCore (path=0x7f1f1f705fa0 "/tmp/tntnet.5541.core") at src/conf.cpp:49 #2 0x00007f1f4b16145d in img2::custom_sigaction (signum=6) at src/conf.cpp:89 #3 <signal handler called> #4 0x00007f1f469ba475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #5 0x00007f1f469bd6f0 in *__GI_abort () at abort.c:92 #6 0x00007f1f469b3621 in *__GI___assert_fail ( assertion=assertion@entry=0x7f1f4155cdb0 "(((mp)->mp_pb.pb.pb_lower - ((unsigned) __builtin_offsetof (MDB_page, mp_ptrs))) >> 1) > 1", file=<optimized out>, file@entry=0x7f1f4155cb30 "mdb.c", line=line@entry=3778, function=function@entry=0x7f1f4155d360 "mdb_page_search_root") at assert.c:81 #7 0x00007f1f41555ccd in mdb_page_search_root (mc=mc@entry=0x7f1f1f708500, key=key@entry=0x0, modify=modify@entry=0) at mdb.c:3778 #8 0x00007f1f4155467a in mdb_page_search (mc=mc@entry=0x7f1f1f708500, key=key@entry=0x0, flags=flags@entry=0) at mdb.c:3908 #9 0x00007f1f41554a07 in mdb_cursor_first (mc=0x7f1f1f708500, key=key@entry=0x7f1f1f7070f0, data=data@entry=0x0) at mdb.c:4354 #10 0x00007f1f4155517e in mdb_cursor_set (mc=mc@entry=0x7f1f1f708370, key=key@entry=0x7f1f1f708770, data=data@entry=0x7f1f1f7070f0, op=op@entry=MDB_SET, exactp=exactp@entry=0x7f1f1f7070d4) at mdb.c:4307 #11 0x00007f1f41559c8d in mdb_cursor_put (mc=0x7f1f1f708370, key=0x7f1f1f708770, data=0x7f1f1f708790, flags=0) at mdb.c:4672 #12 0x00007f1f4155bdc9 in mdb_put (txn=<optimized out>, dbi=<optimized out>, key=0x7f1f1f708770, data=0x7f1f1f708790, flags=<optimized out>) at mdb.c:6599 Also under Valgrind: ==7503== Warning: set address range perms: large range [0x3959d000, 0x7959d000) (defined) **7503** custom_sigaction, signal 6 at 0x51B6EEC: VALGRIND_PRINTF_BACKTRACE(char const*, ...) (valgrind.h:3771) ==7503== by 0x51B72A1: img2::custom_sigaction(int) (conf.cpp:77) ==7503== by 0x985B4EF: ??? (in /lib/x86_64-linux-gnu/libc-2.13.so) ==7503== by 0x985B474: raise (raise.c:64) ==7503== by 0x985E6EF: abort (abort.c:92) ==7503== by 0x9854620: __assert_fail (assert.c:81) ==7503== by 0xEDD9CCC: mdb_page_search_root (mdb.c:3778) ==7503== by 0xEDD8679: mdb_page_search (mdb.c:3908) ==7503== by 0xEDD8F78: mdb_cursor_set (mdb.c:4268) ==7503== by 0xEDD8EB0: mdb_cursor_set (mdb.c:4316) ==7503== by 0xEDDFCA8: mdb_del (mdb.c:6165)

1 0

Re: (ITS#7447) backsql and german umlaute
by metzdorf＠geograt.de 20 Nov '12

20 Nov '12

The umlaut's are gone while posting. So i will try to describe: The search expression is "search<lower umlaut a>o<lower umlaut o>u...". This is converted to "SEARCH<lower umlaut a>O<lower umlaut o>U" in the SELECT statement. The expected is "SEARCH<upper umlaut a>O<upper umlaut o>U". -- Herbert Metzdorf

1 0

(ITS#7447) backsql and german umlaute
by metzdorf＠geograt.de 20 Nov '12

20 Nov '12

Full_Name: Herbert Metzdorf Version: 2.4.30 OS: Windows 7 / 2008 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.138.76.52) I am using thunderbird to query the openldap with the sql backend. Queries with german umlaut's give no result because of wrong lower/uppercase conversion. Look at the following log snippets: 50ab7cdb ==> limits_get: conn=1008 op=1 self="[anonymous]" this="ou=adressen,dc=geograt,dc=de" 50ab7cdb ==>backsql_search(): base="ou=adressen,dc=geograt,dc=de", filter="(|(?mail=*searchäoöuü*)(cn=*searchäoöuü*)(givenName=*searchäoöuü*)(sn=*searchäoöuü*))", scope=2,50ab7cdb deref=0, attrsonly=0, attributes to load: custom list 50ab7cdb ==>backsql_get_db_conn() ... 50ab7cdb <==backsql_srch_query() returns SELECT DISTINCT ldap_entries.id,ldap_persons.sysid,'inetOrgPerson' AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,ldap_persons WHERE ldap_persons.sysid=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND UPPER(ldap_entries.dn) LIKE CONCAT('%',UPPER(?)) AND (1=0 OR (UPPER(vorname||' '||nachname) LIKE '%SEARCHäOöUü%') OR (UPPER(vorname) LIKE '%SEARCHäOöUü%') OR (UPPER(nachname) LIKE '%SEARCHäOöUü%')) The search expression in converted to uppercase but this fails for the umlaut's. Is there a parameter to configure this behavior, or do you know a workaround? Thanks for your help Herbert

1 0

Re: (ITS#7446) slapadd OBSOLETE object class fails
by michael＠stroeder.com 19 Nov '12

19 Nov '12

masarati(a)aero.polimi.it wrote: > Maybe "manage" should be passed to > slap_tool_entry_check(), and write tools (slapadd, slapmodify) could have > an explicit '-o manage' option to enable handling of these cases. I'd regard slapadd to be in kind of a manage mode by default. E.g. it does not check constraints. And as said OBSOLETE attribute types are already accepted. Ciao, Michael.

1 0

Re: (ITS#7446) slapadd OBSOLETE object class fails
by masarati＠aero.polimi.it 19 Nov '12

19 Nov '12

> Full_Name: Michael Ströder > Version: HEAD > OS: > URL: > Submission from: (NULL) (79.227.170.198) > > > Importing an LDIF file with slapadd which contains entries with an object > class > marked as OBSOLETE in the schema fails. > > Importing entries with OBSOLETE attribute types seems to work just fine. > > If object classes are marked as OBSOLETE it's clear that it should be > impossible > to add new entries via LDAP based on such an object class. But it should > still > be possible to restore old entries from backup. Currently, slap_tool_entry_check() sets "manage" to 0 when calling entry_schema_check(); setting it to !0 would allow loading of OBSOLETE objectClasses. Maybe "manage" should be passed to slap_tool_entry_check(), and write tools (slapadd, slapmodify) could have an explicit '-o manage' option to enable handling of these cases. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7446) slapadd OBSOLETE object class fails
by michael＠stroeder.com 19 Nov '12

19 Nov '12

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (79.227.170.198) Importing an LDIF file with slapadd which contains entries with an object class marked as OBSOLETE in the schema fails. Importing entries with OBSOLETE attribute types seems to work just fine. If object classes are marked as OBSOLETE it's clear that it should be impossible to add new entries via LDAP based on such an object class. But it should still be possible to restore old entries from backup.

1 0

(ITS#7445) slapo-deref: deref control should only be register when actually enabled
by rhafer＠suse.de 19 Nov '12

19 Nov '12

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: SLES11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.252.81.246) This is similar to ITS#6647 (which was about sssvlv). Support for the deref control should only be advertised in rootDSE when at least one instance of the deref overlay is present. Patch is on the way.

1 0

(ITS#7444) Check the return value of ldap_pvt_thread_set_concurrency
by tixu＠cs.ucsd.edu 16 Nov '12

16 Nov '12

Full_Name: Tianyin Xu Version: 2.4.33 OS: Ubuntu 12.04 (actually doesn't matter) URL: Submission from: (NULL) (2607:f720:1300:1241:590b:49c:889f:7b21) Hi, all, Still the verbosity idea. In the current version of slapd, when handling users' "concurrency" setting, slapd does not check the return value of "ldap_pvt_thread_set_concurrency" (essentially the return value of "pthread_setconcurrency") to see whether the setting is successful or not. So when the user setting is inappropriate (i.e., too big), slapd says nothing. But users have no way to be aware of such configuration failure. I suggest to check and notify users in this case. Here's the patch: --- ../openldap-2.4.33/servers/slapd/bconfig.c 2012-10-10 05:18:49.000000000 -0700 +++ servers/slapd/bconfig.c 2012-11-16 14:52:37.211421828 -0800 @@ -1530,7 +1530,14 @@ break; case CFG_CONCUR: - ldap_pvt_thread_set_concurrency(c->value_int); + + if(ldap_pvt_thread_set_concurrency(c->value_int) != 0) { + snprintf( c->cr_msg, sizeof( c->cr_msg ), + "concurrency=%d is not valid; using the default setting", + c->value_int ); + Debug(LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->cr_msg, 0 ); + + } break; case CFG_THREADS:

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2012