openldap-bugs

openldap-bugs@openldap.org

1 participants
21184 discussions

(ITS#8092) slapd crash with sasl auxprop and empty suffix
by ryan＠nardis.ca 25 Mar '15

25 Mar '15

Full_Name: Ryan Tandy Version: master, 2.4 OS: Debian URL: Submission from: (NULL) (24.68.37.4) Based on a Debian bug report: https://bugs.debian.org/781162 ./configure --enable-spasswd cat > slapd.conf << EOF include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema database mdb directory . suffix "" EOF slapadd -f slapd.conf << EOF dn: dc=com objectClass: domain dn: dc=example,dc=com objectClass: domain dn: uid=test,dc=example,dc=com objectClass: account objectClass: simpleSecurityObject userPassword: {SASL}test(a)EXAMPLE.COM EOF ldapwhoami -x -D uid=test,dc=example,dc=com Enter LDAP Password: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffeebab700 (LWP 28815)] __strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:210 210 ../sysdeps/x86_64/multiarch/../strcmp.S: No such file or directory. (gdb) bt #0 __strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:210 #1 0x0000000000441689 in select_backend (dn=0x7fffeebaa1a8, noSubs=1) at backend.c:704 #2 0x000000000049c7c2 in slap_auxprop_lookup (glob_context=0x0, sparams=0x7fffe0001cd0, flags=0, user=0x7fffe0001861 "test(a)EXAMPLE.COM", ulen=16) at sasl.c:370 #3 0x00007ffff7bc463b in _sasl_auxprop_lookup (sparams=0x7fffe0001cd0, flags=flags@entry=0, user=0x7fffe0001861 "test(a)EXAMPLE.COM", ulen=16) at ../../lib/auxprop.c:959 #4 0x00007ffff7bc5467 in _sasl_auxprop_lookup_user_props (oparams=0x7fffe0001330, flags=3, conn=0x7fffe0000ac0) at ../../lib/canonusr.c:220 #5 _sasl_canon_user_lookup (conn=conn@entry=0x7fffe0000ac0, user=user@entry=0x7fffe0001460 "test(a)EXAMPLE.COM", ulen=ulen@entry=0, flags=flags@entry=3, oparams=oparams@entry=0x7fffe0001330) at ../../lib/canonusr.c:281 #6 0x00007ffff7bc5d39 in auxprop_verify_password (conn=0x7fffe0000ac0, userstr=0x7fffe0001460 "test(a)EXAMPLE.COM", passwd=0x7fffe0002696 "asdf", service=<optimized out>, user_realm=<optimized out>) at ../../lib/checkpw.c:159 #7 0x00007ffff7bcee78 in _sasl_checkpass (conn=conn@entry=0x7fffe0000ac0, user=0x7fffe0001460 "test(a)EXAMPLE.COM", userlen=userlen@entry=16, pass=pass@entry=0x7fffe0002696 "asdf", passlen=passlen@entry=4) at ../../lib/server.c:1922 #8 0x00007ffff7bd1e50 in sasl_checkpass (conn=0x7fffe0000ac0, user=<optimized out>, userlen=16, pas3D0x0x7fffe0002696 "asdf", passlen=4) at ../../lib/server.c:1989 #9 0x000000000049e4db in chk_sasl (sc=0x8cac98, passwd=0x7fffeebaa8a0, cred=0x7fffe0002700, text=0x7fffeebaaae0) at sasl.c:990 #10 0x0000000000535278 in lutil_passwd (passwd=0x7fffe0003188, cred=0x7fffe0002700, schemes=0x0, text=0x7fffeebaaae0) at passwd.c:327 #11 0x0000000000474aa6 in slap_passwd_check (op=0x7fffe00026b0, e=0x7fffe0002f28, a=0x7fffe0002fa8, cred=0x7fffe0002700, text=0x7fffeebaaae0) at passwd.c:529 #12 0x00000000005088e7 in mdb_bind (op=0x7fffe00026b0, rs=0x7fffeebaaac0) at bind.c:120 #13 0x00000000004584f6 in fe_op_bind (op=0x7fffe00026b0, rs=0x7fffeebaaac0) at bind.c:383 #14 0x0000000000457bb4 in do_bind (op=0x7fffe00026b0, rs=0x7fffeebaaac0) at bind.c:205 #15 0x000000000042f68a in connection_operation (ctx=0x7fffeebaabf0, arg_v=0x7fffe00026b0) at connection.c:1134 #16 0x000000000042fc3a in connection_read_thread (ctx=0x7fffeebaabf0, argv=0xc) at connection.c:1280 #17 0x00000000005401bf in ldap_int_thread_pool_wrapper (xpool=0x8b83c0) at tpool.c:958 #18 0x00007ffff74750a4 in start_thread (arg=0x7fffeebab700) at pthread_create.c:309 #19 0x00007ffff71aa04d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 I don't know how auxprop is intended to be configured; I'm going to follow up on that when I have time. This is just about a segv that happens when pwcheck_method is auxprop (the default) and the suffix is the empty string.

1 0

(ITS#8091) Updateref for openldap 2.4.39 not work
by betchenhuang＠163.com 25 Mar '15

25 Mar '15

Full_Name: marix wong Version: 2.4.39 OS: redhat 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (119.145.14.210) Updateref for openldap 2.4.39 not work i configured updateref option in slapd.conf for consumer slapd, later i restart slapd Successfully, but when i add new record to consumer, it failed. this new recored not refer to master slapd. in log ,i found the return code 10 which means: ldap_add: Referral (10) referrals: ldaps://xxx:xxx/uid=meixuan,ou=Peoples,dc=hadoop,dc=com this is my configuration: syncrepl rid=124 provider=ldaps://167.52.0.35:21780 type=refreshAndPersist%0 interval=00:00:00:15 searchbase="dc=hadoop,dc=com" filter="(objectClass=*)" scope=sub attrs="*,+" tls_reqcert=allow tls_cacert=/opt/cert/cacert.pem schemachecking=off bindmethod=simple binddn="cn=root,dc=hadoop,dc=com" credentials=Ldap@123 retry="15 +" updateref ldaps://167.52.0.35:21780 so i want to know how to make this option work better?

1 0

(ITS#8090) libldap bugfix: Spurious initial LDAP_CONNECT_ERROR with LDAP_OPT_CONNECT_ASYNC enabled
by olli.salli＠vincit.fi 25 Mar '15

25 Mar '15

Full_Name: Olli Salli Version: git master OS: Windows 8.1, Linux 3.18.10 URL: ftp://ftp.openldap.org/incoming/olli-salli-150325.patch Submission from: (NULL) (83.102.45.242) We are working on an application which needs to perform some simple LDAP search queries every once in a while. The application is running as a daemon in an embedded server environment and has no user interface, and is instead remotely controlled and configured via a control TCP connection. This includes the configuration specifying the LDAP server address and port, and whether the LDAP queries should be attempted at all (if there is no server available). We are currently developing on Windows 8.1 with Visual Studio 2013 but will also run in Linux environments. To ensure the control TCP connection stays alive at all times (and the daemon otherwise functional), and to avoid using threads, whahave used the openldap asynchronous APIs, including the asynchronous connect option - if the configured LDAP server is unreachable, the initial search query can block for a very long time otherwise. It is here that we have hit a small issue. When using LDAP_OPT_CONNECT_ASYNC, if the LDAP server is unreachable, the initial request (e.g. using ldap_search_ext) does not block, which is correct. However, this first call returns LDAP_CONNECT_ERROR. If we disregard this, and continue reissuing the ldap_search_ext request periodically, following calls correctly return LDAP_X_CONNECTING. Then when the NETWORK_TIMEOUT has elapsed, LDAP_CONNECT_ERROR is returned again, which is correct. LDAP_CONNECT_ERROR might result in the first ldap_search_ext call from legitimate error conditions in connect() even in asynchronous mode, for example out-of-resource conditions (EADDRNOTAVAIL), or all local network interfaces being down (ENETUNREACH), etc. These should be handled as fatal errors, but would be impossible to distinguish from the false initial LDAP_CONNECT_ERROR resulting from using LDAP_OPT_CONNECT_ASYNC. The issue seems to be in ldap_send_initial_request (http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/…). When async connect is enabled what happens during the first request is: 1) sd is initialized to AC_SOCKET_INVALID 2) ber_sockbuf_ctrl( ... LBER_SB_OPT_GET_FD ... ) is called to determine whether there is already a connection, and to fetch its socket descriptor to sd 3) as there is no connection, it returns -1 and sd stays AC_SOCKET_INVALID 4) a new connection is formed using ldap_open_defconn() 5) ldap_int_check_async_open( ld, sd ) is called, but sd is still AC_SOCKET_INVALID, and thus the poll fails 6) LDAP_CONNECT_ERROR is returned On successive calls, what happens is 1) ber_sockbuf_ctrl( ... LBER_SB_OPT_GET_FD ... ) returns success and a valid socket descriptor 2) opening a new connection is skipped 3) ldap_int_check_async_open( ld, sd ) is called this time with a valid socket descriptor 4) the poll works as intended A simple fix is to simply reissue ber_sockbuf_ctrl( ... LBER_SB_OPT_GET_FD ... ) after opening the connection. This fixes the first poll to return LDAP_X_CONNECTING as intended. This is implemented in the patch at the URL. A perhaps more semantically correct alternative could be to return the created socket descriptor from ldap_open_defconn().

1 0

(ITS#8089) LMDB hangs on mdb_txn_renew0 if MDB_NOSYNC flag is used
by pk＠dbic.pro 24 Mar '15

24 Mar '15

Full_Name: Pavel Kraynyukhov Version: only LMDB from git and lmdb-0.9.14 OS: Gentoo Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.99.47.171) Hello there, I have ran into an issue with LMDB, which I can reproduce at will, but it seems a specific one. The git commit is 3368d1f5e243225cba4d730fba19ff600798ebe3 And this commit and my issue seems to be related. 1. I use MDB_NOTLS flag on environment open. 2. if I use MDB_NOSYNC flag for LMDB environment, the writer thread is stuck after several transactions (writer thread backtrace): #0 0x00007fe5534a25dc in __lll_robust_lock_wait () from /lib64/libpthread.so.0 #1 0x00007fe553498ba1 in __pthread_mutex_lock_full () from /lib64/libpthread.so.0 #2 0x00007fe553ed895a in mdb_txn_renew0 (txn=txn@entry=0x661810) at mdb.c:2638 #3 0x00007fe553ed9558 in mdb_txn_begin (env=0x6606c0, parent=0x0, flags=<optimized out>, ret=0x7fe552bebd08) at mdb.c:2813 #4 0x000000000041cd0c in beginWOTxn (parent=0x0, this=0x6603a8) at ../ITCFramework/include/LMDBEnv.h:220 #5 itc::lmdb::WOTxn::WOTxn (this=0x7fe552bebdb0, ref=...) at ../ITCFramework/include/LMDBWOTxn.h:51 #6 0x0000000000420c5b in itc::lmdb::DBWriter::dbWrite (this=this@entry=0x661b08) at ../ITCFramework/include/LMDBWriter.h:185 #7 0x00000000004210ff in itc::lmdb::DBWriter::execute (this=0x661b08) at ../ITCFramework/include/LMDBWriter.h:98 #8 0x0000000000414eac in itc::sys::CancelableThread<itc::lmdb::DBWriter>::run (this=0x7ffff31f7cd0) at ../ITCLib/include/sys/CancelableThread.h:84 #9 0x0000000000439dc4 in itc::sys::invoke (context=0x7ffff31f7cd0) at src/Thread.cpp:56 #10 0x00007fe55349b4c6 in start_thread () from /lib64/libpthread.so.0 #11 0x00007fe5531e000d in clone () from /lib64/libc.so.6 Before you might ask: 1. There is only one writer thread. Only this thread begins writable transactions and only this thread commits them and of course only this thread calls mdb_put(). 2. There suppose to be a multiple reader threads. For the test I'm running one only. And there are no read operations or cursor usage during this test at the same time when the writer is working. 3. When I write hang, I mean only the application not the system. The test application consume no CPU after it hang. 4. If no MDB_NOSYNC flag is used, then there is no bug/deadlock. This however may be due to very slow file system operations of my PC. It is about 35 writable transactions per second and about 27-39% I/O wait on the CPU. P.S. tested against system provided lmdb version 0.9.14 and result is the same. So this maybe not related to latest commit in git.

1 0

(ITS#8088) slapd man pages get installed when --disable-slapd is specified
by quanah＠openldap.org 24 Mar '15

24 Mar '15

Full_Name: Quanah Gibson-Mount Version: RE24 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.64.214) When only building out the client libraries (--disable-slapd), make install goes ahead and installs the man pages related to slapd, which should be skipped in this case.

1 0

(ITS#8087) Segmentation fault in MDB at idl.c:91 using searches
by francisco＠garnelo.eu 24 Mar '15

24 Mar '15

Full_Name: Francisco Garnelo Version: slapd 2.4.40 OS: FreeBSD 10.1-STABLE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.21) Hi, when I try to access with a LDAP browser (Apache DS) and the browser begin to enumerate the items in differents branches, the server crashes; this not takes more than 30 seconds from last restart. I experimented a similar issue with SLES 12(if not it is the same) and openldap 2.4.40 (from suse repositories) version, but in this system I could not take evidences. The database has more than 3GB of size and MDB is configured to support 100GB as the maximum size. The same databa w works fine ining BDB using an old openldap version. ############# # Versions: # ############# root@XXXX:/usr/local/etc/openldap # /usr/local/libexec/slapd -VVV @(#) $OpenLDAP: slapd 2.4.40 (Mar 24 2015 17:18:46) $ root@XXXX:/usr/rtrts/net/openldap24-server/work/openldap-2.4.40/servers/slapd Included static overlays: dynlist seqmod syncprov Included static backends: config ldif relay root@xxxx:/usr/local/etc/openldap # uname -a FreeBSD xxxx 10.1-STABLE FreeBSD 10.1-STABLE #0 r278906: Tue Feb 17 19:09:13 UTC 2015 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 ###################### # cn=config export: # ###################### version: 1 dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/openldap/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcConfigDir: slapd.d olcConfigFile: slapd.conf olcIdleTimeout: 0 olcIndexIntLen: 8 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcListenerThreads: 1 olcLocalSSF: 71 olcLogLevel: 0 olcPidFile: /var/run/openldap/slapd.pid olcReadOnly: FALSE olcReverseLookup: FALSE olcSizeLimit: unlimited olcThreads: 20 olcTLSCACertificateFile: /usr/local/etc/openldap/certs/public/ca.crt olcTLSCertificateFile: /usr/local/etc/openldap/certs/public/server.crt olcTLSCertificateKeyFile: /usr/local/etc/openldap/certs/private/server.key olcTLSCRLCheck: none olcTLSProtocolMin: 0.0 olcTLSVerifyClient: never olcToolThreads: 2 olcWriteTimeout: 0 dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModuleLoad: {0}back_mdb database config olcModulePath: /usr/local/libexec/openldap dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema ### -- omitted content -- ### include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /r%r/local/etc/openldap/schema/rfc2307bis.schema ### -- omitted content -- ### dn: olcDatabase={-1}frontend,cn=config objectClass: olcFrontendConfig objectClass: olcDatabaseConfig olcDatabase: {-1}frontend olcAccess: {0}to dn.base="" by * read olcAccess: {1}to dn.base%%2"cn=subsemema" by * read olcAccess: {2}to attrs=shadowLastChange by self write by * read olcAccess: {3}to * by * read olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcMonitoring: FALSE olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSizeLimit: unlimited olcSyncUseSubentry: FALSE dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by * none olcAddContentAcl: TRUE olcLastMod: TRUE olcMaxDerefDepth: 15 olcMonitoring: FALSE olcReadOnly: FALSE olcRootDN: cn=config olcRootPW: XXXXX olcSyncUseSubentry: FALSE dn: olcDatabase={1}mdb,cn=config objectClass: olcMdbConfig objectClass: olcDatabaseConfig olcDatabase: {1}mdb olcDbDirectory:2F2Fvar/db/openldap-data.mdb olcDbIndex: objectClass eq olcRootDN: cn=lalala,dc=yyyyyyy,dc=com olcRootPW: XXXXXXX olcSuffix: dc=yyyyyyy,dc=com ######## # GDB: # ######## 551194b6 => mdb_dn2id("lelreleID=6666999999(a)lol.com,ou=molon,dc=yyyyyyy,%3=com") 551194b6 <= mdb_entry_decode 551194b6 <= mdb_dn2id: got id=0x92b0 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 <= mdb_entry_decode 551194b6 mdb_dn2entry("lelreleID=6666999999(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b6 => mdb_entry_decode: 551194b6 => mdb_dn2id("lelreleID=6666999999(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b6 <= mdb_entry_decode 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 <= mdb_dn2id: got id=0x92b0 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 <=dbdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 <= mdb_entry_decode 551194b6 mdb_dn2entry("lelreleID=luser123(a)odin.lala,ou=molon,dc=yyyyyyy,dc=com") 551194b8 => mdb_dn2id("lelreleID=luser123(a)odin.lala,ou=molon,dc=yyyyyyy,dc=com") 551194b8 <= mdb_dn2id: got id=0x931e 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 <= mdb_entry_decode 551194b7 daemon: activity on 1 descriptor 551194b8 daemon: activity on:519194b8 11r551194b8 551194b8 daemon: read activity on 11 551194b8 mdb_dn2entry("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b8 => mdb_dn2id("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b7 => mdb_entry_decode: 551194b7 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 <= mdb_dn2id: got id=0x9321 551194b8 mdb_dn2entry("loloId=50,ou=fry,dc=yyyyyyy,dc=com") 551194b8 => mdb_entry_decode: 551194b8 => mdb_dn2id("loloId=50,ou=fry,dc=yyyyyyy,dc=com") 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 daemon: select: listen=6 active_threads=0 tvp=NULL 551194b8 daemon: select: listen=7 active_threads=0 tvp=NULL 551194b8 <= mdb_dn2id: got id=0xf 551194b6 <= mdb_entry_decode 551194b8 => mdb_entry_dece:3A 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 <= mdb_entry_decode 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 mdb_dn2entry("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b8 => mdb_dn2id("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b8 <= mdb_entry_decode 551194b8 mdb_dn2entry("lelreleID=262280000000000(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 <= mdb_dn2id: got id=0x9321 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 => mdb_dn2id("lelreleID=262280000000000(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 <= mdb_dn2id: got id=0x25 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 mdb_dn2entry("loloId=50,ou=fry,dc=yyyyyyy,dc=com") 551194b8 <= mdb_entry_decode [New Thread 2103c12400 (LWP 100750/slapd)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 2103c12400 (LWP 100750/slapd)] 0x00000008024a579f in mdb_idl_search (ids=0x210a980000, id=37) at idl.c:91 91 val = IDL_CMP( id, ids[cursor] ); Current language: auto; currently minimal -------------- Thanks, Francisco Garnelo

1 0

Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by whm＠stanford.edu 23 Mar '15

23 Mar '15

This one just bit us again. I know that the client should probably not be using pr at all, but the client is an Google supplied intergration application that we have little control over. Is this a problem that is going to be addressed as some point or will it be treated as a known limitation? Bill -- "We have meet the enemy and he is us." Pogo

1 0

Re: (ITS#8086) slapd with mdb backend crashes in id2entry
by hyc＠symas.com 22 Mar '15

22 Mar '15

Nikos Voutsinas wrote: > I am in the process of doing so. Do you have in mind a specific > commit/fix in REL_EN that might have solved this; That would help me > reproduce the initial problem (in 2.4.40) and confirm the fix (in REL_ENG). Most likely 9a72292ac134f80c1befe8102dee1160e57a92ec > > For start I will try to upgrade to REL_ENG the same system from which I > got the debug log, to see if that would help recover (although I have no > great hopes). > > On Sun, Mar 22, 2015 at 12:39 AM, Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com>> wrote: > > nvoutsin(a)gmail.com <mailto:nvoutsin@gmail.com> wrote: > > Full_Name: Nikos Voutsinas > Version: 2.4.40 > OS: Debian > URL: > ftp://ftp.openldap.org/__incoming/NikosVoutsinas_20-03-__2015_mdb_assertion… > <ftp://ftp.openldap.org/incoming/NikosVoutsinas_20-03-2015_mdb_assertion.id2…> > Submission from: (NULL) (5.55.167.101) > > > slapd with an mdb backend, after some time of normal operation, > may reach into a > situation where you can almost predictably crash it, with a > simple modify > operation. > > > Please test RE24 and see if you can still reproduce this issue. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/__project/ > <http://www.openldap.org/project/> > > -- -- 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#8086) slapd with mdb backend crashes in id2entry
by nvoutsin＠gmail.com 22 Mar '15

22 Mar '15

--001a1141ca9eb03add0511dda290 Content-Type: text/plain; charset=UTF-8 I am in the process of doing so. Do you have in mind a specific commit/fix in REL_EN that might have solved this; That would help me reproduce the initial problem (in 2.4.40) and confirm the fix (in REL_ENG). For start I will try to upgrade to REL_ENG the same system from which I got the debug log, to see if that would help recover (although I have no great hopes). On Sun, Mar 22, 2015 at 12:39 AM, Howard Chu <hyc(a)symas.com> wrote: > nvoutsin(a)gmail.com wrote: > >> Full_Name: Nikos Voutsinas >> Version: 2.4.40 >> OS: Debian >> URL: ftp://ftp.openldap.org/incoming/NikosVoutsinas_20-03- >> 2015_mdb_assertion.id2entry >> Submission from: (NULL) (5.55.167.101) >> >> >> slapd with an mdb backend, after some time of normal operation, may reach >> into a >> situation where you can almost predictably crash it, with a simple modify >> operation. >> > > Please test RE24 and see if you can still reproduce this issue. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --001a1141ca9eb03add0511dda290 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div>I am in the process of doing so. Do you have in = mind a specific commit/fix in REL_EN that might have solved this; That woul= d help me reproduce the initial problem (in 2.4.40) and confirm the fix (in= REL_ENG). <br></div><br></div>For start I will try to upgrade to REL_ENG t= he same system from which I got the debug log, to see if that would help re= cover (although I have no great hopes).<br></div><div class=3D"gmail_extra"= ><br><div class=3D"gmail_quote">On Sun, Mar 22, 2015 at 12:39 AM, Howard Ch= u <span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.com" target=3D"_blank">= hyc(a)symas.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" st= yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><a hr= ef=3D"mailto:nvoutsin@gmail.com" target=3D"_blank">nvoutsin(a)gmail.com</a> w= rote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Nikos Voutsinas<br> Version: 2.4.40<br> OS: Debian<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/NikosVoutsinas_20-03-2015_m= db_assertion.id2entry" target=3D"_blank">ftp://ftp.openldap.org/<u></u>inco= ming/NikosVoutsinas_20-03-<u></u>2015_mdb_assertion.id2entry</a><br> Submission from: (NULL) (5.55.167.101)<br> <br> <br> slapd with an mdb backend, after some time of normal operation, may reach i= nto a<br> situation where you can almost predictably crash it, with a simple modify<b= r> operation.<br> </blockquote> <br> Please test RE24 and see if you can still reproduce this issue.<span class= =3D"HOEnZb"><font color=3D"#888888"><br> <br> -- <br> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" target=3D"_blank">http://www.symas.com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/<u></u>project/</a><br> </font></span></blockquote></div><br></div> --001a1141ca9eb03add0511dda290--

1 0

Re: (ITS#8086) slapd with mdb backend crashes in id2entry
by hyc＠symas.com 21 Mar '15

21 Mar '15

nvoutsin(a)gmail.com wrote: > Full_Name: Nikos Voutsinas > Version: 2.4.40 > OS: Debian > URL: ftp://ftp.openldap.org/incoming/NikosVoutsinas_20-03-2015_mdb_assertion.id2… > Submission from: (NULL) (5.55.167.101) > > > slapd with an mdb backend, after some time of normal operation, may reach into a > situation where you can almost predictably crash it, with a simple modify > operation. Please test RE24 and see if you can still reproduce this issue. -- -- 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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs