Full_Name: Frank Offermanns Version: 2.4.16 OS: Windows XP URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.6.189.242) Hello, i am using OpenLDAP 2.4.16 with Windows XP, compiled with msys/mingw with Windows XP and the berkeley DB 4.7.25 NC The database runs without any replication (though with replication it also crashes) I use the "hdb" Backend. I started the datatbase with "slapd -F slapd.d". Now i add about 21000 Entries under the DN: o=test6,ou=Users,o=caesar. When this is finished i start adding another 21000 Entries under the DN: o=test7,ou=Users,o=caesar. While adding these seconds entries i use the LDAPAdmin 1.1.0.0 to view the subtree at "o=test6,ou=Users,o=caesar". LDAPAdmin starts to read the Users and fails at about the 4000 Entry. At this time my slapd.exe crashed. I also did the test with "slapd -d 1 -F slapd.d" and found the following entries in the logfile: ber_flush2: 77 bytes to sd 2268 ber_get_next: tag 0x30 len 93 contents: <= send_search_entry: conn 0 exit. ber_get_next conn=2 op=4017 do_modify entry_decode: "" ber_scanf fmt ({m) ber: ber_scanf fmt ({e{m[W]}}) ber: <= entry_decode() >>> dnPrettyNormal: <cn=10250,o=test7,ou=users,o=caesar> <<< dnPrettyNormal: <cn=10250,o=test7,ou=users,o=caesar>, <cn=10250,o=test7,ou=users,o=caesar> bdb_dn2entry("cn=10250,o=test7,ou=users,o=caesar") => send_search_entry: conn 0 dn="cn=12034,o=test6,ou=Users,o=caesar" => hdb_dn2id("cn=10250,o=test7,ou=users,o=caesar") ber_flush2: 77 bytes to sd 2268 <= hdb_dn2id: got id=0x53da <= send_search_entry: conn 0 exit. entry_decode: "" entry_decode: "" <= entry_decode() <= entry_decode() bdb_dn2entry("cn=10250,o=test7,ou=users,o=caesar") => send_search_entry: conn 0 dn="cn=12035,o=test6,ou=Users,o=caesar" ber_flush2: 77 bytes to sd 2268 entry_decode: "" <= entry_decode() <= send_search_entry: conn 0 exit. bdb_modify_internal: 0x000053da: c�0250 entry_decode: "" <= entry_decode() entry failed schema check: unrecongized attribute type(s) in RDN hdb_modify: modify failed (34) send_ldap_result: conn=2 op=4017 p=3 send_ldap_response: msgid=1026718 tag=103 err=34 => send_search_entry: conn 0 dn="cn=12036,o=test6,ou=Users,o=caesar" ber_flush2: 53 bytes to sd 2336 ber_flush2: 77 bytes to sd 2268 <= send_search_entry: conn 0 exit. entry_decode: "" <= entry_decode() connection_get(4): got connid=2 connection_read(4): checking for input on id=2 ber_get_next ber_get_next: tag 0x30 len 87 contents: ber_get_next conn=2 op=4018 do_modify ber_scanf fmt ({m) ber: ber_scanf fmt ({e{m[W]}}) ber: >>> dnPrettyNormal: <cn=10250,o=test7,ou=users,o=caesar> <<< dnPrettyNormal: <cn=10250,o=test7,ou=users,o=caesar>, <cn=10250,o=test7,ou=users,o=caesar> bdb_dn2entry("cn=10250,o=test7,ou=users,o=caesar") => hdb_dn2id("cn=10250,o=test7,ou=users,o=caesar") <= hdb_dn2id: got id=0x53da entry_decode: "" <= entry_decode() The pointer at "bdb_modify_internal" seems to be dangling. When i didn't read the entries while writing, there seems to be no problem. The Version 2.4.13 also does not seem to have this problem. (I couldn't get the 2.4.13 Version crashing and the 2.4.16 crashes every time after a short time) Additional Info: I am not sure, if this could be a reason for this error, so i am writing this problem also. Starting at Version 2.4.14 the configure command creates makefiles which are not linkable at mingw/msys at windows. I manually added "-lws2_32" in the makefiles at the lines: AC_LIBS = -lregex -lws2_32 I apologize me for my bad english and hope you can understand me. Regards, Frank Offermanns
Hello, i want to add, that with a "bdb" backend the slapd.exe does not crash. Only with the "hdb" backend it crashes. Here is the callstack for this crash: *----> Stack Back Trace <----* WARNING: Stack unwind information not available. Following frames may be wrong. ChildEBP RetAddr Args to Child 0d4af720 00497758 00000034 0d4af798 0d4af740 slapd!ldap_pvt_thread_mutex_lock+0x12 0d4af750 00497b4c 00000000 0d4af798 00000001 slapd!hdb_cache_modify+0x98 0d4af7c0 0049809f 00c723d0 01204440 09dbcb00 slapd!hdb_cache_modify+0x48c 0d4af860 004a86d8 0a7391d0 01204440 0000242b slapd!hdb_cache_find_id+0x30f 0d56faf0 0041918b 0a7391d0 0d56fcd8 00000000 slapd!hdb_search+0x1538 0d56fb30 004188fd 0a7391d0 0d56fcd8 00000001 slapd!fe_op_search+0x43b 0d56fc90 004172c8 0a7391d0 0d56fcd8 0d56fcd4 slapd!do_search+0x4ad 0d56fd30 00417ad9 0d56fdd8 0a7391d0 00000000 slapd!connection_hangup+0x5d8 0d56fdb0 004ef6db 0d56fdd8 00000003 00000038 slapd!connection_hangup+0xde9 0d56ff80 77c0a3b0 00bf8bc0 0000077c 000008b8 slapd!ldap_pvt_thread_pool_context_reset+0x1ab 0d56ffb4 7c80b699 00cc66f0 0000077c 000008b8 msvcrt!endthreadex+0xa9 0d56ffec 00000000 77c0a341 00cc66f0 00000000 kernel32!GetModuleFileNameA+0x1ba Regards, Frank Offermanns -- -- Frank Offermanns | Entwicklung | CASERIS GmbH Fon: +49 2402 7654-566 Fax: +49 2402 7654-8566 | E-Mail: Frank.Offermanns@caseris.com -- CASERIS GmbH | Am Birkenfeld 1-3 | D-52222 Stolberg Geschäftsführer Dipl.-Ing. Stefan Preuß | Registergericht: Amtsgericht Aachen, HRB 14758
changed notes
changed notes changed state Open to Test moved from Incoming to Software Bugs
changed notes changed state Test to Release
changed notes changed state Release to Closed
fixed in HEAD by #6095 Fixed in RE24