openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

(ITS#8180) back-sock should not return sucess in case of error
by michael＠stroeder.com 29 Jun '15

29 Jun '15

Full_Name: Version: HEAD OS: URL: Submission from: (NULL) (84.181.173.53) back-sock should definitely never return success(0) to the client in case the external listener returned non-parseable message: Example trace log: 55913915 => str2entry: "FOOBAR msgid: 1 code: 49 " 55913915 <= str2entry NULL (parse_line) 55913915 str2entry: entry -1 has no dn 55913915 str2entry(FOOBAR) failed 55913915 sock: fgets failed: Success (0)

1 0

(ITS#8179) LMDB: Feature Request: mdb_env_check_mapsize(env)
by scott＠GameRanger.com 28 Jun '15

28 Jun '15

Full_Name: Scott Kevill Version: LMDB 0.9.14 OS: CentOS 5-7 URL: ftp://ftp.openldap.org/incoming/scott-kevill-150628.patch Submission from: (NULL) (60.224.160.178) mdb_txn_begin / mdb_txn_renew will return MDB_MAP_RESIZED for the current process if another process has changed the mapsize AND the data has grown past the current process mapsize. However, by that point, in a multithreaded environment it may be difficult to wind back to a "safe" point of no active txns in order to call mdb_env_set_mapsize(env, 0) to update the mapsize. Requesting: int mdb_env_check_mapsize(MDB_env *env); to return either MDB_SUCCESS or MDB_MAP_RESIZED. This should be lightweight enough to call frequently enough to decide whether to initiate a "safe" point to enable calling mdb_env_set_mapsize(env, 0). Return MDB_SUCCESS if the MDB has not been opened yet. Scenario: - Process W is a writer - Process R is a reader with multiple reader threads (read-only) - Both processes are running and using a 2GB mapsize MDB - Data is currently 1GB - Ops decide W should increase mapsize to 3GB allowing for more expansion - W calls mdb_env_set_mapsize(env, 3GB) - R's mapsize remains at 2GB%0 D Data grows - R:1 thread begins a moderately long read-only txn - Data grows past 2GB - R:2 thread tries to begin a read-only txn, but fails with MDB_MAP_RESIZED - R:2 thread cannot call mdb_env_set_mapsize(env, 0), because of R:1's txn - A major control flow issue exists now, as R:2 may be deep into work, but can't continue nor back out With mdb_env_check_mapsize(), R could periodically test it and if needed, initiate a "safe" point where none of R's threads have active txns. This could be done long before the data size actually reaches R's original mapsize (ie. when data is ~1GB rather >2GB). - Enforcing synchronisation to a "safe" point might be relatively expensive, so it would be important to know if the mapsize has changed first. ie. Making mdb_env_set_mapsize(env, 0) lightweight for the unchanged mapsize case isn't enough I've attached a sample patch against master (scott-kevill-150628.patch). I've tested it against 0.9.14. The code is trivial and is based on the behaviour of mdb_env_set_mapsize(env, 0). I didn't use git for the patch, so not too difficult to get working. Less than 10 new lines, but for the record, I release it to public domain. Feel free to massage it as needed.

1 0

Re: (ITS#7791) 3-Way delta MMR segfault
by quanah＠zimbra.com 27 Jun '15

27 Jun '15

--On Saturday, June 27, 2015 8:01 AM +0000 frederic.nass(a)univ-lorraine.fr wrote: > ------=_Part_4076294_1166621201.1435388481648 > Content-Type: text/plain; charset=utf-8 > Content-Transfer-Encoding: quoted-printable > > Hi,=20 > > We are facing the exact same situation with a 3-way configuration with > open= ldap-2.4.39.2z packaged by Zimbra 8.6 p2.=20 > > Slapd crashes at some point during first replication. We can reproduce > this= on any of the 3 nodes by stopping ldap service, deleting databases > (access= log and mdb) and restarting ldap service.=20 > > Please tell us how we can be helpful.=20 Provide a gdb backtrace. <http://www.openldap.org/faq/data/cache/59.html> --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7791) 3-Way delta MMR segfault
by frederic.nass＠univ-lorraine.fr 27 Jun '15

27 Jun '15

------=_Part_4076294_1166621201.1435388481648 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,=20 We are facing the exact same situation with a 3-way configuration with open= ldap-2.4.39.2z packaged by Zimbra 8.6 p2.=20 Slapd crashes at some point during first replication. We can reproduce this= on any of the 3 nodes by stopping ldap service, deleting databases (access= log and mdb) and restarting ldap service.=20 Please tell us how we can be helpful.=20 Fr=C3=A9d=C3=A9ric Nass=20 Sous-direction Infrastructures=20 Direction du Num=C3=A9rique=20 Universit=C3=A9 de Lorraine=20 ------=_Part_4076294_1166621201.1435388481648 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: arial, helvetica, sans-serif; font-s= ize: 12pt; color: #000000"><div>Hi,</div><div> </di= v><div>We are facing the exact same situation with a 3-way configurati= on with openldap-2.4.39.2z packaged by Zimbra 8.6 p2.</div><div> </= div><div>Slapd crashes at some point during first replication. We can repro= duce this on any of the 3 nodes by stopping ldap service, deleting dat= abases (accesslog and mdb) and restarting ldap service.</div><div> </div= ><div>Please tell us how we can be helpful.</div><div data-marker=3D"__SIG_= PRE__"> Fr=C3=A9d=C3=A9ric Nass Sous-direction Infrastructures <b= r>Direction du Num=C3=A9rique Universit=C3=A9 de Lorraine </div></d= iv></body></html> ------=_Part_4076294_1166621201.1435388481648--

1 0

Re: (ITS#8173)
by hyc＠symas.com 25 Jun '15

25 Jun '15

Adrian.Raemy(a)vtg.admin.ch wrote: > --_000_BE8E19527611BA409D68FF6EA186AF9002A24849BEREXMBX19ifc1i_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > Dear Howard, > > I did a core dump when the crash occurred at slapd respectively when the ba= > ck-ldap crashed. > Maybe the output of the gdb can help you find out where the problem is. > Please let me know what you need more. This trace seems to lack debug symbols. Without source line numbers etc. there's nothing we can determine from this trace. Please read the FAQ. http://www.openldap.org/faq/index.cgi?file=59 The trace shows that you probably have some overlays configured. What overlays? You need to provide your slapd config files if you want any help here. Volunteers aren't going to go out of their way to help you if you aren't going to provide the needed info. > Core was generated by `/usr/lib/openldap/slapd -h ldap://0.0.0.0:389 ldap= > s://0.0.0.0:636 -f /etc/op'. > Program terminated with signal 11, Segmentation fault. > #0 0x00007fc0627492c6 in ldap_back_bind () > (gdb) where > #0 0x00007fc0627492c6 in ldap_back_bind () > #1 0x00007fc062639fcb in fe_op_bind () > #2 0x00007fc0626a86fd in overlay_op_walk () > #3 0x00007fc0626a8956 in over_op_func () > #4 0x00007fc0626a89de in over_op_bind () > #5 0x00007fc062639697 in do_bind () > #6 0x00007fc06260ff19 in connection_operation () > #7 0x00007fc0626104e1 in connection_read_thread () > #8 0x00007fc062145c3c in ldap_int_thread_pool_wrapper () from /usr/lib64/l= > ibldap_r-2.4.so.2 > #9 0x00007fc06155e806 in start_thread () from /lib64/libpthread.so.0 > #10 0x00007fc05fda902d in clone () from /lib64/libc.so.6 > #11 0x0000000000000000 in ?? () > > Core was generated by `/usr/lib/openldap/slapd -h ldap://0.0.0.0:389 ldap= > s://0.0.0.0:636 -f /etc/op'. > Program terminated with signal 11, Segmentation fault. > #0 0x00007fc0627492c6 in ldap_back_bind () > (gdb) where > #0 0x00007fc0627492c6 in ldap_back_bind () > #1 0x00007fc062639fcb in fe_op_bind () > #2 0x00007fc0626a86fd in overlay_op_walk () > #3 0x00007fc0626a8956 in ?? () > #4 0x00007fc0626a89de in ?? () > #5 0x00007fc062639697 in do_bind () > #6 0x00007fc06260ff19 in ?? () > #7 0x00007fc0626104e1 in ?? () > #8 0x00007fc062145c3c in ldap_int_thread_pool_wrapper () from /usr/lib64/l= > ibldap_r-2.4.so.2 > #9 0x00007fc06155e806 in start_thread () from /lib64/libpthread.so.0 > #10 0x00007fc05fda902d in gnu_dev_makedev () from /lib64/libc.so.6 > #11 0x0000000000000000 in ?? () > > Best regards > Adrian -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8173)
by Adrian.Raemy＠vtg.admin.ch 24 Jun '15

24 Jun '15

--_000_BE8E19527611BA409D68FF6EA186AF9002A24849BEREXMBX19ifc1i_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Howard, I did a core dump when the crash occurred at slapd respectively when the ba= ck-ldap crashed. Maybe the output of the gdb can help you find out where the problem is. Please let me know what you need more. Core was generated by `/usr/lib/openldap/slapd -h ldap://0.0.0.0:389 ldap= s://0.0.0.0:636 -f /etc/op'. Program terminated with signal 11, Segmentation fault. #0 0x00007fc0627492c6 in ldap_back_bind () (gdb) where #0 0x00007fc0627492c6 in ldap_back_bind () #1 0x00007fc062639fcb in fe_op_bind () #2 0x00007fc0626a86fd in overlay_op_walk () #3 0x00007fc0626a8956 in over_op_func () #4 0x00007fc0626a89de in over_op_bind () #5 0x00007fc062639697 in do_bind () #6 0x00007fc06260ff19 in connection_operation () #7 0x00007fc0626104e1 in connection_read_thread () #8 0x00007fc062145c3c in ldap_int_thread_pool_wrapper () from /usr/lib64/l= ibldap_r-2.4.so.2 #9 0x00007fc06155e806 in start_thread () from /lib64/libpthread.so.0 #10 0x00007fc05fda902d in clone () from /lib64/libc.so.6 #11 0x0000000000000000 in ?? () Core was generated by `/usr/lib/openldap/slapd -h ldap://0.0.0.0:389 ldap= s://0.0.0.0:636 -f /etc/op'. Program terminated with signal 11, Segmentation fault. #0 0x00007fc0627492c6 in ldap_back_bind () (gdb) where #0 0x00007fc0627492c6 in ldap_back_bind () #1 0x00007fc062639fcb in fe_op_bind () #2 0x00007fc0626a86fd in overlay_op_walk () #3 0x00007fc0626a8956 in ?? () #4 0x00007fc0626a89de in ?? () #5 0x00007fc062639697 in do_bind () #6 0x00007fc06260ff19 in ?? () #7 0x00007fc0626104e1 in ?? () #8 0x00007fc062145c3c in ldap_int_thread_pool_wrapper () from /usr/lib64/l= ibldap_r-2.4.so.2 #9 0x00007fc06155e806 in start_thread () from /lib64/libpthread.so.0 #10 0x00007fc05fda902d in gnu_dev_makedev () from /lib64/libc.so.6 #11 0x0000000000000000 in ?? () Best regards Adrian --_000_BE8E19527611BA409D68FF6EA186AF9002A24849BEREXMBX19ifc1i_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"DE-CH" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Dear Howard,<o:p></o:p> <o:p> </o:p> I did a core dump when the cras= h occurred at slapd respectively when the back-ldap crashed.<o:p></o:p></sp= an> Maybe the output of the gdb can= help you find out where the problem is.<o:p></o:p> Please let me know what you nee= d more.<o:p></o:p> <o:p> </o:p> Core was generated by `/usr/lib= /openldap/slapd -h  ldap://0.0.0.0:389  ldaps://0.0.0.0:636 = -f /etc/op'.<o:p></o:p> Program terminated with signal = 11, Segmentation fault.<o:p></o:p> #0  0x00007fc0627492c6 in = ldap_back_bind ()<o:p></o:p> (gdb) where<o:p></o:p></= p> #0  0x00007fc0627492c6 in = ldap_back_bind ()<o:p></o:p> #1  0x00007fc062639fcb in fe_op_bind ()<o:p></o= :p> #2  0x00007fc0626a86fd in = overlay_op_walk ()<o:p></o:p> #3  0x00007fc0626a8956 in = over_op_func ()<o:p></o:p> #4  0x00007fc0626a89de in = over_op_bind ()<o:p></o:p> #5  0x00007fc062639697 in = do_bind ()<o:p></o:p> #6  0x00007fc06260ff19 in = connection_operation ()<o:p></o:p> #7  0x00007fc0626104e1 in = connection_read_thread ()<o:p></o:p> #8  0x00007fc062145c3c in = ldap_int_thread_pool_wrapper () from /usr/lib64/libldap_r-2.4.so.2<o:p></o:= p> #9  0x00007fc06155e806 in = start_thread () from /lib64/libpthread.so.0<o:p></o:p> #10 0x00007fc05fda902d in clone= () from /lib64/libc.so.6<o:p></o:p> #11 0x0000000000000000 in ?? ()= <o:p></o:p> <o:p> </o:p> Core was generated by `/usr/lib= /openldap/slapd -h  ldap://0.0.0.0:389  ldaps://0.0.0.0:636 = -f /etc/op'.<o:p></o:p> Program terminated with signal = 11, Segmentation fault.<o:p></o:p> #0  0x00007fc0627492c6 in = ldap_back_bind ()<o:p></o:p> (gdb) where<o:p></o:p></= p> #0  0x00007fc0627492c6 in = ldap_back_bind ()<o:p></o:p> #1  0x00007fc062639fcb in fe_op_bind ()<o:p></o= :p> #2  0x00007fc0626a86fd in = overlay_op_walk ()<o:p></o:p> #3  0x00007fc0626a8956 in = ?? ()<o:p></o:p> #4  0x00007fc0626a89de in = ?? ()<o:p></o:p> #5  0x00007fc062639697 in = do_bind ()<o:p></o:p> #6  0x00007fc06260ff19 in = ?? ()<o:p></o:p> #7  0x00007fc0626104e1 in = ?? ()<o:p></o:p> #8  0x00007fc062145c3c in = ldap_int_thread_pool_wrapper () from /usr/lib64/libldap_r-2.4.so.2<o:p></o:= p> #9  0x00007fc06155e806 in = start_thread () from /lib64/libpthread.so.0<o:p></o:p> #10 0x00007fc05fda902d in gnu_d= ev_makedev () from /lib64/libc.so.6<o:p></o:p> #11 0x0000000000000000 in ?? ()= <o:p></o:p> <o:p>&nbs= p;</o:p> Best rega= rds<o:p></o:p> Adrian</s= pan><o:p></o:p> </div> </body> </html> --_000_BE8E19527611BA409D68FF6EA186AF9002A24849BEREXMBX19ifc1i_--

1 0

(ITS#8178) back-sock: Timeout to avoid locking
by michael＠stroeder.com 24 Jun '15

24 Jun '15

Full_Name: Version: HEAD OS: URL: Submission from: (NULL) (2001:8d8:1fe:700::1:3) If a back-sock listener does not correctly respond to a request slapd thread hangs forever and slapd has to be stopped with kill -9. slapd should implement a timeout after which it abandons processing the LDAP request.

1 0

(ITS#8177) RFE: back-sock to receive controls
by michael＠stroeder.com 22 Jun '15

22 Jun '15

Full_Name: Version: HEAD OS: URL: Submission from: (NULL) (84.178.24.72) It would be nice if back-sock would also receive the extended controls sent by the client and could generate response control to be returned to the client.

1 0

Re: (ITS#8176) the olcRootDSE attributeType should be Single Value
by elecharny＠gmail.com 22 Jun '15

22 Jun '15

Le 22/06/15 14:51, Howard Chu a écrit : > elecharny(a)gmail.com wrote: >> Ah, my bad then. >> >> What's the rational for having the RootDSE spread in many files though ? > > Probably different applications may add their own sets of attributes > as individual files. > Ok. Probably not a frequent use case, but never mind. The GUI shall not rule the server ! Thanks Mickaël, Howard for the clarifications.

1 0

Re: (ITS#8176) the olcRootDSE attributeType should be Single Value
by hyc＠symas.com 22 Jun '15

22 Jun '15

elecharny(a)gmail.com wrote: > Ah, my bad then. > > What's the rational for having the RootDSE spread in many files though ? Probably different applications may add their own sets of attributes as individual files. -- -- 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:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs