openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#7667) performance degradation when using MDB_INTEGERKEY
by romange＠gmail.com 21 Aug '13

21 Aug '13

--f46d043c7d22cec95604e479b9f8 Content-Type: text/plain; charset=UTF-8 Thanks! I was aware of little endian transformation. I did not know that the change of insertion order affects write performance of the database that much. On Wed, Aug 21, 2013 at 12:54 AM, Howard Chu <hyc(a)symas.com> wrote: > romange(a)gmail.com wrote: > >> --001a11c1e98008372804e46726c2 >> Content-Type: text/plain; charset=UTF-8 >> >> >> Hi, I extracted a small dataset that shows the problem. >> you can download it from here: >> https://docs.google.com/file/**d/**0B6o29pwkWoERdnFSaUtMNDljemc/** >> edit?usp=sharing<https://docs.google.com/file/d/0B6o29pwkWoERdnFSaUtMNDljemc/edit?usp=sharing> >> >> I modified mdb_copy.c to demonstrate the difference. copy it to source dir >> from here >> https://docs.google.com/file/**d/**0B6o29pwkWoERd3VuUm1DN0FpcUU/** >> edit?usp=sharing<https://docs.google.com/file/d/0B6o29pwkWoERd3VuUm1DN0FpcUU/edit?usp=sharing> >> >> build and >> run "time ./mdb_copy foo foo2" >> after this change the flag at line 64 and run it again. >> at my computer the difference is 17s vs 1.7s for 3 million items. >> > > This test doesn't prove the existence of a bug. You're running on a > Little-Endian machine, therefore data that is in sorted order as a string > is in hashed order when used as an integer. Your data insert turns into a > worst-case insert order in this case, causing the worst possible random > access strides through memory. Assuming the two orders to be equivalent is > a pretty common mistake for DB programmers. Microsoft has done the same > thing in ActiveDirectory, I mentioned it here a few years ago > http://www.openldap.org/lists/**openldap-devel/200711/**msg00002.html<http://www.openldap.org/lists/openldap-devel/200711/msg00002.html> > > If you had run this test on a Big-Endian machine, like SPARC, the insert > order would be identical either way, and INTEGERKEY result would have been > faster. > > Closing this ITS, no bug. > > >> >> >> On Tue, Aug 20, 2013 at 9:04 PM, Quanah Gibson-Mount <quanah(a)zimbra.com >> >wrote: >> >> --On Sunday, August 18, 2013 11:46 AM +0000 romange(a)gmail.com wrote: >>> >>> Full_Name: Roman Gershman >>> >>>> Version: >>>> OS: linux 3.8.0-25-generic >>>> URL: >>>> Submission from: (NULL) (212.150.97.210) >>>> >>>> >>> Please provide further information, specifically: >>> >>> The size of values >>> Insert order >>> Sample code if possible >>> >>> Thanks, >>> Quanah >>> >>> >>> -- >>> >>> Quanah Gibson-Mount >>> Lead Engineer >>> Zimbra, Inc >>> -------------------- >>> Zimbra :: the leader in open source messaging and collaboration >>> >>> >> >> >> > > -- > -- 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/> > -- Best regards, Roman --f46d043c7d22cec95604e479b9f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra">Thanks! I was aware of little e= ndian transformation. I did not know that the change of insertion order aff= ects write performance of the database that much.=C2=A0</div><div class=3D"= gmail_extra"> </div><div class=3D"gmail_extra"> </div><div class=3D"gmail_extra"><= br><div class=3D"gmail_quote">On Wed, Aug 21, <a href=3D"tel:2013" value=3D= "+9722013" target=3D"_blank">2013</a> at 12:54 AM, Howard Chu <<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</= a>> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><a href=3D"mailto:romange@gmail.com" target= =3D"_blank">romange(a)gmail.com</a> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> --001a11c1e98008372804e46726c2 Content-Type: text/plain; charset=3DUTF-8<div> Hi, I extracted a small dataset that shows the problem. you can download it from here: <a href=3D"https://docs.google.com/file/d/0B6o29pwkWoERdnFSaUtMNDljemc/edit= ?usp=3Dsharing" target=3D"_blank">https://docs.google.com/file/d/= 0B6o29pwkWoERdnFSaUtMNDljemc/edit?usp=3Dsharing</a> I modified mdb_copy.c to demonstrate the difference. copy it to source dir<= br> from here <a href=3D"https://docs.google.com/file/d/0B6o29pwkWoERd3VuUm1DN0FpcUU/edit= ?usp=3Dsharing" target=3D"_blank">https://docs.google.com/file/d/= 0B6o29pwkWoERd3VuUm1DN0FpcUU/edit?usp=3Dsharing</a> build and run "time ./mdb_copy foo foo2" after this change the flag at line 64 and run it again. at my computer the difference is 17s vs 1.7s for 3 million items. </div></blockquote> This test doesn't prove the existence of a bug. You're running on a= Little-Endian machine, therefore data that is in sorted order as a string = is in hashed order when used as an integer. Your data insert turns into a w= orst-case insert order in this case, causing the worst possible random acce= ss strides through memory. Assuming the two orders to be equivalent is a pr= etty common mistake for DB programmers. Microsoft has done the same thing i= n ActiveDirectory, I mentioned it here a few years ago <a href=3D"http://ww= w.openldap.org/lists/openldap-devel/200711/msg00002.html" target=3D"_blank"= >http://www.openldap.org/lists/openldap-devel/200711/msg00002= .html</a> If you had run this test on a Big-Endian machine, like SPARC, the insert or= der would be identical either way, and INTEGERKEY result would have been fa= ster. Closing this ITS, no bug.<div><div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Tue, Aug 20, <a href=3D"tel:2013" value=3D"+9722013" target=3D"_blank">2= 013</a> at 9:04 PM, Quanah Gibson-Mount <<a href=3D"mailto:quanah@zimbra= .com" target=3D"_blank">quanah(a)zimbra.com</a>>wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> --On Sunday, August 18, <a href=3D"tel:2013" value=3D"+9722013" target=3D"_= blank">2013</a> 11:46 AM +0000 <a href=3D"mailto:romange@gmail.com" target= =3D"_blank">romange(a)gmail.com</a> wrote: =C2=A0 Full_Name: Roman Gershman <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Version: OS: linux 3.8.0-25-generic URL: Submission from: (NULL) (212.150.97.210) </blockquote> Please provide further information, specifically: The size of values Insert order Sample code if possible Thanks, Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: =C2=A0the leader in open source messaging and collaboration </blockquote> </blockquote> -- </div></div> =C2=A0 -- Howard Chu =C2=A0 CTO, Symas Corp. =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> =C2=A0 Director, Highland Sun =C2=A0 =C2=A0 <a href=3D"http://highlandsun.c= om/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a> =C2=A0 Chief Architect, OpenLDAP =C2=A0<a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> <div> </div>-- <b= r>Best regards, =C2=A0 =C2=A0=C2=A0 Roman </div></div> --f46d043c7d22cec95604e479b9f8--

1 0

(ITS#7669) tool_bind in common.c should be doing conditional assert
by k.venkata.kiran＠ericsson.com 21 Aug '13

21 Aug '13

Full_Name: Venkata Kiran K Version: 2.4.35 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.71.175.12) tool_bind has below assert which might be hit when nsctrls is not updated assert(nsctrls < (int) (sizeof(sctrls) / sizeof(sctrls[0])));

1 0

