openldap-bugs June 2015

openldap-bugs@openldap.org

21 participants
71 discussions

Re: (ITS#8048) back-sock/slapo-sock issue
by hyc＠symas.com 29 Jun '15

29 Jun '15

michael(a)stroeder.com wrote: > michael(a)stroeder.com wrote: >> Null-bytes really needed? > > Hmm, with null-bytes the wrong result code is returned to the LDAP client. > > Without null-bytes the correct result code is returned to the client but slapd > complains about unknown string: > > 'RESULT\nmsgid: 1\ncode: 49\nmatched: uid=wuqww,cn=ampua,ou=ampua\ninfo: NOK\n\n' > > results in log message: > > 559174df str2result (msgid: 1 > code: 0 > > ) unknown > 559174df str2result ( > ) unknown I would almost suspect you were running on Windows. None of the behavior you're reporting occurs for me using the searchexample.pl script. Sounds like your problem is a python runtime configuration, not a slapd bug. -- -- 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#8048) back-sock/slapo-sock issue
by michael＠stroeder.com 29 Jun '15

29 Jun '15

michael(a)stroeder.com wrote: > Null-bytes really needed? Hmm, with null-bytes the wrong result code is returned to the LDAP client. Without null-bytes the correct result code is returned to the client but slapd complains about unknown string: 'RESULT\nmsgid: 1\ncode: 49\nmatched: uid=wuqww,cn=ampua,ou=ampua\ninfo: NOK\n\n' results in log message: 559174df str2result (msgid: 1 code: 0 ) unknown 559174df str2result ( ) unknown

1 0

Re: (ITS#8048) back-sock/slapo-sock issue
by michael＠stroeder.com 29 Jun '15

29 Jun '15

Michael Str=F6der wrote: > This is my Python response string: >=20 > 'RESULT\nmsgid: 1\ncode: 49\ninfo: remote NOK\n\n' Hmmpf! After adding null-bytes in each line like this 'RESULT\n\x00msgid: 1\n\x00code: 49\n\x00\n\x00' at least this message went away also with RE24: > This leads to slapd debug output: >=20 > 55914b01 str2result (msgid: 1 > code: 49 > info: remote NOK >=20 > ) unknown > 55914b01 str2result ( > ) unknown Null-bytes really needed? str2result() checks for null-bytes in a bunch o= f cases. I really wonder why null-terminated char *s is used. Ciao, Michael.

1 0

Re: (ITS#8048) back-sock/slapo-sock issue
by michael＠stroeder.com 29 Jun '15

29 Jun '15

hyc(a)openldap.org wrote: > Full_Name: Howard Chu > Version: 2.4 > OS:=20 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (110.49.207.42) > Submitted by: hyc >=20 > The result parser is checking for CONTINUE in the wrong place. Please re-open this ticket. RE24 (tagged as 2.4.41) made things worse. Is there a chance to get things fixed? I promise to help testing. First CONTINUE\n works in RE24 better than in 2.4.40 which was the cause = of this ITS. But handling RESULT is seriously broken, even more than in 2.4.40. Example: This is my Python response string: 'RESULT\nmsgid: 1\ncode: 49\ninfo: remote NOK\n\n' This leads to slapd debug output: 55914b01 str2result (msgid: 1 code: 49 info: remote NOK ) unknown 55914b01 str2result ( ) unknown Note that the whole string is returned as being unknown. Also with 2.4.40 my client script receives ' remote NOK' as diagnostic message. With RE24 the diagnostic message is complete garbage. So I tried many response string variants regarding number of \n and leavi= ng away space after the colon etc. But not really working. Sometimes slapd hangs, sometimes my client hangs e.g. when sending two subsequent bind requests in one open LDAP connection.

1 0

(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 24 Jun '15

24 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2015