Re: (ITS#7667) performance degradation when using MDB_INTEGERKEY
by hyc＠symas.com 20 Aug '13

20 Aug '13

romange(a)gmail.com wrote: > --001a11c1e98008372804e46726c2 > Content-Type: text/plain; charset=UTF-8 > > Hi, I extracted a small dataset that shows the problem. > you can download it from here: > https://docs.google.com/file/d/0B6o29pwkWoERdnFSaUtMNDljemc/edit?usp=sharing > > I modified mdb_copy.c to demonstrate the difference. copy it to source dir > from here > https://docs.google.com/file/d/0B6o29pwkWoERd3VuUm1DN0FpcUU/edit?usp=sharing > > build and > run "time ./mdb_copy foo foo2" > after this change the flag at line 64 and run it again. > at my computer the difference is 17s vs 1.7s for 3 million items. This test doesn't prove the existence of a bug. You're running on a Little-Endian machine, therefore data that is in sorted order as a string is in hashed order when used as an integer. Your data insert turns into a worst-case insert order in this case, causing the worst possible random access strides through memory. Assuming the two orders to be equivalent is a pretty common mistake for DB programmers. Microsoft has done the same thing in ActiveDirectory, I mentioned it here a few years ago http://www.openldap.org/lists/openldap-devel/200711/msg00002.html If you had run this test on a Big-Endian machine, like SPARC, the insert order would be identical either way, and INTEGERKEY result would have been faster. Closing this ITS, no bug. > > > > On Tue, Aug 20, 2013 at 9:04 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > >> --On Sunday, August 18, 2013 11:46 AM +0000 romange(a)gmail.com wrote: >> >> Full_Name: Roman Gershman >>> Version: >>> OS: linux 3.8.0-25-generic >>> URL: >>> Submission from: (NULL) (212.150.97.210) >>> >> >> Please provide further information, specifically: >> >> The size of values >> Insert order >> Sample code if possible >> >> Thanks, >> Quanah >> >> >> -- >> >> Quanah Gibson-Mount >> Lead Engineer >> Zimbra, Inc >> -------------------- >> Zimbra :: the leader in open source messaging and collaboration >> > > > -- -- 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#7667) performance degradation when using MDB_INTEGERKEY
by romange＠gmail.com 20 Aug '13

20 Aug '13

--001a11c1e98008372804e46726c2 Content-Type: text/plain; charset=UTF-8 Hi, I extracted a small dataset that shows the problem. you can download it from here: https://docs.google.com/file/d/0B6o29pwkWoERdnFSaUtMNDljemc/edit?usp=sharing I modified mdb_copy.c to demonstrate the difference. copy it to source dir from here https://docs.google.com/file/d/0B6o29pwkWoERd3VuUm1DN0FpcUU/edit?usp=sharing build and run "time ./mdb_copy foo foo2" after this change the flag at line 64 and run it again. at my computer the difference is 17s vs 1.7s for 3 million items. On Tue, Aug 20, 2013 at 9:04 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Sunday, August 18, 2013 11:46 AM +0000 romange(a)gmail.com wrote: > > Full_Name: Roman Gershman >> Version: >> OS: linux 3.8.0-25-generic >> URL: >> Submission from: (NULL) (212.150.97.210) >> > > Please provide further information, specifically: > > The size of values > Insert order > Sample code if possible > > Thanks, > Quanah > > > -- > > Quanah Gibson-Mount > Lead Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > -- Best regards, Roman --001a11c1e98008372804e46726c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Hi, I extracted a small dataset that shows the proble= m.</div><div>you can download it from here: <a href=3D"https://docs.google.= com/file/d/0B6o29pwkWoERdnFSaUtMNDljemc/edit?usp=3Dsharing">https://docs.go= ogle.com/file/d/0B6o29pwkWoERdnFSaUtMNDljemc/edit?usp=3Dsharing</a></div> <div> </div><div>I modified mdb_copy.c to demonstrate the difference. co= py it to source dir from here <a href=3D"https://docs.google.com/file/d/0B6= o29pwkWoERd3VuUm1DN0FpcUU/edit?usp=3Dsharing">https://docs.google.com/file/= d/0B6o29pwkWoERd3VuUm1DN0FpcUU/edit?usp=3Dsharing</a></div> <div> </div><div>build and=C2=A0</div><div>run "time ./mdb_copy foo= foo2"</div><div>after this change the flag at line 64 and run it agai= n.</div><div>at my computer the difference is 17s vs 1.7s for 3 million ite= ms.</div> <div> </div></div><div class=3D"gmail_extra"> <div class=3D"gmail= _quote">On Tue, Aug 20, 2013 at 9:04 PM, Quanah Gibson-Mount <<a href=3D"mailto:quanah@zimbra.com" target=3D"_blank">quanah@zimbr= a.com</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">--On Sunday, August 18, <a href=3D"tel:2013"= value=3D"+9722013" target=3D"_blank">2013</a> 11:46 AM +0000 <a href=3D"ma= ilto:romange@gmail.com" target=3D"_blank">romange(a)gmail.com</a> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Roman Gershman Version: OS: linux 3.8.0-25-generic URL: Submission from: (NULL) (212.150.97.210) </blockquote> Please provide further information, specifically: The size of values Insert order Sample code if possible Thanks, Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: =C2=A0the leader in open source messaging and collaboration </blockquote></div> <div> </div>-- Best regards= , =C2=A0 =C2=A0=C2=A0 Roman </div> --001a11c1e98008372804e46726c2--

1 0

Re: (ITS#7667) performance degradation when using MDB_INTEGERKEY
by quanah＠zimbra.com 20 Aug '13

20 Aug '13

--On Sunday, August 18, 2013 11:46 AM +0000 romange(a)gmail.com wrote: > Full_Name: Roman Gershman > Version: > OS: linux 3.8.0-25-generic > URL: > Submission from: (NULL) (212.150.97.210) Please provide further information, specifically: The size of values Insert order Sample code if possible Thanks, Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7668) LMDB enhancement, corruption detection
by hyc＠OpenLDAP.org 20 Aug '13

20 Aug '13

Full_Name: Howard Chu Version: LMDB 0.9.7 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc Currently LMDB always stores two snapshots of the environment, one in each of the two meta pages. For ongoing operation it simply uses the one with the higher transaction number; the older one is ignored. If a power failure occurs at the instant that a transaction commit is occurring, it is possible for the meta page write to be corrupted in the storage device. Storage devices use ECC to detect (and sometimes recover from) these problems; if the error cannot be corrected then an attempt to read this sector will fail and the OS may tell the application that the read failed with an I/O error. In mdb_env_read_header() we currently attempt to read both header pages but completely fail the mdb_env_open() if an error occurs. Instead, we should always attempt to read both pages (assuming the file was not truncated, and both pages really were written before). If both pages exist but we only successfully read one, we should allow the env_open() to proceed in Read-Only mode, and return an error code to the caller indicating this situation. E.g., MDB_NEEDS_BACKUP. The point being, the user should use mdb_copy(1) to make a backup of the environment ASAP and should not be able to do anything else to the environment in the meantime. It's been suggested that LMDB should also use its own CRC on the meta page, to detect more subtle corruptions. We may consider adding this as well, but obviously this would be an on-disk format change. My personal view is this is what ECC DRAM is for. The primary argument for it is the possibility (again, during a power faiure) for the contents of the storage device's write buffer to be corrupted while writing to the meta page. I.e., ECC may have protected the data all the way from the host to the storage device, but if the device was in the middle of writing the sector when the power failure occurred, the write may have completed, but the buffer DRAM may have been losing charge while the write was happening. Again, I'm skeptical that corruptions of this sort would not be detected by the device's own ECC checks. While we're at it, it may be useful to include an env_open() flag explicitly requesting use of the older meta page. This flag would only be valid in conjunction with MDB_RDONLY. It would allow using mdb_copy to make a backup of the previous environment snapshot.

1 0

(ITS#7667) performance degradation when using MDB_INTEGERKEY
by romange＠gmail.com 18 Aug '13

18 Aug '13

Full_Name: Roman Gershman Version: OS: linux 3.8.0-25-generic URL: Submission from: (NULL) (212.150.97.210) The program writes into mdb database 100 million key,value pairs. All keys are 64bit integers. If we open the new database with mdb_dbi_open(txn, NULL, 0, &dbi); it has excellent performance - writes are done very quickly. However if we open it with "mdb_dbi_open(txn, NULL, MDB_INTEGERKEY, &dbi)" (and this is the only change in the code) its performance quickly deteriorates and after it writes several million items to the clean db the difference in write times becomes 2 orders of magnitude or even more compared to the previous setting. We used the source from git repository git://gitorious.org/mdb/mdb.git at commit id 214e9ed07d566307f22e16d0c1f1f57be9504a3b

1 0

Re: (ITS#7616) syncrepl enhancement: defer requests when refreshing
by hyc＠symas.com 14 Aug '13

14 Aug '13

hyc(a)symas.com wrote: > Michael Ströder wrote: >> hyc(a)symas.com wrote: >>> I was considering returning LDAP_BUSY for this case, but it may make more >>> sense to return a REFERRAL to the provider instead. (Although again, if we >>> have two MMR servers pointed at each other starting at the same time, they >>> would just refer to each other and clients would get nowhere until one of them >>> finishes its refresh.) >> >> IMO referrals are harmful. >> Just returning LDAP_BUSY seems best to me because if reliable HA is really >> important for a deployment you have decent load-balancers in front of your >> LDAP server which should do a proper health-check. > > Agreed. > >> Just a question: Is this database-specific? Maybe only one of several DBs is >> in this initial syncrepl phase and access to others should simply work. > > Overlays are db-specific. > A similar feature was already implemented, and never documented: commit 9e00b6cc6ce2857490b33218bdaf1339319c5f60 Author: Howard Chu <hyc(a)openldap.org> Date: Fri Apr 15 11:13:38 2011 -0700 Add strictrefresh syncrepl option Only affects delta-syncrepl - stop listening to clients while refresh is running. This is a bit more extreme though, it terminates all client connections and suspends the slapd listeners while a refresh is running. The solution discussed in this ITS would be preferable. -- -- 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#7666) segfault when searching regex minus than 3 characters over translucent
by theju3434＠gmail.com 14 Aug '13

14 Aug '13

--047d7b86f532b361c704e3e79cfd Content-Type: text/plain; charset=ISO-8859-1 Sorry, Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffb164d700 (LWP 18682)] 0x00007ffff678d0bc in ?? () from /lib/libc.so.6 (gdb) bt full #0 0x00007ffff678d0bc in ?? () from /lib/libc.so.6 No symbol table info available. #1 0x00000000005720a1 in avl_find (root=0xd13ea0, data=0x7fffb14cb0a0, fcmp=0x4da000 <bdb_rdn_cmp>) at avl.c:545 cmp = <value optimized out> #2 0x00000000004dae90 in bdb_cache_find_ndn (op=<value optimized out>, txn=<value optimized out>, ndn=0xb3cda0, res=0x7fffb164b5e8) at cache.c:443 bdb = 0x97bf20 ei = {bei_parent = 0x97bfa0, bei_id = 140736167981340, bei_lockpad = -20208, bei_state = -20148, bei_finders = 32767, bei_nrdn = {bv_len = 23, bv_val = 0x1b <Address 0x1b out of bounds>}, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = {__data = {__lock = 270, __count = 0, __owner = 16, __nusers = 0, __kind = -1320374016, __spins = 32767, __list = {__prev = 0x7fffb14cb102, __next = 0x0}}, __size = "\016\001\000\000\000\000\000\000\020\000\000\000\000\000\000\000\000\261L\261\377\177\000\000\002\261L\261\377\177\000\000\000\000\000\000\000\000\000", __align = 270}, bei_lrunext = 0x633d646975330000, bei_lruprev = 0x69622e657269616c} eip = 0x97bfa0 ei2 = 0xa5eda0 rc = <value optimized out> ptr = 0x1b <Address 0x1b out of bounds> #3 0x00000000004db460 in bdb_cache_find_id (op=0xa652f0, tid=<value optimized out>, id=<value optimized out>, eip=0x7fffb164b5e8, flag=2, lock=0x7fffb164b570) at cache.c:923 bdb = 0x97bf20 ep = 0xb3cd88 rc = <value optimized out> load = <value optimized out> ei = {bei_parent = 0x0, bei_id = 1331, bei_lockpad = 0, bei_state = 0, bei_finders = 0, bei_nrdn = {bv_len = 0, bv_val = 0x0}, bei_e = 0x0, bei_kids = 0x0, bei_kids_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, bei_lrunext = 0x0, bei_lruprev = 0x0} #4 0x000000000049b274 in bdb_search (op=0xa652f0, rs=0x7fffb164ca40) at search.c:737 scopeok = <value optimized out> bdb = 0x97bf20 id = <value optimized out> cursor = 1331 lastid = 18446744073709551615 candidates = {18446744073709551615, 1, 1358, 96, 130, 225, 243, 267, 305, 325, 402, 420, 430, 464, 494, 518, 585, 606, 683, 762, 774, 854, 904, 1006, 1010, 0 <repeats 131047 times>} scopes = {0 <repeats 64885 times>, 112, 0, 140737330949800, 0, 96, 30064771072, 140737330949744, 144, 30064771072, 0, 96, 140737330949696, 96, 140736169549664, 140736169549856, 18678, 140737327905904, 0, 96, 140736169554240, 140736169554064, 140736169549664, 140737328407145, 8589950976, 33022, 4857321309812969474, 140736169549712, 0, 0, 4295000064, 0, 72057594037927936, 140736169549760, 0, 140737328406892, 8589940736, 0, 10485842016695418880, 140736169549808, 0, 0, 4294969344, 0, 72058143793676288, 0, 0, 140737328406892, 562962838323220, 80222775637897, 4294967296, 65556, 0, 1688935776387072, 18446744073709551615, 2044404433372, 563035852767296, 80222775637897, 12842975242, 141828410114068, 18398981297188896768, 1688936890543102, 18446744073709551615, 2065879269857, 0 <repeats 265 times>, 140737346106200, 0, 0, 24, 140737346106200, 140736169552160, 0, 24, 140736169552272, 140736169552192, 0, 0, 0, 2050, 17, 1, 5909838, 0, 13733440, 17, 5910105, 0 <repeats 33 times>, 5709985, 140736169555760, 140736169560672, 140736169555920, 4603268, 12663952, 4597084, 0 <repeats 19 times>, 5709985, 140736169555968, 140736169560672, 140736169556192, 4603268, 140736169556112, 4597084, 140736169556144, 4603268, 140736169556120, 4597084, 0, 5709985, 140736169556064, 140736169556224, 12663576, 4603268, 140736169556232, 4597084, 0, 1, 5949064, 5949064, 0, 0, 0, 0, 140736169554320, 0, 5949054, 0, 140736169554752, 140736169554736, 7, 140736169555104, 140736169554752, 140737327689241, 140736169553280, 1, 6046159, 6046159, 140736169554416, 18446744073709551615, 12664240, 140736169554280, 140736169554464, 0, 6046156, 0, 140736169554896, 140736169554880, 3, 140736169555248, 140736169554896, 140737327689241, 140736169553424, 2, 5948970, 5948970, 140733193388032, 18446744069414584320, 115, 140736169554424, 140736169554608, 0, 5948966, 0, 0, 140736169554716...} e = 0xb3cd88 base = {e_id = 1, e_name = {bv_len = 140736169554992, bv_val = 0xa64a9a ""}, e_nname = {bv_len = 23, bv_val = 0xd18db0 "ou=people,dc=c,dc=fr"}, e_attrs = 0x7ffff69e2e40, e_ocflags = 0, e_bv = {bv_len = 10898074, bv_val = 0xa64aa0 ""}, e_private = 0xa659c0} e_root = <value optimized out> matched = 0x0 ei = 0x0 realbase = {bv_len = 23, bv_val = 0xd18db0 "ou=people,dc=c,dc=fr"} mask = <value optimized out> manageDSAit = <value optimized out> tentries = 1358 nentries = <value optimized out> idflag = 2 lock = {off = 0, ndx = 270, gen = 248, mode = DB_LOCK_READ} opinfo = 0x0 ltid = 0xa658b0 oex = <value optimized out> #5 0x0000000000489077 in overlay_op_walk (op=0xa652f0, rs=0x7fffb164ca40, which=<value optimized out>, oi=0x9b99a0, on=0x0) at backover.c:671 rc = 32768 #6 0x000000000055f546 in translucent_search (op=0xa652f0, rs=0x7fffb164ca40) at translucent.c:1122 on = 0x9b9b80 ov = 0x9b9d60 cb = {sc_next = 0x7fffb164b930, sc_response = 0x55f680 <translucent_search_cb>, sc_cleanup = 0, sc_private = 0x7fffb164b6c0} tc = {db = 0x7fffb164b7a0, on = 0x9b9b80, orig = 0xc13ce8, list = 0x0, step = 1, slimit = 500000, attrs = 0x0} fl = 0xc13da0 fr = 0x0 rc = 0 #7 0x0000000000488f8a in overlay_op_walk (op=0xa652f0, rs=0x7fffb164ca40, which=<value optimized out>, oi=0x9b99a0, on=0x9b9b80) at backover.c:661 rc = -1318794336 #8 0x0000000000489a57 in over_op_func (op=0xa652f0, rs=0x1b, which=23) at backover.c:723 oi = 0x48fa on = 0x97bfd8 be = 0x97bd80 db = {bd_info = 0x844bc0, bd_self = 0x97bd80, be_ctrls = "\000\000\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 15 times>, "\001", be_flags = 2315, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x97d380, be_nsuffix = 0x97d4b0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 32, bv_val = 0x97d5c0 "cn=admin,ou=People,dc=c,dc=fr"}, be_rootndn = {bv_len = 32, bv_val = 0x97d610 "cn=admin,ou=people,dc=c,dc=fr"}, be_rootpw = {bv_len = 9, bv_val = 0x97d460 "password"}, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500000, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x9bc820, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0xa5b830, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x849580, be_private = 0x97bf20, be_next = {stqe_next = 0x9bd7c0}} cb = {sc_next = 0x0, sc_response = 0x488d00 <over_back_response>, sc_cleanup = 0, sc_private = 0x9b99a0} sc = <value optimized out> rc = 27 __PRETTY_FUNCTION__ = "over_op_func" #9 0x0000000000424151 in fe_op_search (op=0xa652f0, rs=0x7fffb164ca40) at search.c:402 bd = 0x851ca0 #10 0x000000000042497c in do_search (op=0xa652f0, rs=0x7fffb164ca40) at search.c:247 base = {bv_len = 23, bv_val = 0xd1bef7 "ou=People,dc=c,dc=fr"} siz = 0 i = 140736169560992 #11 0x0000000000421eb9 in connection_operation (ctx=0x7fffb164cba0, arg_v=<value optimized out>) at connection.c:1155 rc = <value optimized out> cancel = <value optimized out> op = 0xa652f0 rs = {sr_type = REP_SEARCH, sr_tag = 0, sr_msgid = 0, sr_err = 5, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 4, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = 0x7ffff7f3fed0 memctx = 0xa64b10 memctx_null = 0x0 __PRETTY_FUNCTION__ = "connection_operation" #12 0x00000000004226a5 in connection_read_thread (ctx=<value optimized out>, argv=<value optimized out>) at connection.c:1291 s = 17 #13 0x0000000000576780 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:688 pool = 0x9259b0 task = 0xa63430 work_list = <value optimized out> ctx = {ltu_id = 140736169563904, ltu_key = {{ltk_key = 0x420bb0, ltk_data = 0xa65740, ltk_free = 0x420c80 <conn_counter_destroy>}, {ltk_key = 0x474e80, ltk_data = 0xa64b10, ltk_free = 0x474ea0 <slap_sl_mem_destroy>}, {ltk_key = 0x435150, ltk_data = 0x0, ltk_free = 0x434f30 <slap_op_q_destroy>}, {ltk_key = 0xa5b850, ltk_data = 0xa658b0, ltk_free = 0x4d9810 <bdb_reader_free>}, {ltk_key = 0x499860, ltk_data = 0x7fffafe4c010, ltk_free = 0x499930 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>, {ltk_key = 0x0, ltk_data = 0x7ffff7850927, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} kctx = <value optimized out> keyslot = 74 hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #14 0x00007ffff784f8ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #15 0x00007ffff6754b6d in clone () from /lib/libc.so.6 No symbol table info available. #16 0x0000000000000000 in ?? () No symbol table info available. Thank you Ju --047d7b86f532b361c704e3e79cfd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div>Sorry, Program received signal SIGSEGV, S= egmentation fault. [Switching to Thread 0x7fffb164d700 (LWP 18682)] 0= x00007ffff678d0bc in ?? () from /lib/libc.so.6 (gdb)=A0 bt full #0=A0= 0x00007ffff678d0bc in ?? () from /lib/libc.so.6 No symbol table info available. #1=A0 0x00000000005720a1 in avl_find (ro= ot=3D0xd13ea0, data=3D0x7fffb14cb0a0, fcmp=3D0x4da000 <bdb_rdn_cmp>) = at avl.c:545 =A0=A0=A0=A0=A0=A0=A0 cmp =3D <value optimized out><b= r>#2=A0 0x00000000004dae90 in bdb_cache_find_ndn (op=3D<value optimized = out>, txn=3D<value optimized out>, ndn=3D0xb3cda0, res=3D0x7fffb16= 4b5e8) at cache.c:443 =A0=A0=A0=A0=A0=A0=A0 bdb =3D 0x97bf20 =A0=A0=A0=A0=A0=A0=A0 ei =3D {bei= _parent =3D 0x97bfa0, bei_id =3D 140736167981340, bei_lockpad =3D -20208, b= ei_state =3D -20148, bei_finders =3D 32767, bei_nrdn =3D {bv_len =3D 23, <b= r>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 bv_val =3D 0x1b <Address 0x1b out of= bounds>}, bei_e =3D 0x0, bei_kids =3D 0x0, bei_kids_mutex =3D {__data = =3D {__lock =3D 270, __count =3D 0, __owner =3D 16, __nusers =3D 0, =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 __kind =3D -1320374016, __spins =3D= 32767, __list =3D {__prev =3D 0x7fffb14cb102, __next =3D 0x0}}, =A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 __size =3D "\016\001\000\000\000\000\000\0= 00\020\000\000\000\000\000\000\000\000\261L\261\377\177\000\000\002\261L\26= 1\377\177\000\000\000\000\000\000\000\000\000", =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 __align =3D 270}, bei_lrunext =3D 0x633d6= 46975330000, bei_lruprev =3D 0x69622e657269616c} =A0=A0=A0=A0=A0=A0=A0 e= ip =3D 0x97bfa0 =A0=A0=A0=A0=A0=A0=A0 ei2 =3D 0xa5eda0 =A0=A0=A0=A0= =A0=A0=A0 rc =3D <value optimized out> =A0=A0=A0=A0=A0=A0=A0 ptr = =3D 0x1b <Address 0x1b out of bounds> #3=A0 0x00000000004db460 in bdb_cache_find_id (op=3D0xa652f0, tid=3D<val= ue optimized out>, id=3D<value optimized out>, eip=3D0x7fffb164b5e= 8, flag=3D2, lock=3D0x7fffb164b570) at cache.c:923 =A0=A0=A0=A0=A0=A0=A0= bdb =3D 0x97bf20 =A0=A0=A0=A0=A0=A0=A0 ep =3D 0xb3cd88 =A0=A0=A0=A0=A0=A0=A0 rc =3D <value optimized out> =A0=A0=A0=A0=A0= =A0=A0 load =3D <value optimized out> =A0=A0=A0=A0=A0=A0=A0 ei =3D= {bei_parent =3D 0x0, bei_id =3D 1331, bei_lockpad =3D 0, bei_state =3D 0, = bei_finders =3D 0, bei_nrdn =3D {bv_len =3D 0, bv_val =3D 0x0}, bei_e =3D 0= x0, bei_kids =3D 0x0, bei_kids_mutex =3D { =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 __data =3D {__lock =3D 0, __count =3D 0, = __owner =3D 0, __nusers =3D 0, __kind =3D 0, __spins =3D 0, __list =3D {__p= rev =3D 0x0, __next =3D 0x0}}, __size =3D '\000' <repeats 39 tim= es>, =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 __align =3D 0}, bei_lrunext = =3D 0x0, bei_lruprev =3D 0x0} #4=A0 0x000000000049b274 in bdb_search (op=3D0xa652f0, rs=3D0x7fffb164ca40)= at search.c:737 =A0=A0=A0=A0=A0=A0=A0 scopeok =3D <value optimized o= ut> =A0=A0=A0=A0=A0=A0=A0 bdb =3D 0x97bf20 =A0=A0=A0=A0=A0=A0=A0 i= d =3D <value optimized out> =A0=A0=A0=A0=A0=A0=A0 cursor =3D 1331<= br> =A0=A0=A0=A0=A0=A0=A0 lastid =3D 18446744073709551615 =A0=A0=A0=A0=A0=A0= =A0 candidates =3D {18446744073709551615, 1, 1358, 96, 130, 225, 243, 267, = 305, 325, 402, 420, 430, 464, 494, 518, 585, 606, 683, 762, 774, 854, 904, = 1006, 1010, =A0=A0=A0=A0=A0=A0=A0=A0=A0 0 <repeats 131047 times>}= =A0=A0=A0=A0=A0=A0=A0 scopes =3D {0 <repeats 64885 times>, 112, 0, 14= 0737330949800, 0, 96, 30064771072, 140737330949744, 144, 30064771072, 0, 96= , 140737330949696, 96, 140736169549664, =A0=A0=A0=A0=A0=A0=A0=A0=A0 140= 736169549856, 18678, 140737327905904, 0, 96, 140736169554240, 1407361695540= 64, 140736169549664, 140737328407145, 8589950976, 33022, 485732130981296947= 4, 140736169549712, =A0=A0=A0=A0=A0=A0=A0=A0=A0 0, 0, 4295000064, 0, 72057594037927936, 1407361= 69549760, 0, 140737328406892, 8589940736, 0, 10485842016695418880, 14073616= 9549808, 0, 0, 4294969344, 0, 72058143793676288, =A0=A0=A0=A0=A0=A0=A0= =A0=A0 0, 0, 140737328406892, 562962838323220, 80222775637897, 4294967296, = 65556, 0, 1688935776387072, 18446744073709551615, 2044404433372, 5630358527= 67296, 80222775637897, =A0=A0=A0=A0=A0=A0=A0=A0=A0 12842975242, 141828410114068, 18398981297188896= 768, 1688936890543102, 18446744073709551615, 2065879269857, 0 <repeats 2= 65 times>, 140737346106200, 0, 0, 24, =A0=A0=A0=A0=A0=A0=A0=A0=A0 14= 0737346106200, 140736169552160, 0, 24, 140736169552272, 140736169552192, 0,= 0, 0, 2050, 17, 1, 5909838, 0, 13733440, 17, 5910105, 0 <repeats 33 tim= es>, 5709985, =A0=A0=A0=A0=A0=A0=A0=A0=A0 140736169555760, 140736169560672, 1407361695559= 20, 4603268, 12663952, 4597084, 0 <repeats 19 times>, 5709985, 140736= 169555968, 140736169560672, 140736169556192, 4603268, =A0=A0=A0=A0=A0= =A0=A0=A0=A0 140736169556112, 4597084, 140736169556144, 4603268, 1407361695= 56120, 4597084, 0, 5709985, 140736169556064, 140736169556224, 12663576, 460= 3268, 140736169556232, 4597084, 0, =A0=A0=A0=A0=A0=A0=A0=A0=A0 1, 5949064, 5949064, 0, 0, 0, 0, 14073616955432= 0, 0, 5949054, 0, 140736169554752, 140736169554736, 7, 140736169555104, 140= 736169554752, 140737327689241, 140736169553280, 1, =A0=A0=A0=A0=A0=A0= =A0=A0=A0 6046159, 6046159, 140736169554416, 18446744073709551615, 12664240= , 140736169554280, 140736169554464, 0, 6046156, 0, 140736169554896, 1407361= 69554880, 3, 140736169555248, =A0=A0=A0=A0=A0=A0=A0=A0=A0 140736169554896, 140737327689241, 1407361695534= 24, 2, 5948970, 5948970, 140733193388032, 18446744069414584320, 115, 140736= 169554424, 140736169554608, 0, 5948966, 0, 0, =A0=A0=A0=A0=A0=A0=A0=A0= =A0 140736169554716...} =A0=A0=A0=A0=A0=A0=A0 e =3D 0xb3cd88 =A0=A0=A0=A0=A0=A0=A0 base =3D {e_id =3D 1, e_name =3D {bv_len =3D 14073616= 9554992, bv_val =3D 0xa64a9a ""}, e_nname =3D {bv_len =3D 23, bv_= val =3D 0xd18db0 "ou=3Dpeople,dc=3Dc,dc=3Dfr"}, e_attrs =3D 0x7ff= ff69e2e40, =A0=A0=A0=A0=A0=A0=A0=A0=A0 e_ocflags =3D 0, e_bv =3D {bv_le= n =3D 10898074, bv_val =3D 0xa64aa0 ""}, e_private =3D 0xa659c0}<= br> =A0=A0=A0=A0=A0=A0=A0 e_root =3D <value optimized out> =A0=A0=A0= =A0=A0=A0=A0 matched =3D 0x0 =A0=A0=A0=A0=A0=A0=A0 ei =3D 0x0 =A0=A0= =A0=A0=A0=A0=A0 realbase =3D {bv_len =3D 23, bv_val =3D 0xd18db0 "ou= =3Dpeople,dc=3Dc,dc=3Dfr"} =A0=A0=A0=A0=A0=A0=A0 mask =3D <value= optimized out> =A0=A0=A0=A0=A0=A0=A0 manageDSAit =3D <value optimized out> =A0=A0= =A0=A0=A0=A0=A0 tentries =3D 1358 =A0=A0=A0=A0=A0=A0=A0 nentries =3D &lt= ;value optimized out> =A0=A0=A0=A0=A0=A0=A0 idflag =3D 2 =A0=A0=A0= =A0=A0=A0=A0 lock =3D {off =3D 0, ndx =3D 270, gen =3D 248, mode =3D DB_LOC= K_READ} =A0=A0=A0=A0=A0=A0=A0 opinfo =3D 0x0 =A0=A0=A0=A0=A0=A0=A0 ltid =3D 0xa6= 58b0 =A0=A0=A0=A0=A0=A0=A0 oex =3D <value optimized out> #5=A0 = 0x0000000000489077 in overlay_op_walk (op=3D0xa652f0, rs=3D0x7fffb164ca40, = which=3D<value optimized out>, oi=3D0x9b99a0, on=3D0x0) at backover.c= :671 =A0=A0=A0=A0=A0=A0=A0 rc =3D 32768 #6=A0 0x000000000055f546 in transluce= nt_search (op=3D0xa652f0, rs=3D0x7fffb164ca40) at translucent.c:1122 =A0= =A0=A0=A0=A0=A0=A0 on =3D 0x9b9b80 =A0=A0=A0=A0=A0=A0=A0 ov =3D 0x9b9d60= =A0=A0=A0=A0=A0=A0=A0 cb =3D {sc_next =3D 0x7fffb164b930, sc_response = =3D 0x55f680 <translucent_search_cb>, sc_cleanup =3D 0, sc_private = =3D 0x7fffb164b6c0} =A0=A0=A0=A0=A0=A0=A0 tc =3D {db =3D 0x7fffb164b7a0, on =3D 0x9b9b80, orig = =3D 0xc13ce8, list =3D 0x0, step =3D 1, slimit =3D 500000, attrs =3D 0x0}<b= r>=A0=A0=A0=A0=A0=A0=A0 fl =3D 0xc13da0 =A0=A0=A0=A0=A0=A0=A0 fr =3D 0x0= =A0=A0=A0=A0=A0=A0=A0 rc =3D 0 #7=A0 0x0000000000488f8a in overlay_o= p_walk (op=3D0xa652f0, rs=3D0x7fffb164ca40, which=3D<value optimized out= >, oi=3D0x9b99a0, on=3D0x9b9b80) at backover.c:661 =A0=A0=A0=A0=A0=A0=A0 rc =3D -1318794336 #8=A0 0x0000000000489a57 in ove= r_op_func (op=3D0xa652f0, rs=3D0x1b, which=3D23) at backover.c:723 =A0= =A0=A0=A0=A0=A0=A0 oi =3D 0x48fa =A0=A0=A0=A0=A0=A0=A0 on =3D 0x97bfd8<b= r>=A0=A0=A0=A0=A0=A0=A0 be =3D 0x97bd80 =A0=A0=A0=A0=A0=A0=A0 db =3D {bd= _info =3D 0x844bc0, bd_self =3D 0x97bd80, be_ctrls =3D "\000\000\000\0= 01\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000&#39= ; <repeats 15 times>, "\001", =A0=A0=A0=A0=A0=A0=A0=A0=A0 be_flags =3D 2315, be_restrictops =3D 0, be_req= uires =3D 0, be_ssf_set =3D {sss_ssf =3D 0, sss_transport =3D 0, sss_tls = =3D 0, sss_sasl =3D 0, sss_update_ssf =3D 0, sss_update_transport =3D 0, <b= r>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 sss_update_tls =3D 0, sss_update_sasl = =3D 0, sss_simple_bind =3D 0}, be_suffix =3D 0x97d380, be_nsuffix =3D 0x97d= 4b0, be_schemadn =3D {bv_len =3D 0, bv_val =3D 0x0}, be_schemandn =3D { =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 bv_len =3D 0, bv_val =3D 0x0}, be_rootdn = =3D {bv_len =3D 32, bv_val =3D 0x97d5c0 "cn=3Dadmin,ou=3DPeople,dc=3Dc= ,dc=3Dfr"}, be_rootndn =3D {bv_len =3D 32, =A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 bv_val =3D 0x97d610 "cn=3Dadmin,ou=3Dpeople,dc=3Dc,dc=3Df= r"}, be_rootpw =3D {bv_len =3D 9, bv_val =3D 0x97d460 "password&q= uot;}, be_max_deref_depth =3D 15, be_def_limit =3D { =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 lms_t_soft =3D 3600, lms_t_hard =3D 0, lm= s_s_soft =3D 500000, lms_s_hard =3D 0, lms_s_unchecked =3D -1, lms_s_pr =3D= 0, lms_s_pr_hide =3D 0, lms_s_pr_total =3D 0}, be_limits =3D 0x0, =A0= =A0=A0=A0=A0=A0=A0=A0=A0 be_acl =3D 0x9bc820, be_dfltaccess =3D ACL_READ, b= e_extra_anlist =3D 0x0, be_update_ndn =3D {bv_len =3D 0, bv_val =3D 0x0}, b= e_update_refs =3D 0x0, be_pending_csn_list =3D 0xa5b830, =A0=A0=A0=A0=A0=A0=A0=A0=A0 be_pcl_mutex =3D {__data =3D {__lock =3D 0, __c= ount =3D 0, __owner =3D 0, __nusers =3D 0, __kind =3D 0, __spins =3D 0, __l= ist =3D {__prev =3D 0x0, __next =3D 0x0}}, =A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 __size =3D '\000' <repeats 39 times>, __align =3D 0}, = be_syncinfo =3D 0x0, be_pb =3D 0x0, be_cf_ocs =3D 0x849580, be_private =3D = 0x97bf20, be_next =3D {stqe_next =3D 0x9bd7c0}} =A0=A0=A0=A0=A0=A0=A0 cb =3D {sc_next =3D 0x0, sc_response =3D 0x488d00 &lt= ;over_back_response>, sc_cleanup =3D 0, sc_private =3D 0x9b99a0} =A0= =A0=A0=A0=A0=A0=A0 sc =3D <value optimized out> =A0=A0=A0=A0=A0=A0= =A0 rc =3D 27 =A0=A0=A0=A0=A0=A0=A0 __PRETTY_FUNCTION__ =3D "over_o= p_func" #9=A0 0x0000000000424151 in fe_op_search (op=3D0xa652f0, rs=3D0x7fffb164ca4= 0) at search.c:402 =A0=A0=A0=A0=A0=A0=A0 bd =3D 0x851ca0 #10 0x000000= 000042497c in do_search (op=3D0xa652f0, rs=3D0x7fffb164ca40) at search.c:24= 7 =A0=A0=A0=A0=A0=A0=A0 base =3D {bv_len =3D 23, bv_val =3D 0xd1bef7 &qu= ot;ou=3DPeople,dc=3Dc,dc=3Dfr"} =A0=A0=A0=A0=A0=A0=A0 siz =3D 0 =A0=A0=A0=A0=A0=A0=A0 i =3D 140736169560= 992 #11 0x0000000000421eb9 in connection_operation (ctx=3D0x7fffb164cba0= , arg_v=3D<value optimized out>) at connection.c:1155 =A0=A0=A0=A0= =A0=A0=A0 rc =3D <value optimized out> =A0=A0=A0=A0=A0=A0=A0 cancel =3D <value optimized out> =A0=A0=A0= =A0=A0=A0=A0 op =3D 0xa652f0 =A0=A0=A0=A0=A0=A0=A0 rs =3D {sr_type =3D R= EP_SEARCH, sr_tag =3D 0, sr_msgid =3D 0, sr_err =3D 5, sr_matched =3D 0x0, = sr_text =3D 0x0, sr_ref =3D 0x0, sr_ctrls =3D 0x0, sr_un =3D {sru_search = =3D {r_entry =3D 0x0, =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 r_attr_flags =3D 0, r_operational_a= ttrs =3D 0x0, r_attrs =3D 0x0, r_nentries =3D 4, r_v2ref =3D 0x0}, sru_sasl= =3D {r_sasldata =3D 0x0}, sru_extended =3D {r_rspoid =3D 0x0, =A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 r_rspdata =3D 0x0}}, sr_flags =3D 0} =A0=A0=A0=A0=A0=A0=A0 tag =3D 99 =A0=A0=A0=A0=A0=A0=A0 opidx =3D SLAP_OP= _SEARCH =A0=A0=A0=A0=A0=A0=A0 conn =3D 0x7ffff7f3fed0 =A0=A0=A0=A0=A0= =A0=A0 memctx =3D 0xa64b10 =A0=A0=A0=A0=A0=A0=A0 memctx_null =3D 0x0 = =A0=A0=A0=A0=A0=A0=A0 __PRETTY_FUNCTION__ =3D "connection_operation&qu= ot; #12 0x00000000004226a5 in connection_read_thread (ctx=3D<value op= timized out>, argv=3D<value optimized out>) at connection.c:1291<b= r> =A0=A0=A0=A0=A0=A0=A0 s =3D 17 #13 0x0000000000576780 in ldap_int_thread= _pool_wrapper (xpool=3D<value optimized out>) at tpool.c:688 =A0= =A0=A0=A0=A0=A0=A0 pool =3D 0x9259b0 =A0=A0=A0=A0=A0=A0=A0 task =3D 0xa6= 3430 =A0=A0=A0=A0=A0=A0=A0 work_list =3D <value optimized out> =A0=A0=A0=A0=A0=A0=A0 ctx =3D {ltu_id =3D 140736169563904, ltu_key =3D {{lt= k_key =3D 0x420bb0, ltk_data =3D 0xa65740, ltk_free =3D 0x420c80 <conn_c= ounter_destroy>}, {ltk_key =3D 0x474e80, ltk_data =3D 0xa64b10, =A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ltk_free =3D 0x474ea0 <slap_sl_mem_= destroy>}, {ltk_key =3D 0x435150, ltk_data =3D 0x0, ltk_free =3D 0x434f3= 0 <slap_op_q_destroy>}, {ltk_key =3D 0xa5b850, ltk_data =3D 0xa658b0,= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ltk_free =3D 0x4d9810 <bdb_reade= r_free>}, {ltk_key =3D 0x499860, ltk_data =3D 0x7fffafe4c010, ltk_free = =3D 0x499930 <search_stack_free>}, {ltk_key =3D 0x0, ltk_data =3D 0x0= , =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ltk_free =3D 0} <repeats 2= 4 times>, {ltk_key =3D 0x0, ltk_data =3D 0x7ffff7850927, ltk_free =3D 0}= , {ltk_key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D 0}, {ltk_key =3D 0x0, <b= r> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ltk_data =3D 0x0, ltk_free =3D 0}}}= =A0=A0=A0=A0=A0=A0=A0 kctx =3D <value optimized out> =A0=A0=A0= =A0=A0=A0=A0 keyslot =3D 74 =A0=A0=A0=A0=A0=A0=A0 hash =3D <value opt= imized out> =A0=A0=A0=A0=A0=A0=A0 __PRETTY_FUNCTION__ =3D "ldap_= int_thread_pool_wrapper" #14 0x00007ffff784f8ca in start_thread () from /lib/libpthread.so.0 No s= ymbol table info available. #15 0x00007ffff6754b6d in clone () from /lib= /libc.so.6 No symbol table info available. #16 0x0000000000000000 in = ?? () No symbol table info available. </div>Thank you </div>Ju <= /div> --047d7b86f532b361c704e3e79cfd--

1 0

Re: (ITS#7666) segfault when searching regex minus than 3 characters over translucent
by theju3434＠gmail.com 14 Aug '13

14 Aug '13

--001a11339f3813188a04e3e76889 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable # schema.perso/c.schema attributetype ( 1.3.6.1.4.1.10000.13.2.20 NAME 'Application' DESC 'Acces sur les application' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) objectclass ( 1.3.6.1.4.1.10013.2.2.1.0.0 NAME 'cPerson' SUP 'inetOrgPerson' STRUCTURAL MUST ( uid ) MAY ( Application) ) #slapd.conf include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema.perso/c.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel 2 allow bind_v2 # The maximum number of entries that is returned for a search operation sizelimit 500000 # The tool-threads parameter sets the actual amount of cpu's that is used # for indexing. tool-threads 1 database bdb # The base of your directory in database #1 suffix "ou=3DPeople,dc=3Dc,dc=3Dfr" # rootdn directive for specifying a superuser on the database. This is needed # for syncrepl. rootdn "cn=3Dadmin,ou=3DPeople,dc=3Dc,dc=3Dfr" rootpw "password" # Where the database file are physically stored for database #1 directory "/var/lib/ldap-people" dbconfig set_cachesize 0 536870912 0 dbconfig set_flags DB_LOG_AUTOREMOVE dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uid eq,pres index Application eq,pres,sub overlay translucent # on demande que les resultats des 2 annuaires soient merg=E9s translucent_no_glue off translucent_strict off #liste des attribut a chercher sur l'overlay translucent_local Application #liste des attributs a chercher sur le master translucent_remote sn,GivenName,mail,street,Postalcode,l,uid,facsimileTelephoneNumber #activation du bind local translucent_bind_local on # activation de la possibilit=E9 de changer le mot de passe translucent_pwmod_local on uri ldap://ldapr.c.fr lastmod off acl-bind binddn=3D"cn=3Dadmin,ou=3DPeople,dc=3Dc,dc=3Dfr" credentials=3D"password" access to attrs=3DuserPassword,shadowLastChange by dn=3D"cn=3Dadmin,ou=3DPeople,dc=3Dc,dc=3Dfr" write by anonymous auth by self write by * none access to dn.base=3D"" by * read Ex user : dn: uid=3Dw.k.1,ou=3Dc,ou=3DPeople,dc=3Dc,dc=3Dfr displayName: K W givenName: W postalCode: 44095 objectClass: cPerson uid: w.k.1 mail: w.k(a)mail.fr cn: K W telephoneNumber: 06 06 06 06 06 o: C l: MON sn: KNAP Application: contrat:ABC221:082534 2013/8/14 Howard Chu <hyc(a)symas.com> > theju3434(a)gmail.com wrote: > >> --047d7b34397049627604e3e73688 >> Content-Type: text/plain; charset=3DISO-8859-1 >> >> >> Here is the stack: >> >> >> gdb slapd >> GNU gdb (GDB) 7.0.1-debian >> Copyright (C) 2009 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.= * >> *html <http://gnu.org/licenses/gpl.html> >> >>> >>> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copyin= g" >> and "show warranty" for details. >> This GDB was configured as "x86_64-linux-gnu". >> For bug reporting instructions, please see: >> <http://www.gnu.org/software/**gdb/bugs/<http://www.gnu.org/software/gdb= /bugs/> >> >... >> Reading symbols from /usr/sbin/slapd...(no debugging symbols >> found)...done. >> > > This trace is useless since it doesn't have any symbols. Please reread th= e > FAQ article in my previous reply. > > -- > -- 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://ww= w.openldap.org/project/> > --001a11339f3813188a04e3e76889 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"># schema.perso/c.schema attributetype ( 1.3.6.1.4.1= .10000.13.2.20 =A0=A0=A0=A0=A0=A0=A0 NAME 'Application' =A0= =A0=A0=A0=A0=A0=A0 DESC 'Acces sur les application' =A0=A0=A0=A0= =A0=A0=A0 EQUALITY caseIgnoreMatch =A0=A0=A0=A0=A0=A0=A0 SUBSTR caseIgno= reSubstringsMatch =A0=A0=A0=A0=A0=A0=A0 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) objectc= lass (=A0 1.3.6.1.4.1.10013.2.2.1.0.0 =A0=A0=A0=A0=A0=A0=A0 NAME 'cP= erson' =A0=A0=A0=A0=A0=A0=A0 SUP 'inetOrgPerson' =A0=A0= =A0=A0=A0=A0=A0 STRUCTURAL =A0=A0=A0=A0=A0=A0=A0 MUST (=A0 uid ) =A0= =A0=A0=A0=A0=A0=A0 MAY ( Application) ) #slapd.conf include=A0=A0=A0=A0=A0=A0=A0=A0 /etc/openlda= p/schema/core.schema include=A0=A0=A0=A0=A0=A0=A0=A0 /etc/openldap/schem= a/cosine.schema include=A0=A0=A0=A0=A0=A0=A0=A0 /etc/openldap/schema/nis= .schema include=A0=A0=A0=A0=A0=A0=A0=A0 /etc/openldap/schema/inetorgpers= on.schema include=A0=A0=A0=A0=A0=A0=A0=A0 /etc/openldap/schema.perso/c.schema = pidfile=A0=A0=A0=A0=A0=A0=A0=A0 /var/run/slapd/slapd.pid argsfile=A0=A0= =A0=A0=A0=A0=A0 /var/run/slapd/slapd.args loglevel=A0=A0=A0=A0=A0 2 <= br>allow bind_v2 # The maximum number of entries that is returned fo= r a search operation sizelimit=A0=A0=A0=A0=A0=A0 500000 # The tool-threads parameter sets= the actual amount of cpu's that is used # for indexing. tool-thr= eads=A0=A0=A0 1 database=A0=A0=A0=A0=A0=A0=A0 bdb # The b= ase of your directory in database #1 suffix=A0=A0=A0=A0=A0=A0=A0=A0=A0 "ou=3DPeople,dc=3Dc,dc=3Dfr"<br= > # rootdn directive for specifying a superuser on the database. This is= needed # for syncrepl. rootdn=A0=A0=A0=A0=A0=A0=A0=A0=A0 "cn=3D= admin,ou=3DPeople,dc=3Dc,dc=3Dfr" rootpw=A0=A0=A0=A0=A0=A0=A0=A0=A0= "password" # Where the database file are physically stored for database #1 = directory=A0=A0=A0=A0=A0=A0 "/var/lib/ldap-people" dbconfi= g set_cachesize 0 536870912 0 dbconfig set_flags=A0=A0=A0 DB_LOG_AUTOREM= OVE dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 <= br>index objectClass=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 eq,pres index ou,cn,mail,surname,givenname=A0=A0=A0=A0=A0 e= q,pres,sub index uid=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 eq,pres index Application=A0=A0=A0 =A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 eq,pres,sub <= br> overlay=A0=A0=A0=A0=A0=A0=A0=A0 translucent # on demande que = les resultats des 2 annuaires soient merg=E9s translucent_no_glue off<br= >translucent_strict off #liste des attribut a chercher sur l'ove= rlay translucent_local Application #liste des attributs a chercher sur le mas= ter translucent_remote sn,GivenName,mail,street,Postalcode,l,uid,facsimi= leTelephoneNumber #activation du bind local translucent_bind_loca= l on # activation de la possibilit=E9 de changer le mot de passe transluc= ent_pwmod_local on uri=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ldap://<a= href=3D"http://ldapr.c.fr">ldapr.c.fr</a> lastmod=A0=A0=A0=A0=A0=A0=A0= =A0 off acl-bind=A0=A0=A0=A0=A0=A0=A0 binddn=3D"cn=3Dadmin,ou=3DPeo= ple,dc=3Dc,dc=3Dfr" credentials=3D"password" access to attrs=3DuserPassword,shadowLastChange =A0=A0=A0=A0=A0=A0= =A0 by dn=3D"cn=3Dadmin,ou=3DPeople,dc=3Dc,dc=3Dfr" write =A0= =A0=A0=A0=A0=A0=A0 by anonymous auth =A0=A0=A0=A0=A0=A0=A0 by self write= =A0=A0=A0=A0=A0=A0=A0 by * none access to dn.base=3D""= =A0=A0=A0=A0=A0=A0=A0 by * read Ex user : dn: uid=3Dw.k.= 1,ou=3Dc,ou=3DPeople,dc=3Dc,dc=3Dfr displayName: K W givenName: W = postalCode: 44095 objectClass: cPerson uid: w.k.1 mail: <a href=3D= "mailto:w.k@mail.fr">w.k(a)mail.fr</a> cn: K W telephoneNumber: 06 06 06 06 06 o: C l: MON sn: KNAP<br= >Application: contrat:ABC221:082534 </div><div class=3D"gmail_extra"><br= > <div class=3D"gmail_quote">2013/8/14 Howard Chu <= <a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a>></s= pan> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><a href=3D"mailto:theju3434@gmail.com" targe= t=3D"_blank">theju3434(a)gmail.com</a> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> --047d7b34397049627604e3e73688 Content-Type: text/plain; charset=3DISO-8859-1<div class=3D"im"> Here is the stack: gdb slapd GNU gdb (GDB) 7.0.1-debian Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <<a href=3D"http://gnu.org/li= censes/gpl.html" target=3D"_blank">http://gnu.org/licenses/gpl.html<= /a> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> </blockquote> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. =A0Type "show co= pying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <<a href=3D"http://www.gnu.org/software/gdb/bugs/" target=3D"_blank">htt= p://www.gnu.org/software/gdb/bugs/</a>>... Reading symbols from /usr/sbin/slapd...(no debugging symbols found)...done.= </div></blockquote> This trace is useless since it doesn't have any symbols. Please reread = the FAQ article in my previous reply. -- =A0 -- Howard Chu =A0 CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a> =A0 Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a> =A0 Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> </div> --001a11339f3813188a04e3e76889--

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