- openldap-bugs - openldap.org

(ITS#7663) Add 'namingContexts' to backend entry below cn=Backends, cn=Monitor
by michael＠stroeder.com 13 Aug '13

13 Aug '13

Full_Name: Version: HEAD OS: URL: Submission from: (NULL) (79.219.109.139) Feature request: It would be quite handy if attribute 'namingContexts' would be available in backend entries in subtree cn=Backends,cn=Monitor. This would allow to quickly query the set of supported LDAPv3 ext. controls in attribute 'supportedControl' for a given naming context. Of course one can query the DB entry below cn=Databases,cn=Monitor and look at 'seeAlso' but that's extra amount of work without added value especially since 'seeAlso' is multi-valued also pointing to overlay entries. Alternative would be to add 'supportedControl' to entries below cn=Databases,cn=Monitor.

1 0

Re: (ITS#7660) LMDB: Proposing a small addition to the API: mdb_txn_env
by quanah＠zimbra.com 12 Aug '13

12 Aug '13

--On Friday, August 09, 2013 9:33 PM -0500 Salvador Ortiz Garcia <sog(a)msg.com.mx> wrote: > Sure! > > In fact I want the module to become the "oficial" Perl's LMDB module. > > Right now I'm writing an extensive test battery that is uncovering some > bad assumptions, undocumented features, and/or bugs in the library. > > Please expect the announce of an alpha release early in the next week in > openldap-devel. > > I'm Just waiting for a version of LMDB in git with the issues solved. They should be all resolved now. Will you be hosting your CPAN module anywhere like github or gitorious? --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Antwort: Re: (ITS#7653) Test Build Version 2.4.36 hangs
by howard.allison＠pensionsversicherung.at 11 Aug '13

11 Aug '13

--0__=4EBBF156DFB715BF8f9e8a93df938690918c4EBBF156DFB715BF Content-type: multipart/alternative; Boundary="1__=4EBBF156DFB715BF8f9e8a93df938690918c4EBBF156DFB715BF" --1__=4EBBF156DFB715BF8f9e8a93df938690918c4EBBF156DFB715BF Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Hi! Sorry - here's the stack trace: SLAPD: (dbx) thread info thread state-k wchan state-u k-tid mode held scope functi= on $t1 wait 0xf1000f0a1000ee40 blocked 15597767 k no sy= s general: pthread addr =3D 0x3009f56c size =3D 0x290 vp addr =3D 0x300a15b0 size =3D 0x2e0 thread errno =3D 0 start pc =3D 0x10000420 joinable =3D yes pthread_t =3D 1 scheduler: kernel =3D user =3D 1 (other) nice =3D 60 event : event =3D 0x0 cancel =3D enabled, deferred, not pending stack storage: base =3D 0x20000000 size =3D 0xff22190= limit =3D 0x2ff22190 sp =3D 0x2ff21e90 thread state-k wchan state-u k-tid mode held scope functi= on >$t2 run running 36372639 k no sys __fd_select general: pthread addr =3D 0x308e5cf0 size =3D 0x290 vp addr =3D 0x303d3780 size =3D 0x2e0 thread errno =3D 4 start pc =3D 0x3001f600 joinable =3D yes pthread_t =3D 102 scheduler: kernel =3D user =3D 1 (other) nice =3D 60 event : event =3D 0x0 cancel =3D enabled, deferred, not pending stack storage: base =3D 0x304e5000 size =3D 0x400000 limit =3D 0x308e5b90 sp =3D 0x308e4530 thread state-k wchan state-u k-tid mode held scope functi= on $t3 run running 30015693 u no sys base_candidate general: pthread addr =3D 0x30ce9cf0 size =3D 0x290 vp addr =3D 0x303d5790 size =3D 0x2e0 thread errno =3D 11 start pc =3D 0xf0391ec0 joinable =3D no pthread_t =3D 203 scheduler: kernel =3D user =3D 1 (other) nice =3D 60 event : event =3D 0x0 cancel =3D enabled, deferred, not pending stack storage: base =3D 0x308e9000 size =3D 0x400000 limit =3D 0x30ce9b90 sp =3D 0x30c286f0 thread state-k wchan state-u k-tid mode held scope functi= on $t4 run running 21561505 u no sys base_candidate general: pthread addr =3D 0x319eecf0 size =3D 0x290 vp addr =3D 0x303e4b60 size =3D 0x2e0 thread errno =3D 11 start pc =3D 0xf0391ec0 joinable =3D no pthread_t =3D 304 scheduler: kernel =3D user =3D 1 (other) nice =3D 60 event : event =3D 0x0 cancel =3D enabled, deferred, not pending stack storage: base =3D 0x315ed000 size =3D 0x400000 limit =3D 0x319eeb90 sp =3D 0x3192d6f0 (dbx) thread current -1 warning: Thread is in kernel mode, not all registers can be accessed. (dbx) where .() at 0x11c501d40 _event_wait(??, ??) at 0xd0502be4 _cond_wait_local(??, ??, ??) at 0xd0510f40 _cond_wait(??, ??, ??) at 0xd0511510 pthread_join(??, ??) at 0xd04f91b0 ldap_pvt_thread_join(thread =3D 8, thread_return =3D 0x00000008), line = 197 in "thr_posix.c" slapd_daemon(), line 2929 in "daemon.c" main(argc =3D 0, argv =3D (nil)), line 1012 in "main.c" (dbx) thread current -2 (dbx) where __fd_select(??, ??, ??, ??, ??) at 0xd0262f2c daemon.select(__fds =3D 0, __readlist =3D (nil), __writelist =3D (nil),= __exceptlist =3D (nil), __timeout =3D (nil)), line 234 in "time.h" unnamed block in slapd_daemon_task(ptr =3D (nil)), line 2536 in "daemon= .c" unnamed block in slapd_daemon_task(ptr =3D (nil)), line 2536 in "daemon= .c" slapd_daemon_task(ptr =3D (nil)), line 2536 in "daemon.c" (dbx) thread current -3 (dbx) where search.base_candidate(be =3D (nil), e =3D (nil), ids =3D (nil)), line 3= 71 in "search.c" glue_sub_search(op =3D 0xf061b148, rs =3D 0xf061b108, b0 =3D 0x00000002= , on =3D 0xf0240744), line 380 in "backglue.c" glue_op_search(op =3D 0x301185f8, rs =3D 0x303d5a78), line 537 in "back= glue.c" overlay_op_walk(op =3D (nil), rs =3D (nil), which =3D op_bind, oi =3D (= nil), on =3D 0x01000000), line 661 in "backover.c" over_op_func(op =3D (nil), rs =3D 0x102c9510, which =3D op_bind), line = 723 in "backover.c" fe_op_search(op =3D 0x00004105, rs =3D 0x00000100), line 402 in "search= .c" do_search(op =3D 0x000003e8, rs =3D (nil)), line 247 in "search.c" unnamed block in connection_operation(ctx =3D 0x00000114, arg_v =3D 0x00000045), line 1155 in "connection.c" connection_operation(ctx =3D 0x00000114, arg_v =3D 0x00000045), line 11= 55 in "connection.c" connection_read_thread(ctx =3D (nil), argv =3D (nil)), line 1291 in "connection.c" ldap_int_thread_pool_wrapper(xpool =3D (nil)), line 688 in "tpool.c" (dbx) thread current -4 (dbx) where search.base_candidate(be =3D (nil), e =3D (nil), ids =3D (nil)), line 3= 71 in "search.c" glue_sub_search(op =3D 0xf061b148, rs =3D 0xf061b108, b0 =3D 0x00000002= , on =3D 0xf0240744), line 380 in "backglue.c" glue_op_search(op =3D 0x301185f8, rs =3D 0x303e4ee8), line 537 in "back= glue.c" overlay_op_walk(op =3D (nil), rs =3D (nil), which =3D op_bind, oi =3D (= nil), on =3D 0x01000000), line 661 in "backover.c" over_op_func(op =3D (nil), rs =3D 0x102c9510, which =3D op_bind), line = 723 in "backover.c" fe_op_search(op =3D 0x00004105, rs =3D 0x00000100), line 402 in "search= .c" do_search(op =3D 0x000003e9, rs =3D (nil)), line 247 in "search.c" unnamed block in connection_operation(ctx =3D 0x0000019c, arg_v =3D 0x00000067), line 1155 in "connection.c" connection_operation(ctx =3D 0x0000019c, arg_v =3D 0x00000067), line 11= 55 in "connection.c" connection_read_thread(ctx =3D (nil), argv =3D (nil)), line 1291 in "connection.c" ldap_int_thread_pool_wrapper(xpool =3D (nil)), line 688 in "tpool.c" LDAPSEARCH: Waiting to attach to process 11272394 ... Successfully attached to ldapsearch. warning: Directory containing ldapsearch could not be determined. Apply 'use' command to initialize source path. Type 'help' for help. reading symbolic information ... stopped in __fd_poll at 0xd0262734 ($t1) 0xd0262734 (__fd_poll+0xb4) 80410014 lwz r2,0x14(r1) (dbx) where __fd_poll(??, ??, ??) at 0xd0262734 os-ip.poll(__listptr =3D 0x00000001, __nfds =3D 4294967294, __timeout =3D= 1000000), line 107 in "poll.h" ldap_int_select(ld =3D (nil), timeout =3D 0x3002a9c8), line 1139 in "os= -ip.c" wait4msg(ld =3D 0xd0f6bb50, msgid =3D 804398239, all =3D 804389024, tim= eout =3D (nil), result =3D 0x2ff200e0), line 312 in "result.c" ldap_result(ld =3D (nil), msgid =3D 805309096, all =3D 804389216, timeo= ut =3D 0x28224243, result =3D 0x1000866c), line 117 in "result.c" dosearch(ld =3D 0x30009c18, base =3D "file:///%s/", scope =3D 268504837= , filtpatt =3D (nil), value =3D (nil), attrs =3D (nil), attrsonly =3D -261995236, = sctrls =3D 0x10010f08, cctrls =3D (nil), timeout =3D (nil), sizelimit =3D -1), lin= e 1447 in "ldapsearch.c" main(argc =3D 0, argv =3D (nil)), line 1222 in "ldapsearch.c" (dbx) thread thread state-k wchan state-u k-tid mode held scope functi= on >$t1 run running 35192885 k no sys __fd_= poll Thanks Howard Mit freundlichen Gr=FC=DFen Howard ALLISON Pensionsversicherungsanstalt Rechenzentrumsbetrieb A-1021 Wien, Friedrich-Hillegeist-Stra=DFe 1 E-Mail..: howard.allison(a)pva.sozvers.at Internet: www.pensionsversicherung.at Von: Quanah Gibson-Mount <quanah(a)zimbra.com> An: howard.allison(a)pensionsversicherung.at, openldap-its(a)openldap.org, Datum: 07.08.2013 21:20 Betreff: Re: (ITS#7653) Test Build Version 2.4.36 hangs --On July 31, 2013 6:51:18 AM +0000 howard.allison@pensionsversicherung= .at wrote: > Full_Name: Howard Allison > Version: 2.4.36 > OS: AIX > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.153.217.248) > > > AIX 6.1 Using IBM VAC Compiler > Configure and Build works, test hangs at test005 Hi, thanks for the report. Unfortunately, your stack trace only shows = a single thread out of multiple threads. This thread is waiting on anoth= er thread to complete a task. Please submit a full backtrace of all threa= ds. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration -----------------------------------------------------------------------= --------------------------------- VERTRAULICHKEIT: Diese Nachricht ist ausschlie=DFlich f=FCr denjenigen bestimmt, an den sie adressiert ist und kann vertrauliche Informationen= enthalten. Falls Sie nicht der Empf=E4nger dieser Nachricht sind, weise= n wir Sie darauf hin, dass die unberechtigte Weitergabe oder Verwendung sowie= das unberechtigte Verteilen oder Kopieren dieser Nachricht strikt untersagt= sind. Falls Sie diese Nachricht irrt=FCmlich erhalten haben, vernichten= Sie sie bitte sofort. CONFIDENTIALITY: This message is intended only for the use of the individuality or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure= . If you are not the intended recipient you are notified that any disseminat= ion, distribution, use or copying of this communication is strictly prohibit= ed. If you received this message in error, please immediately destroy this message. -----------------------------------------------------------------------= --------------------------------- = --1__=4EBBF156DFB715BF8f9e8a93df938690918c4EBBF156DFB715BF Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable <html><body> Hi! Sorry - here's the stack trace:</f= ont> SLAPD: (dbx) thread info  thread  state-k   =   wchan    state-u    k-tid   mode held s= cope function  $t1     wait &nbsp= ;    0xf1000f0a1000ee40 blocked  15597767     = k   no   sys       general:</fon= t>          = pthread addr =3D 0x3009f56c         size   &nb= sp;     =3D 0x290          = vp addr      =3D 0x300a15b0         = size         =3D 0x2e0          = thread errno =3D 0          = start pc     =3D 0x10000420          = joinable     =3D yes          = pthread_t    =3D 1       scheduler:</f= ont>          = kernel       =3D          = user         =3D 1 (other)          = nice         =3D 60       event :</font= >          = event        =3D 0x0          = cancel       =3D enabled, deferred, not pending<b= r>       stack storage= :          = base         =3D 0x20000000       &n= bsp; size         =3D 0xff22190          = limit        =3D 0x2ff22190          = sp           =3D 0x2ff21e90  thread  state-k   =   wchan    state-u    k-tid   mode held s= cope function >$t2     run   &= nbsp;              running  363= 72639     k   no   sys  __fd_select =       general:</fon= t>          = pthread addr =3D 0x308e5cf0         size   &nb= sp;     =3D 0x290          = vp addr      =3D 0x303d3780         = size         =3D 0x2e0          = thread errno =3D 4          = start pc     =3D 0x3001f600          = joinable     =3D yes          = pthread_t    =3D 102       scheduler:</f= ont>          = kernel       =3D          = user         =3D 1 (other)          = nice         =3D 60       event :</font= >          = event        =3D 0x0          = cancel       =3D enabled, deferred, not pending<b= r>       stack storage= :          = base         =3D 0x304e5000       &n= bsp; size         =3D 0x400000          = limit        =3D 0x308e5b90          = sp           =3D 0x308e4530  thread  state-k   =   wchan    state-u    k-tid   mode held s= cope function  $t3     run  =                running  3= 0015693     u   no   sys  base_candidate</font= >       general:</fon= t>          = pthread addr =3D 0x30ce9cf0         size   &nb= sp;     =3D 0x290          = vp addr      =3D 0x303d5790         = size         =3D 0x2e0          = thread errno =3D 11          = start pc     =3D 0xf0391ec0          = joinable     =3D no          = pthread_t    =3D 203       scheduler:</f= ont>          = kernel       =3D          = user         =3D 1 (other)          = nice         =3D 60       event :</font= >          = event        =3D 0x0          = cancel       =3D enabled, deferred, not pending<b= r>       stack storage= :          = base         =3D 0x308e9000       &n= bsp; size         =3D 0x400000          = limit        =3D 0x30ce9b90          = sp           =3D 0x30c286f0  thread  state-k   =   wchan    state-u    k-tid   mode held s= cope function  $t4     run  =                running  2= 1561505     u   no   sys  base_candidate</font= >       general:</fon= t>          = pthread addr =3D 0x319eecf0         size   &nb= sp;     =3D 0x290          = vp addr      =3D 0x303e4b60         = size         =3D 0x2e0          = thread errno =3D 11          = start pc     =3D 0xf0391ec0          = joinable     =3D no          = pthread_t    =3D 304       scheduler:</f= ont>          = kernel       =3D          = user         =3D 1 (other)          = nice         =3D 60       event :</font= >          = event        =3D 0x0          = cancel       =3D enabled, deferred, not pending<b= r>       stack storage= :          = base         =3D 0x315ed000       &n= bsp; size         =3D 0x400000          = limit        =3D 0x319eeb90          = sp           =3D 0x3192d6f0 (dbx) thread current -1 = warning: Thread is in kernel mode,= not all registers can be accessed. (dbx) where .() at 0x11c501d40 _event_wait(??, ??) at 0xd0502be4<= /font> _cond_wait_local(??, ??, ??) at 0x= d0510f40 _cond_wait(??, ??, ??) at 0xd05115= 10 pthread_join(??, ??) at 0xd04f91b0= ldap_pvt_thread_join(thread =3D 8,= thread_return =3D 0x00000008), line 197 in "thr_posix.c"</fo= nt> slapd_daemon(), line 2929 in &quot= ;daemon.c" main(argc =3D 0, argv =3D (nil)), = line 1012 in "main.c" (dbx) thread current -2 = (dbx) where __fd_select(??, ??, ??, ??, ??) at= 0xd0262f2c daemon.select(__fds =3D 0, __readl= ist =3D (nil), __writelist =3D (nil), __exceptlist =3D (nil), __timeout= =3D (nil)), line 234 in "time.h" unnamed block in slapd_daemon_task= (ptr =3D (nil)), line 2536 in "daemon.c" unnamed block in slapd_daemon_task= (ptr =3D (nil)), line 2536 in "daemon.c" slapd_daemon_task(ptr =3D (nil)), = line 2536 in "daemon.c" (dbx)  thread current -3</fon= t> (dbx) where search.base_candidate(be =3D (nil)= , e =3D (nil), ids =3D (nil)), line 371 in "search.c"<= br> glue_sub_search(op =3D 0xf061b148,= rs =3D 0xf061b108, b0 =3D 0x00000002, on =3D 0xf0240744), line 380 in = "backglue.c" glue_op_search(op =3D 0x301185f8, = rs =3D 0x303d5a78), line 537 in "backglue.c" overlay_op_walk(op =3D (nil), rs =3D= (nil), which =3D op_bind, oi =3D (nil), on =3D 0x01000000), line 661 i= n "backover.c" over_op_func(op =3D (nil), rs =3D = 0x102c9510, which =3D op_bind), line 723 in "backover.c"</fon= t> fe_op_search(op =3D 0x00004105, rs= =3D 0x00000100), line 402 in "search.c" do_search(op =3D 0x000003e8, rs =3D= (nil)), line 247 in "search.c" unnamed block in connection_operat= ion(ctx =3D 0x00000114, arg_v =3D 0x00000045), line 1155 in "conne= ction.c" connection_operation(ctx =3D 0x000= 00114, arg_v =3D 0x00000045), line 1155 in "connection.c"</fo= nt> connection_read_thread(ctx =3D (ni= l), argv =3D (nil)), line 1291 in "connection.c" ldap_int_thread_pool_wrapper(xpool= =3D (nil)), line 688 in "tpool.c" (dbx) thread current -4 = (dbx) where search.base_candidate(be =3D (nil)= , e =3D (nil), ids =3D (nil)), line 371 in "search.c"<= br> glue_sub_search(op =3D 0xf061b148,= rs =3D 0xf061b108, b0 =3D 0x00000002, on =3D 0xf0240744), line 380 in = "backglue.c" glue_op_search(op =3D 0x301185f8, = rs =3D 0x303e4ee8), line 537 in "backglue.c" overlay_op_walk(op =3D (nil), rs =3D= (nil), which =3D op_bind, oi =3D (nil), on =3D 0x01000000), line 661 i= n "backover.c" over_op_func(op =3D (nil), rs =3D = 0x102c9510, which =3D op_bind), line 723 in "backover.c"</fon= t> fe_op_search(op =3D 0x00004105, rs= =3D 0x00000100), line 402 in "search.c" do_search(op =3D 0x000003e9, rs =3D= (nil)), line 247 in "search.c" unnamed block in connection_operat= ion(ctx =3D 0x0000019c, arg_v =3D 0x00000067), line 1155 in "conne= ction.c" connection_operation(ctx =3D 0x000= 0019c, arg_v =3D 0x00000067), line 1155 in "connection.c"</fo= nt> connection_read_thread(ctx =3D (ni= l), argv =3D (nil)), line 1291 in "connection.c" ldap_int_thread_pool_wrapper(xpool= =3D (nil)), line 688 in "tpool.c" LDAPSEARCH: Waiting to attach to process 11272= 394 ... Successfully attached to ldapsearc= h. warning: Directory containing ldap= search could not be determined. Apply 'use' command to initialize = source path. Type 'help' for help. reading symbolic information ...</= font> stopped in __fd_poll at 0xd0262734= ($t1) 0xd0262734 (__fd_poll+0xb4) 804100= 14         lwz   r2,0x14(r1) (dbx) where __fd_poll(??, ??, ??) at 0xd026273= 4 os-ip.poll(__listptr =3D 0x0000000= 1, __nfds =3D 4294967294, __timeout =3D 1000000), line 107 in "pol= l.h" ldap_int_select(ld =3D (nil), time= out =3D 0x3002a9c8), line 1139 in "os-ip.c" wait4msg(ld =3D 0xd0f6bb50, msgid = =3D 804398239, all =3D 804389024, timeout =3D (nil), result =3D 0x2ff20= 0e0), line 312 in "result.c" ldap_result(ld =3D (nil), msgid =3D= 805309096, all =3D 804389216, timeout =3D 0x28224243, result =3D 0x100= 0866c), line 117 in "result.c" dosearch(ld =3D 0x30009c18, base =3D= "<a href=3D"file:///%s/">file:///%s/</a>", scope =3D 2685048= 37, filtpatt =3D (nil), value =3D (nil), attrs =3D (nil), attrsonly =3D= -261995236, sctrls =3D 0x10010f08, cctrls =3D (nil), timeout =3D (nil)= , sizelimit =3D -1), line 1447 in "ldapsearch.c" main(argc =3D 0, argv =3D (nil)), = line 1222 in "ldapsearch.c" (dbx) thread  thread  state-k   =   wchan    state-u    k-tid   mode held s= cope function >$t1     run   &= nbsp;              running  351= 92885     k   no   sys  __fd_poll Thanks Howard Mit freundlichen Gr=FC=DF= en Howard ALLISON <table border=3D"0" cellspacing=3D"0" cellpadding=3D"0"> <tr valign=3D"top"><td width=3D"95"> <ul style=3D"padding-left: 1pt"><img src=3D"cid:1__=3D4EBBF156DFB715BF@= pensionsversicherung.at" width=3D"83" height=3D"52"></ul> </td><td width=3D"237" valign=3D"middle"> <ul style=3D"padding-left: 1pt">Pensionsversicherungsanstalt Rechenzentrumsbetrieb A-1021 Wien, Friedrich-Hillegeist-Stra=DFe 1 E-Mail..: <a href=3D"mailto:howard.allison@pva.sozvers.at"><font= size=3D"1" color=3D"#0000FF" face=3D"MS Sans Serif">howard.allison@= pva.sozvers.at</a><b= r> Internet: <a href=3D"http://www.pensionsversicherung.at/">www.pensionsvers= icherung.at</a></ul> </td></tr> </table> <img width=3D"16" height=3D"16" src=3D"cid:2__=3D4EBBF156DFB715BF@pensi= onsversicherung.at" border=3D"0" alt=3D"Inactive hide details for Quana= h Gibson-Mount ---07.08.2013 21:20:29---Von: Quanah Gibson-Mount <qu= anah(a)zimbra.com> An: howard.">Quanah Gibson-Mount ---07.08.2013 21:20:29---Von: Quan= ah Gibson-Mount <quanah(a)zimbra.com> An: howard.allison@pensionsve= rsicherung.at, openldap-its(a)openldap.org, Von: <fon= t size=3D"1" face=3D"sans-serif">Quanah Gibson-Mount <quanah(a)zimbra.= com> An: <font= size=3D"1" face=3D"sans-serif">howard.allison(a)pensionsversicherung.at,= openldap-its(a)openldap.org, Datum: <f= ont size=3D"1" face=3D"sans-serif">07.08.2013 21:20 Betreff: = Re: (ITS#7653) Test Build Version = 2.4.36 hangs <hr width=3D"100%" size=3D"2" align=3D"left" noshade style=3D"color:#80= 91A5; "> <tt> --On July 31, 2013 6:51:18 AM +0000 howard.allison@pensionsversicherung= .at wrote: > Full_Name: Howard Allison > Version: 2.4.36 > OS: AIX > URL: </tt><tt><a href=3D"ftp://ftp.openlda= p.org/incoming/">ftp://ftp.openldap.org/incoming/</a></tt><tt><f= ont size=3D"2"> > Submission from: (NULL) (194.153.217.248) > > > AIX 6.1 Using IBM VAC Compiler > Configure and Build works, test hangs at test005 Hi, thanks for the report.  Unfortunately, your stack trace only s= hows a single thread out of multiple threads.  This thread is waiting on = another thread to complete a task.  Please submit a full backtrace of all = threads. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra ::  the leader in open source messaging and collaboration<b= r> </tt>   ---------------------------= -----------------------------------------------------------------------= ------ VERTRAULICHKEIT: Diese Nach= richt ist ausschlie=DFlich f=FCr denjenigen bestimmt, an den sie adress= iert ist und kann vertrauliche Informationen enthalten. Falls Sie nicht= der Empf=E4nger dieser Nachricht sind, weisen wir Sie darauf hin, dass= die unberechtigte Weitergabe oder Verwendung sowie das unberechtigte V= erteilen oder Kopieren dieser Nachricht strikt untersagt sind. Falls Si= e diese Nachricht irrt=FCmlich erhalten haben, vernichten Sie sie bitte= sofort. CONFIDENTIALITY: This messa= ge is intended only for the use of the individuality or entity to which= it is addressed and may contain information that is privileged, confid= ential and exempt from disclosure. If you are not the intended recipien= t you are notified that any dissemination, distribution, use or copying= of this communication is strictly prohibited. If you received this mes= sage in error, please immediately destroy this message. ---------------------------= -----------------------------------------------------------------------= ------ </body></html>= --1__=4EBBF156DFB715BF8f9e8a93df938690918c4EBBF156DFB715BF-- --0__=4EBBF156DFB715BF8f9e8a93df938690918c4EBBF156DFB715BF Content-type: image/gif; name="15079017.gif" Content-Disposition: inline; filename="15079017.gif" Content-ID: <1__=4EBBF156DFB715BF(a)pensionsversicherung.at> Content-transfer-encoding: base64 R0lGODlhUwA0APcAAA4Rm9DR2jw/qpaYw3Z4sx4hoLy9zldZsIGDtTEzpbGyztbe3lBSr6ipyY+R vDg7p2xursnL1UZJqhgaoSosoEFDpsTF1dLT2hganp+iwIaIwmNmqyEpnGxvtnt8vbe40sHC0aap z1VXsklLpoeJuxwfn46QxZmZzF1fsdHS2WxuuTQ3piAjoSotpL6/09zd3kxPrRQXnVVYpmdptoqN vczMzKutzj0/p7i60nFztVRXrHp7tJqdwKqrxlpdskJFrJKUvn+AumJktdfY3LW2zYKFvZKUxqSl xr3F1khLrSQopM3O1igrpGpstpydxNbW1v4BAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIA AADYLuB3EgMwABIBAACV8AAAOQA8AAAAAACeAgAAAQAAAIhkWAAgwBUAqAZWAAIAAAC88hIA2Vi0 d9UHAYXk8hIAAgAAACj0EgAc8xIAotfhdxIDMAASAQAAlfAAADkAPAABAAAAEgEAAJXwAAASAzAA SLkVANi1FQAgACAAAAAVACAAIAAAABUARgBlAHIAdABpAGcAAAASAAAAAAD8iOd3AAAAAAAAAADV BwGFiGRYADzzEgDxoeF3EgMwAAIDJwASAQAAlfAAADkAPAAAABMAlfAAAKqHRQASAzAAAgMnAAAB AAAkAAAAOQA8AKEAAACIZFgApPYSABgVOwB3wrR3KAM4AGhWEwAgAQAA2LUVAAAAAAAAAAAA0PMS AJUriHcINoh3/////+DzEgAec+d3AAATAAgAFAAYAQAAbJxIAGibSACJOOh3AAAAAAAAAAAAAAAA AAAAAETaRABsnEgA9MIVAHlWEwB5m0gA/////2hWEwB32EQAbJxIACH5BAEAAFAALAAAAABTADQA QAj/AKEIHEiwoMGDCBMqXMiwYcIhAyRgmEixIgYWD1BosAEiwoUhIIc4hBJBAQ0hK2LE0KFgZMIB Fi22ADEywoyJNA42mWARwcENGDqIJBhgKMMHMZPONFjEYgeDFlpMuJHCIA0nBkEwSTqRREEaSiIk tLB14gAoDWIuLTgkgFu3LpygYMGTKxCEBOomDWIQJgAPLgewyNHQQhAdD1hwpaiycYkEhKGAqHrw QsQJE5QUCeCys+fPoEMvHBKXAGIlJVJjXjyxBIUbKIo0sCDaJQm6rHPr5lrAAMMIRIwyHAJDL9e1 nSFgaFkwAgXMP4QLhGmRCc2BATZcT5hgN/KRRBRT/9wwGgbrB0sKQpgQOWGAG5iPEBwCJEEBFwad xNgdk4XvgQ2UUN0O6RVkgASY+XBBbdJBMcQHNORAwABERNDgQhdYoIAJTVRQgkos6ECDCxfWZuKJ KIL2AQFI8TcRC0wkkMADNNLYAgsCVlTACCRslyJBNuWoWwEuUtSCBB04QZtCCnQgAQ2UfTbEDMZR VIAPMwih5ZZc+pBEWRMl0ASXWpqXlHw/EiTDfot955AQMWRg0BAjVITCQU1RNINwRGDFUBBVKuWj QDSUwMKhK/RgkAuHLklQDxgo4ehACghZUQJiYXeDotx5N6iDKYQaZUFO5AhDiUStwFpOBDkBgAkJ of+glw0osFmRmwsFgEJSgMUaKEUrZDrQERgAwBxCH4h3p0BHPIcZrgPYWmQDBgHxawFeNYcgAGc5 dIRi1DYUbZGXZkpEaiVIEMSnJHWQIw2oNgTCBuGmudASRzTRgkqQsWsvQhd8AEQODDzQQgFEWqRS ai3ccEAOAyhgQbz/VmzxxRhn7FAALjQAxA5CyMAADEmUnIQOKHRQxAAcLaixSwE0kMOX5LLWgg4k BPfyQBc4cYB4uSUggRBBsIyDBREsofTSFuBgwwBFzDBCdy/OcOy/R5hpsxAEEDDDAUnc8MAKZD9w gwQ6COEBEDZMrNAFRARRAQVC/HfiESv8WrN3OBf/iJAFJCCAH2hDdKD33kUuazEB0lZEgbAPgVDE A5itwFlzVFd0g8sEEdFtbQYoYbO/CeW1uUE2WGodVC1MhALnUKTQA8UANq4W6WOxAMNBNGAWn0Ep 3GBRtgMNgKZC5+qG6xIf4OC83wSlNcNBVE5QxEEMJNWeQA4IsZAOnhpEgkXTF2TBcz6x9cABP+l9 vEAo6KBQ5qP3ZfYNDn/qgugYfD4QSAbZweGu16oY2CAhrVMe7hIiBIqU4IALoc5i6iUQIMRgewVp 0UWaYCkjLdAgF0iCcZRgt4P0oIMW2QFbbvCqhPSOIgoAgRKqhKuEKEBrFrEcQvbHGh4YRAcxYALk /wxyk4kQUDC3+lQDEoC/G6wATKwZQYOWkIBfxWAH0gHBvlgAPbxgJgF+MwD4MIAr/exNcQIZgkRi UgFOAWkEE4iBUBxChBnKz3wkmJRAzLg3AhBkV0bKQQkH4oQqxmAGsPNWDH6QSIQMAACIwwABWZQD G1zoAkBo0Q8gGBob3ABWDkkBCBQwABJ4QAU+0IEqdXAAtRWBbS5YQrwiQIMfYEYJORgcii5whCGS JIa0GwlpBiCEBCwMBgPw5css4IQmwKACN4CBEHJQBCMcoQHYxKYTjFCEHAghCSsoQGOYAAMCNOCD O6tMBFygABs4wQRAiGcInBfLRqbznvjMZ4oCAgA7 --0__=4EBBF156DFB715BF8f9e8a93df938690918c4EBBF156DFB715BF Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <2__=4EBBF156DFB715BF(a)pensionsversicherung.at> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=4EBBF156DFB715BF8f9e8a93df938690918c4EBBF156DFB715BF--

1 0

Re: (ITS#7625) ppolicy doesn't support changing olcPasswordHash without restart
by hyc＠symas.com 10 Aug '13

10 Aug '13

joke(a)seiken.de wrote: > Full_Name: Joke de Buhr > Version: 2.4.35 > OS: fedora 18 64bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (37.5.143.82) > > > While using the password policy overlay changing the parameter olcPasswordHash > causes an error upon password update. Unable to reproduce the issue here. Please post your complete slapd configuration, sample LDIF, and the exact commandlines you issued to demonstrate the problem. > > When changing the password via ldappasswd after changing the parameter > olcPasswordHash the error > > Constraint violation (19) Password policy only allows one password value > > if returned to the client. Changing the password isn't possible until slapd is > restarted. After restarting slapd changing the password works again. > > > > Please refer to my postings [1] on the mailing list. > > [1] http://www.openldap.org/lists/openldap-technical/201306/msg00122.html > > -- -- 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#7662) dangling reader in back-mdb
by hyc＠OpenLDAP.org 10 Aug '13

10 Aug '13

Full_Name: Howard Chu Version: 2.4.35 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc mdb_entry_get() acquires a reader txn to retrieve the specified entry, and mdb_entry_release() releases the reader txn. If mdb_entry_get() fails (e.g., the specified entry doesn't exist) then mdb_entry_release() doesn't get called. A fix will be committed shortly.

1 0

Re: (ITS#7660) LMDB: Proposing a small addition to the API: mdb_txn_env
by h.b.furuseth＠usit.uio.no 10 Aug '13

10 Aug '13

Salvador Ortiz <sog(a)msg.com.mx> writes: > I want to avoid as much as possible the need to duplicate LMDB's state in perl, > in particular dbi's flags, so I need a method to obtain the MDB_env from a > MDB_txn, but the required API is missing. > > In the same spirit of mdb_cursor_txn or mdb_cursor_dbi I propose adding > mdb_txn_env. Maybe there should be an mdb_txn_info() function instead: typedef struct MDB_txninfo { int mt_lib_version; /* library version, set by liblmdb */ MDB_env *mt_env; } MDB_txninfo; #define mdb_txn_info(txn, ti) mdb_txn_xinfo(txn, ti, MDB_VERSION_FULL) int mdb_txn_xinfo(MDB_txn *txn, MDB_txninfo *ti, int api_version); The version parameter is so we can extend MDB_txninfo later, and liblmdb will know how much of MDB_txninfo it can fill in. The caller can zero out the txninfo before the call, so he'll be prepared if an older liblmdb does not support and set all fields. -- Hallvard

1 0

Re: (ITS#7656) Build: Installing LMDB on OS X
by hyc＠symas.com 10 Aug '13

10 Aug '13

john(a)jahewson.com wrote: > Full_Name: John Hewson > Version: 2.4.35 > OS: OS X 10.8.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.175.89.135) > > > I can't install liblmdb on OS X because its Makefile assumes that cp can > handle multiple source files, rather than the basic POSIX cp, which can't. > This leads to the situation on OS X where: > > cp source1 source2 dest > > throws an error. Thanks for the report, fixed in mdb.master > > The breaks the LMDB Makefile, because its install attempts to do: > > ILIBS = liblmdb.a liblmdb.so > ... > cp $(IPROGS) $(DESTDIR)$(prefix)/bin > > Most makefiles I've encountered use a for loop for copying multiple files, > so the fix for the Makefile is to change `install` to: > > install: $(ILIBS) $(IPROGS) $(IHDRS) > for f in $(IPROGS); do cp $$f $(DESTDIR)$(prefix)/bin; done > for f in $(ILIBS); do cp $$f $(DESTDIR)$(prefix)/lib; done > for f in $(IHDRS); do cp $$f $(DESTDIR)$(prefix)/include; done > for f in $(IDOCS); do cp $$f $(DESTDIR)$(prefix)/man/man1; done > > Then LMDB builds and installs successfully on OS X. > > -- -- 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#7660) LMDB: Proposing a small addition to the API: mdb_txn_env
by hyc＠symas.com 10 Aug '13

10 Aug '13

sog(a)msg.com.mx wrote: > Full_Name: Salvador Ortiz > Version: 24 > OS: Linux > URL: ftp://ftp.msg.com.mx/pub/varios/Add-mdb_txn_env-to-API.patch > Submission from: (NULL) (187.162.45.111) > > > I'm writing from scratch a wrapper of LMDB for the Perl language, the project is > progressing fast and looks very promising. Thank you for a wonderful library! > > I want to avoid as much as possible the need to duplicate LMDB's state in perl, > in particular dbi's flags, so I need a method to obtain the MDB_env from a > MDB_txn, but the required API is missing. > > In the same spirit of mdb_cursor_txn or mdb_cursor_dbi I propose adding > mdb_txn_env. Looks fine, thanks. In mdb.master. > > Provided a patch against gitorious mdb.master. > > Any comments or questions more than welcome. > > Regards. > > Salvador > > -- -- 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#7661) LMDB: Can't get the current flags of MAIN_DBI
by hyc＠symas.com 10 Aug '13

10 Aug '13

sog(a)msg.com.mx wrote: > Full_Name: Salvador Ortiz > Version: 24 > OS: Linux > URL: > Submission from: (NULL) (187.162.45.111) > > > The API allows to set the flags of the unnamed db (MAIN_DBI), but try to get > them back fails with EINVAL. > > The fix is trivial: Thanks, fixed in mdb.master > --- a/libraries/liblmdb/mdb.c > +++ b/libraries/liblmdb/mdb.c > @@ -7871,7 +7871,7 @@ void mdb_dbi_close(MDB_env *env, MDB_dbi dbi) > int mdb_dbi_flags(MDB_env *env, MDB_dbi dbi, unsigned int *flags) > { > /* We could return the flags for the FREE_DBI too but what's the point? > */ > - if (dbi <= MAIN_DBI || dbi >= env->me_numdbs) > + if (dbi < MAIN_DBI || dbi >= env->me_numdbs) > return EINVAL; > *flags = env->me_dbflags[dbi]; > return MDB_SUCCESS; > > -- -- 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#7661) LMDB: Can't get the current flags of MAIN_DBI
by sog＠msg.com.mx 09 Aug '13

09 Aug '13

Full_Name: Salvador Ortiz Version: 24 OS: Linux URL: Submission from: (NULL) (187.162.45.111) The API allows to set the flags of the unnamed db (MAIN_DBI), but try to get them back fails with EINVAL. The fix is trivial: --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -7871,7 +7871,7 @@ void mdb_dbi_close(MDB_env *env, MDB_dbi dbi) int mdb_dbi_flags(MDB_env *env, MDB_dbi dbi, unsigned int *flags) { /* We could return the flags for the FREE_DBI too but what's the point? */ - if (dbi <= MAIN_DBI || dbi >= env->me_numdbs) + if (dbi < MAIN_DBI || dbi >= env->me_numdbs) return EINVAL; *flags = env->me_dbflags[dbi]; return MDB_SUCCESS;

1 0

Re: (ITS#7660) LMDB: Proposing a small addition to the API: mdb_txn_env
by sog＠msg.com.mx 09 Aug '13

09 Aug '13

Sure! In fact I want the module to become the "oficial" Perl's LMDB module. Right now I'm writing an extensive test battery that is uncovering some bad assumptions, undocumented features, and/or bugs in the library. Please expect the announce of an alpha release early in the next week in openldap-devel. I'm Just waiting for a version of LMDB in git with the issues solved. Salvador. On 08/09/2013 05:55 PM, Quanah Gibson-Mount wrote: > > Will you be publishing the module on CPAN? > > --Quanah > >

1 0

Re: (ITS#7660) LMDB: Proposing a small addition to the API: mdb_txn_env
by quanah＠zimbra.com 09 Aug '13

09 Aug '13

--On August 9, 2013 5:18:57 PM +0000 sog(a)msg.com.mx wrote: > Any comments or questions more than welcome. Will you be publishing the module on CPAN? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7660) LMDB: Proposing a small addition to the API: mdb_txn_env
by sog＠msg.com.mx 09 Aug '13

09 Aug '13

Full_Name: Salvador Ortiz Version: 24 OS: Linux URL: ftp://ftp.msg.com.mx/pub/varios/Add-mdb_txn_env-to-API.patch Submission from: (NULL) (187.162.45.111) I'm writing from scratch a wrapper of LMDB for the Perl language, the project is progressing fast and looks very promising. Thank you for a wonderful library! I want to avoid as much as possible the need to duplicate LMDB's state in perl, in particular dbi's flags, so I need a method to obtain the MDB_env from a MDB_txn, but the required API is missing. In the same spirit of mdb_cursor_txn or mdb_cursor_dbi I propose adding mdb_txn_env. Provided a patch against gitorious mdb.master. Any comments or questions more than welcome. Regards. Salvador

1 0

Re: (ITS#7659) slapd refuses caseIgnoreMatch for Country String
by hyc＠symas.com 09 Aug '13

09 Aug '13

cyrille.maucci(a)hp.com wrote: > Full_Name: Cyrille MAUCCI > Version: 2.4.32 > OS: RHEL5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (15.203.169.125) > > > Hello openldap'ers, > > > as a follow-up of our discussion on > http://www.openldap.org/lists/openldap-technical/201307/msg00042.html, I'm > creating an ITS to track the fact that slapd seems to refuse caseIgnoreMatch > matching rule for Country String. Fixed now in master. > > Initial description of the bug can be found hereafter, to which Howard are > ack'ed > > "Looks like a bug, schema_init.c doesn't list Country String as a compatible > syntax here. You should submit an ITS for this." > > > Many thanks in advance > ++Cyrille > > > BUG DESCRIPTION: > > When I have this piece of schema included in my slapd.conf file… > > > > attributetype ( 1.3.6.1.4.1.11.11.1.1.1.1.402 > > NAME ( 'TestCountryString' 'TestCountryStringSyn' ) > > DESC 'Test Country String' > > EQUALITY caseIgnoreMatch > > ORDERING caseIgnoreOrderingMatch > > SUBSTR caseIgnoreSubstringsMatch > > SYNTAX 1.3.6.1.4.1.1466.115.121.1.11 > > SINGLE-VALUE ) > > > > … my 2.4.32 slapd –Tt complains with this error: > > > > line 8 attributetype: AttributeType inappropriate matching rule: > "caseIgnoreMatch". > > > > > > My understanding of http://tools.ietf.org/html/rfc4517 is that caseIgnoreMatch > is valid for country string: > > > > "The caseIgnoreMatch rule compares an assertion value of the Directory > > String syntax to an attribute value of a syntax (e.g., the Directory > > String, Printable String, Country String, or Telephone Number syntax) > > whose corresponding ASN.1 type is DirectoryString or one of its > > alternative string types. > > " > > > > > > Could you confirm whether this is a bug in openldap or simply a misunderstanding > from me ? > > > -- -- 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#7659) slapd refuses caseIgnoreMatch for Country String
by cyrille.maucci＠hp.com 09 Aug '13

09 Aug '13

Full_Name: Cyrille MAUCCI Version: 2.4.32 OS: RHEL5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (15.203.169.125) Hello openldap'ers, as a follow-up of our discussion on http://www.openldap.org/lists/openldap-technical/201307/msg00042.html, I'm creating an ITS to track the fact that slapd seems to refuse caseIgnoreMatch matching rule for Country String. Initial description of the bug can be found hereafter, to which Howard are ack'ed "Looks like a bug, schema_init.c doesn't list Country String as a compatible syntax here. You should submit an ITS for this." Many thanks in advance ++Cyrille BUG DESCRIPTION: When I have this piece of schema included in my slapd.conf file… attributetype ( 1.3.6.1.4.1.11.11.1.1.1.1.402 NAME ( 'TestCountryString' 'TestCountryStringSyn' ) DESC 'Test Country String' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.11 SINGLE-VALUE ) … my 2.4.32 slapd –Tt complains with this error: line 8 attributetype: AttributeType inappropriate matching rule: "caseIgnoreMatch". My understanding of http://tools.ietf.org/html/rfc4517 is that caseIgnoreMatch is valid for country string: "The caseIgnoreMatch rule compares an assertion value of the Directory String syntax to an attribute value of a syntax (e.g., the Directory String, Printable String, Country String, or Telephone Number syntax) whose corresponding ASN.1 type is DirectoryString or one of its alternative string types. " Could you confirm whether this is a bug in openldap or simply a misunderstanding from me ?

1 0

Re: (ITS#7658) LMDB: Crash when mdb_del should ignore data, back trace and patch provided
by hyc＠symas.com 09 Aug '13

09 Aug '13

sog(a)msg.com.mx wrote: > Full_Name: Salvador Ortiz > Version: 24 > OS: Linux > URL: ftp://ftp.msg.com.mx/pub/varios/mdb_del-must-ignore-data.patch > Submission from: (NULL) (187.162.45.111) > > > According to the documentation, mdb_del should ignore the data parameter if the > dbi was not opened with MDB_DUPSORT, but this check is missing causing a > segfault deep in mdb_cursor_set when a NULL dcmp is called. > > I discovered this in the following back trace: > > #0 0x0000000000000000 in ?? () > #1 0x00007ffff1080f69 in mdb_cursor_set (mc=mc@entry=0x7fffffffd220, > key=key@entry=0x7fffffffd5f0, data=0x7fffffffd210, op=MDB_GET_BOTH, > exactp=exactp@entry=0x7fffffffd20c) at mdb.c:5149 > #2 0x00007ffff10862af in mdb_del (txn=txn@entry=0xe60a10, dbi=1, > key=key@entry=0x7fffffffd5f0, data=data@entry=0x7fffffffd600) at mdb.c:7164 > ... > > A simple patch against gitorious's mdb.master provided. Thanks, committed. -- -- 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#7658) LMDB: Crash when mdb_del should ignore data, back trace and patch provided
by sog＠msg.com.mx 09 Aug '13

09 Aug '13

Full_Name: Salvador Ortiz Version: 24 OS: Linux URL: ftp://ftp.msg.com.mx/pub/varios/mdb_del-must-ignore-data.patch Submission from: (NULL) (187.162.45.111) According to the documentation, mdb_del should ignore the data parameter if the dbi was not opened with MDB_DUPSORT, but this check is missing causing a segfault deep in mdb_cursor_set when a NULL dcmp is called. I discovered this in the following back trace: #0 0x0000000000000000 in ?? () #1 0x00007ffff1080f69 in mdb_cursor_set (mc=mc@entry=0x7fffffffd220, key=key@entry=0x7fffffffd5f0, data=0x7fffffffd210, op=MDB_GET_BOTH, exactp=exactp@entry=0x7fffffffd20c) at mdb.c:5149 #2 0x00007ffff10862af in mdb_del (txn=txn@entry=0xe60a10, dbi=1, key=key@entry=0x7fffffffd5f0, data=data@entry=0x7fffffffd600) at mdb.c:7164 ... A simple patch against gitorious's mdb.master provided.

1 0

Re: (ITS#7657) Alias dereferencing with MDB slow compared with BDB
by quanah＠zimbra.com 08 Aug '13

08 Aug '13

--On August 8, 2013 5:12:50 PM +0100 Mark Cairney <Mark.Cairney(a)ed.ac.uk> wrote: > Hi Quanah, > > I've transferred one of the nodes to back-hdb and the performance appears > to broadly match back-bdb. > > Is there a simple test I can perform to confirm that it is indeed using > back-hdb? > > For completeness here's the result of my timed search: > > bash-4.1$ time ldapsearch -H ldaps://rowan.authorise.is.ed.ac.uk:636 -b > 'ou=staff,ou=law,ou=hss,dc=authorise,dc=ed,dc=ac,dc=uk' -a always > "(&(eduniSchoolCode=S26)(eduniCategory=101)(eduniIDStatus=300))" > ># numResponses: 425 ># numEntries: 424 > > real 0m0.902s > user 0m0.054s > sys 0m0.025s No, that's enough, thanks. So it is MDB specific then. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7657) Alias dereferencing with MDB slow compared with BDB
by Mark.Cairney＠ed.ac.uk 08 Aug '13

08 Aug '13

Hi Quanah, I've transferred one of the nodes to back-hdb and the performance appears to broadly match back-bdb. Is there a simple test I can perform to confirm that it is indeed using back-hdb? For completeness here's the result of my timed search: bash-4.1$ time ldapsearch -H ldaps://rowan.authorise.is.ed.ac.uk:636 -b 'ou=staff,ou=law,ou=hss,dc=authorise,dc=ed,dc=ac,dc=uk' -a always "(&(eduniSchoolCode=S26)(eduniCategory=101)(eduniIDStatus=300))" # numResponses: 425 # numEntries: 424 real 0m0.902s user 0m0.054s sys 0m0.025s On 08/08/13 16:45, Quanah Gibson-Mount wrote: > --On August 8, 2013 4:34:32 PM +0100 Mark Cairney > <Mark.Cairney(a)ed.ac.uk> wrote: > > >>> back-bdb or back-hdb? "BDB" is just the storage database for those two >>> backends. >> >> >> back-bdb. > > Thanks. I would note that back-mdb is based on back-hdb, and that can > have significant differences in performance profile for some operations > as compared to back-bdb. If it were possible, I'd be curious to know if > you see the same issue with back-hdb as you do with back-mdb. > > --Quanah > -- /**************************** Mark Cairney ITI UNIX Section Information Services University of Edinburgh Tel: 0131 650 6565 Email: Mark.Cairney(a)ed.ac.uk *******************************/ The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#7657) Alias dereferencing with MDB slow compared with BDB
by quanah＠zimbra.com 08 Aug '13

08 Aug '13

--On August 8, 2013 4:34:32 PM +0100 Mark Cairney <Mark.Cairney(a)ed.ac.uk> wrote: >> back-bdb or back-hdb? "BDB" is just the storage database for those two >> backends. > > > back-bdb. Thanks. I would note that back-mdb is based on back-hdb, and that can have significant differences in performance profile for some operations as compared to back-bdb. If it were possible, I'd be curious to know if you see the same issue with back-hdb as you do with back-mdb. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7657) Alias dereferencing with MDB slow compared with BDB
by Mark.Cairney＠ed.ac.uk 08 Aug '13

08 Aug '13

On 08/08/13 16:27, Howard Chu wrote: > > How many aliases? > In that OU 435, in total across the whole database: 29179. -- /**************************** Mark Cairney ITI UNIX Section Information Services University of Edinburgh Tel: 0131 650 6565 Email: Mark.Cairney(a)ed.ac.uk *******************************/ The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#7657) Alias dereferencing with MDB slow compared with BDB
by Mark.Cairney＠ed.ac.uk 08 Aug '13

08 Aug '13

On 08/08/13 16:32, Quanah Gibson-Mount wrote: > > > --On August 8, 2013 3:02:51 PM +0000 Mark.Cairney(a)ed.ac.uk wrote: > >> Full_Name: Mark Cairney >> Version: 2.4.35-RE24 >> OS: SL 6.4 64-bit >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (129.215.200.23) >> >> >> Having migrated the database of our production service running 2.4.35 >> from BDB to MDB alias de-referencing stopped working completely (this has >> already been reported in ITS# 7557). > > back-bdb or back-hdb? "BDB" is just the storage database for those two > backends. back-bdb. > > Thanks, > Quanah > -- /**************************** Mark Cairney ITI UNIX Section Information Services University of Edinburgh Tel: 0131 650 6565 Email: Mark.Cairney(a)ed.ac.uk *******************************/ The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#7657) Alias dereferencing with MDB slow compared with BDB
by quanah＠zimbra.com 08 Aug '13

08 Aug '13

--On August 8, 2013 3:02:51 PM +0000 Mark.Cairney(a)ed.ac.uk wrote: > Full_Name: Mark Cairney > Version: 2.4.35-RE24 > OS: SL 6.4 64-bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (129.215.200.23) > > > Having migrated the database of our production service running 2.4.35 > from BDB to MDB alias de-referencing stopped working completely (this has > already been reported in ITS# 7557). back-bdb or back-hdb? "BDB" is just the storage database for those two backends. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7657) Alias dereferencing with MDB slow compared with BDB
by hyc＠symas.com 08 Aug '13

08 Aug '13

Mark.Cairney(a)ed.ac.uk wrote: > Full_Name: Mark Cairney > Version: 2.4.35-RE24 > OS: SL 6.4 64-bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (129.215.200.23) > > > Having migrated the database of our production service running 2.4.35 from BDB > to MDB alias de-referencing stopped working completely (this has already been > reported in ITS# 7557). > > Upgrading to the RE 24 now has alias derefencing working but it is considerably > slower than BDB was for the same search. > > To confirm this I downgraded one of our nodes (we run 4 nodes in multi-master) > and on that node the search results are once more acceptable: > > With MDB: > time ldapsearch -H ldaps://alder.authorise.is.ed.ac.uk:636 -b > 'ou=staff,ou=law,ou=hss,dc=authorise,dc=ed,dc=ac,dc=uk' -a always > "(&(eduniSchoolCode=S26)(eduniCategory=101)(eduniIDStatus=300))" > > # numResponses: 425 > # numEntries: 424 > > real 0m26.490s > user 0m0.028s > sys 0m0.032s > > > with BDB: > > time ldapsearch -H ldaps://oak.authorise.is.ed.ac.uk:636 -b > 'ou=staff,ou=law,ou=hss,dc=authorise,dc=ed,dc=ac,dc=uk' -a always > "(&(eduniSchoolCode=S26)(eduniCategory=101)(eduniIDStatus=300))" > > real 0m2.605s > user 0m0.054s > sys 0m0.006s > > If there's anything additional I can supply (log files, strace output) let me > know. > > Our OpenLDAP DB currently has around 400,000 user accounts if that's relevant. How many aliases? -- -- 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#7657) Alias dereferencing with MDB slow compared with BDB
by Mark.Cairney＠ed.ac.uk 08 Aug '13

08 Aug '13

Full_Name: Mark Cairney Version: 2.4.35-RE24 OS: SL 6.4 64-bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.215.200.23) Having migrated the database of our production service running 2.4.35 from BDB to MDB alias de-referencing stopped working completely (this has already been reported in ITS# 7557). Upgrading to the RE 24 now has alias derefencing working but it is considerably slower than BDB was for the same search. To confirm this I downgraded one of our nodes (we run 4 nodes in multi-master) and on that node the search results are once more acceptable: With MDB: time ldapsearch -H ldaps://alder.authorise.is.ed.ac.uk:636 -b 'ou=staff,ou=law,ou=hss,dc=authorise,dc=ed,dc=ac,dc=uk' -a always "(&(eduniSchoolCode=S26)(eduniCategory=101)(eduniIDStatus=300))" # numResponses: 425 # numEntries: 424 real 0m26.490s user 0m0.028s sys 0m0.032s with BDB: time ldapsearch -H ldaps://oak.authorise.is.ed.ac.uk:636 -b 'ou=staff,ou=law,ou=hss,dc=authorise,dc=ed,dc=ac,dc=uk' -a always "(&(eduniSchoolCode=S26)(eduniCategory=101)(eduniIDStatus=300))" real 0m2.605s user 0m0.054s sys 0m0.006s If there's anything additional I can supply (log files, strace output) let me know. Our OpenLDAP DB currently has around 400,000 user accounts if that's relevant.

1 0

Re: (ITS#7645) various TLSProtocolMin issues
by guenther＠sendmail.com 07 Aug '13

07 Aug '13

[Post-facto. Howard has already committed this] I believe there's two other doc changes that should be added for this: 1) syncrepl accepts tls_protocol_min as a suboption too, 2) for consistency, perhaps slapd-ldap(5) and slapd-meta(5) should use the same <major>[.<minor>] syntax for the value as ldap.conf(5) and slapd.conf(5) ? First two chunks below are for (1), second two for (2). Philip Guenther diff --git a/doc/man/man5/slapd-config.5 b/doc/man/man5/slapd-config.5 index af8beb3..2f8e656 100644 --- a/doc/man/man5/slapd-config.5 +++ b/doc/man/man5/slapd-config.5 @@ -1786,6 +1786,7 @@ FALSE, meaning the contextCSN is stored in the context entry. .B [tls_reqcert=never|allow|try|demand] .B [tls_ciphersuite=<ciphers>] .B [tls_crlcheck=none|peer|all] +.B [tls_protocol_min=<major>[.<minor>]] .B [suffixmassage=<real DN>] .B [logbase=<base DN>] .B [logfilter=<filter str>] diff --git a/doc/man/man5/slapd.conf.5 b/doc/man/man5/slapd.conf.5 index 70116df..8840e3a 100644 --- a/doc/man/man5/slapd.conf.5 +++ b/doc/man/man5/slapd.conf.5 @@ -1763,6 +1763,7 @@ the contextCSN is stored in the context entry. .B [tls_reqcert=never|allow|try|demand] .B [tls_ciphersuite=<ciphers>] .B [tls_crlcheck=none|peer|all] +.B [tls_protocol_min=<major>[.<minor>]] .B [suffixmassage=<real DN>] .B [logbase=<base DN>] .B [logfilter=<filter str>] diff --git a/doc/man/man5/slapd-ldap.5 b/doc/man/man5/slapd-ldap.5 index 98969e0..8df818c 100644 --- a/doc/man/man5/slapd-ldap.5 +++ b/doc/man/man5/slapd-ldap.5 @@ -114,7 +114,7 @@ needs to be created. .B [tls_cacertdir=<path>] .B [tls_reqcert=never|allow|try|demand] .B [tls_ciphersuite=<ciphers>] -.B [tls_protocol_min=<version>] +.B [tls_protocol_min=<major>[.<minor>]] .B [tls_crlcheck=none|peer|all] .RS Allows to define the parameters of the authentication method that is diff --git a/doc/man/man5/slapd-meta.5 b/doc/man/man5/slapd-meta.5 index a4020b5..9a326d5 100644 --- a/doc/man/man5/slapd-meta.5 +++ b/doc/man/man5/slapd-meta.5 @@ -381,7 +381,7 @@ for details on the syntax of this field. .B [tls_cacertdir=<path>] .B [tls_reqcert=never|allow|try|demand] .B [tls_ciphersuite=<ciphers>] -.B [tls_protocol_min=<version>] +.B [tls_protocol_min=<major>[.<minor>]] .B [tls_crlcheck=none|peer|all] .RS Allows to define the parameters of the authentication method that is

1 0

Re: (ITS#7653) Test Build Version 2.4.36 hangs
by quanah＠zimbra.com 07 Aug '13

07 Aug '13

--On July 31, 2013 6:51:18 AM +0000 howard.allison(a)pensionsversicherung.at wrote: > Full_Name: Howard Allison > Version: 2.4.36 > OS: AIX > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.153.217.248) > > > AIX 6.1 Using IBM VAC Compiler > Configure and Build works, test hangs at test005 Hi, thanks for the report. Unfortunately, your stack trace only shows a single thread out of multiple threads. This thread is waiting on another thread to complete a task. Please submit a full backtrace of all threads. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7656) Build: Installing LMDB on OS X
by john＠jahewson.com 05 Aug '13

05 Aug '13

Full_Name: John Hewson Version: 2.4.35 OS: OS X 10.8.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.175.89.135) I can't install liblmdb on OS X because its Makefile assumes that cp can handle multiple source files, rather than the basic POSIX cp, which can't. This leads to the situation on OS X where: cp source1 source2 dest throws an error. The breaks the LMDB Makefile, because its install attempts to do: ILIBS = liblmdb.a liblmdb.so ... cp $(IPROGS) $(DESTDIR)$(prefix)/bin Most makefiles I've encountered use a for loop for copying multiple files, so the fix for the Makefile is to change `install` to: install: $(ILIBS) $(IPROGS) $(IHDRS) for f in $(IPROGS); do cp $$f $(DESTDIR)$(prefix)/bin; done for f in $(ILIBS); do cp $$f $(DESTDIR)$(prefix)/lib; done for f in $(IHDRS); do cp $$f $(DESTDIR)$(prefix)/include; done for f in $(IDOCS); do cp $$f $(DESTDIR)$(prefix)/man/man1; done Then LMDB builds and installs successfully on OS X.

1 0

Re: (ITS#7655) segfault during initial mirror of multimaster delta replication
by quanah＠zimbra.com 04 Aug '13

04 Aug '13

--On Sunday, August 04, 2013 4:27 PM +0000 hans.freitag(a)entiretec.com wrote: > Full_Name: Hans Freitag > Version: 2.4.35 and 33 > OS: SLES 11SP2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.200.138.3) > > > I have a Multimaster Delta replication setup here with bdb on a 18 GB > Database. > > After a crash due to a full disk I made a new database on one node ans > started over. > > The empty node started to replicate, from the full one but after a while > (approx. 2GB) it crashed with a segfault: > > Aug 4 11:45:32 mhr-dd-lda-01 kernel: [52189.476209] slapd[10158]: > segfault at 20 ip 00007ff97ebfabc0 sp 00007ff6e57e6b38 error 4 in > libc-2.11.1.so[7ff97eb79000+155000] > > So i thought, maybe it is not e good Idea to put in a package for SP2 in a > machine running SP1 so my first attempt to solve was an upgrade. After the > upgrade I got this: > > Aug 4 12:46:29 mhr-dd-lda-01 kernel: [ 1414.757587] slapd[3704]: > segfault at 20 ip 00007fc82eee6182 sp 00007fc592e0acf0 error 4 in > slapd[7fc82ee7a000+1e6000] > > So I created a brandnew openldap RPM 2.4.35 rpm to try out if the problem > is maybe related to the 2.4.33 version I am running. But fail: > > Aug 4 13:47:19 mhr-dd-lda-01 kernel: [ 5063.074410] slapd[8749]: > segfault at 20 ip 00007fcbc1b537dc sp 00007fc92624fb88 error 4 in > slapd[7fcbc1ac8000+1ea000] > > At the moment I deactivated the accesslogging on the node which seems to > work. I will know for sure in a few hours. ;-) I can try to reproduce > that on a backup node next week. Whenn all the main nodes are up and > running again. :) I would suggest you build with debugging symbols, enable core files, and provide a backtrace of the problem. What you have provided does not give any useful information for debugging purposes. You also fail to state the backend you are using (back-bdb or back-hdb). For information on how to provide a backtrace: <http://www.openldap.org/faq/data/cache/59.html> Regards, Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7655) segfault during initial mirror of multimaster delta replication
by hans.freitag＠entiretec.com 04 Aug '13

04 Aug '13

Full_Name: Hans Freitag Version: 2.4.35 and 33 OS: SLES 11SP2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.200.138.3) I have a Multimaster Delta replication setup here with bdb on a 18 GB Database. After a crash due to a full disk I made a new database on one node ans started over. The empty node started to replicate, from the full one but after a while (approx. 2GB) it crashed with a segfault: Aug 4 11:45:32 mhr-dd-lda-01 kernel: [52189.476209] slapd[10158]: segfault at 20 ip 00007ff97ebfabc0 sp 00007ff6e57e6b38 error 4 in libc-2.11.1.so[7ff97eb79000+155000] So i thought, maybe it is not e good Idea to put in a package for SP2 in a machine running SP1 so my first attempt to solve was an upgrade. After the upgrade I got this: Aug 4 12:46:29 mhr-dd-lda-01 kernel: [ 1414.757587] slapd[3704]: segfault at 20 ip 00007fc82eee6182 sp 00007fc592e0acf0 error 4 in slapd[7fc82ee7a000+1e6000] So I created a brandnew openldap RPM 2.4.35 rpm to try out if the problem is maybe related to the 2.4.33 version I am running. But fail: Aug 4 13:47:19 mhr-dd-lda-01 kernel: [ 5063.074410] slapd[8749]: segfault at 20 ip 00007fcbc1b537dc sp 00007fc92624fb88 error 4 in slapd[7fcbc1ac8000+1ea000] At the moment I deactivated the accesslogging on the node which seems to work. I will know for sure in a few hours. ;-) I can try to reproduce that on a backup node next week. Whenn all the main nodes are up and running again. :)

1 0

ITS#7599 libldap and libclntsh
by hyc＠symas.com 02 Aug '13

02 Aug '13

This is an Oracle bug, please contact Oracle for a fix. Their library should not be exporting symbols from the ldap_* namespace; this space has been owned by libldap since the 1990s. Closing this ITS. -- -- 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#7654) [PATCH] back-meta/config.c: #include "ldif.h"
by fumiyas＠osstech.co.jp 02 Aug '13

02 Aug '13

Full_Name: SATOH Fumiyasu Version: master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (240b:10:2640:bf0:222:5fff:fe95:3cda) >From 9d009b4890586354e94be92f4ddb2462e9d18158 Mon Sep 17 00:00:00 2001 From: SATOH Fumiyasu <fumiyas(a)osstech.co.jp> Date: Fri, 2 Aug 2013 18:20:05 +0900 Subject: [PATCH] back-meta/config.c: #include "ldif.h" --- servers/slapd/back-meta/config.c | 1 + 1 file changed, 1 insertion(+) diff --git a/servers/slapd/back-meta/config.c b/servers/slapd/back-meta/config.c index 0be9ed8..a23f5ef 100644 --- a/servers/slapd/back-meta/config.c +++ b/servers/slapd/back-meta/config.c @@ -30,6 +30,7 @@ #include "slap.h" #include "config.h" #include "lutil.h" +#include "ldif.h" #include "../back-ldap/back-ldap.h" #include "back-meta.h" -- 1.8.3.2

1 0

Re: (ITS#7651) LMDB: Uncontrolled database when opened from multiple processes
by h.b.furuseth＠usit.uio.no 01 Aug '13

01 Aug '13

Howard Chu writes: > h.b.furuseth(a)usit.uio.no wrote: >> I'd call this two doc bugs: >> >> Something should mention that once a page has been used, the file will >> never shrink below that page. (Can't quite say that the file never >> shrinks, since WRITEMAP and Windows will set it to exact re-configurable >> mapsize in some cases. If I remember correctly.) > > You cannot shrink the mapsize below that last used page, and the last used > page is a non-decreasing number. Yes. Duh, that's already roughly stated under mdb_env_set_mapsize(). >> mdb_env_copy() and mdb_env_copyfd() should document that >> >> @node This call can trigger siginficant file size growth if run in >> parallel with write transactions, because it employs a read-only >> transaction. See long-lived transactions under Caveats. I'll add this one though. >> I wonder that means these functions should have a flag parameter. >> For some databases, users might prefer a _write_ transaction while >> reading the DB, blocking writes while copying. > > No one has ever wanted a hot-backup function that halts writes. You > might as well not do a hot-backup at all. Yes, nevermind about a mdb_env_copy() flag. An mdb_txn_begin timeout would make it a viable choice - but if that is implemented someday, those two behaviors together could go in an MDB_env flag. -- Hallvard

1 0

Re: (ITS#7651) LMDB: Uncontrolled database when opened from multiple processes
by hyc＠symas.com 31 Jul '13

31 Jul '13

h.b.furuseth(a)usit.uio.no wrote: > I'd call this two doc bugs: > > Something should mention that once a page has been used, the file will > never shrink below that page. (Can't quite say that the file never > shrinks, since WRITEMAP and Windows will set it to exact re-configurable > mapsize in some cases. If I remember correctly.) You cannot shrink the mapsize below that last used page, and the last used page is a non-decreasing number. > mdb_env_copy() and mdb_env_copyfd() should document that > > @node This call can trigger siginficant file size growth if run in > parallel with write transactions, because it employs a read-only > transaction. See long-lived transactions under Caveats. > > I wonder that means these functions should have a flag parameter. > For some databases, users might prefer a _write_ transaction while > reading the DB, blocking writes while copying. No one has ever wanted a hot-backup function that halts writes. You might as well not do a hot-backup at all. -- -- 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#7651) LMDB: Uncontrolled database when opened from multiple processes
by h.b.furuseth＠usit.uio.no 31 Jul '13

31 Jul '13

I'd call this two doc bugs: Something should mention that once a page has been used, the file will never shrink below that page. (Can't quite say that the file never shrinks, since WRITEMAP and Windows will set it to exact re-configurable mapsize in some cases. If I remember correctly.) mdb_env_copy() and mdb_env_copyfd() should document that @node This call can trigger siginficant file size growth if run in parallel with write transactions, because it employs a read-only transaction. See long-lived transactions under Caveats. I wonder that means these functions should have a flag parameter. For some databases, users might prefer a _write_ transaction while reading the DB, blocking writes while copying. -- Hallvard

1 0

Re: (ITS#7651) LMDB: Uncontrolled database when opened from multiple processes
by hyc＠symas.com 31 Jul '13

31 Jul '13

Dimitrij Denissenko wrote: > Makes sense, but out of interest: shouldn't the file size drop again, > when locked pages are released? No. All allocated pages get reused internally, so there's no point giving them back to the OS. > > On 31/07/13 15:34, Howard Chu wrote: >> dimitrij.denissenko(a)blacksquaremedia.com wrote: >>> Hi again, >>> >>> I was able to recreate the scenario in a test case. I must have mixed >>> something up previously. After more tests it seems that the memory >>> growth only appears when transactions are reset within the child. >>> >>> Here's the full code: >>> https://gist.github.com/dim/6122131 >>> >>> Output on my machine: >>> >>> $ rm -f testdb/* && mkdir -p testdb && make mtest8 && ./mtest8 >>> gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast >>> -c mtest8.c >>> gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast >>> mtest8.o liblmdb.a -o mtest8 >>> NO FORK : 1699840 >>> FORK & OPEN : 1699840 >>> FORK & COPY : 6225920 >> >> This behavior is expected. Your child process is holding a read txn >> while it performs the env_copyfd(). During that time writers are not >> able to reuse old data pages, so all writes consume new pages. When >> the copyfd completes and releases its read txn the writers will resume >> reusing old pages. >> >> There's no bug here, this ITS will be closed. >> > > -- -- 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#7651) LMDB: Uncontrolled database when opened from multiple processes
by dimitrij.denissenko＠blacksquaremedia.com 31 Jul '13

31 Jul '13

Makes sense, but out of interest: shouldn't the file size drop again, when locked pages are released? On 31/07/13 15:34, Howard Chu wrote: > dimitrij.denissenko(a)blacksquaremedia.com wrote: >> Hi again, >> >> I was able to recreate the scenario in a test case. I must have mixed >> something up previously. After more tests it seems that the memory >> growth only appears when transactions are reset within the child. >> >> Here's the full code: >> https://gist.github.com/dim/6122131 >> >> Output on my machine: >> >> $ rm -f testdb/* && mkdir -p testdb && make mtest8 && ./mtest8 >> gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast >> -c mtest8.c >> gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast >> mtest8.o liblmdb.a -o mtest8 >> NO FORK : 1699840 >> FORK & OPEN : 1699840 >> FORK & COPY : 6225920 > > This behavior is expected. Your child process is holding a read txn > while it performs the env_copyfd(). During that time writers are not > able to reuse old data pages, so all writes consume new pages. When > the copyfd completes and releases its read txn the writers will resume > reusing old pages. > > There's no bug here, this ITS will be closed. >

1 0

Re: (ITS#7651) LMDB: Uncontrolled database when opened from multiple processes
by hyc＠symas.com 31 Jul '13

31 Jul '13

dimitrij.denissenko(a)blacksquaremedia.com wrote: > Hi again, > > I was able to recreate the scenario in a test case. I must have mixed > something up previously. After more tests it seems that the memory > growth only appears when transactions are reset within the child. > > Here's the full code: > https://gist.github.com/dim/6122131 > > Output on my machine: > > $ rm -f testdb/* && mkdir -p testdb && make mtest8 && ./mtest8 > gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast > -c mtest8.c > gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast > mtest8.o liblmdb.a -o mtest8 > NO FORK : 1699840 > FORK & OPEN : 1699840 > FORK & COPY : 6225920 This behavior is expected. Your child process is holding a read txn while it performs the env_copyfd(). During that time writers are not able to reuse old data pages, so all writes consume new pages. When the copyfd completes and releases its read txn the writers will resume reusing old pages. There's no bug here, this ITS will be closed. -- -- 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#7651) LMDB: Uncontrolled database when opened from multiple processes
by dimitrij.denissenko＠blacksquaremedia.com 31 Jul '13

31 Jul '13

Hi again, I was able to recreate the scenario in a test case. I must have mixed something up previously. After more tests it seems that the memory growth only appears when transactions are reset within the child. Here's the full code: https://gist.github.com/dim/6122131 Output on my machine: $ rm -f testdb/* && mkdir -p testdb && make mtest8 && ./mtest8 gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -c mtest8.c gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast mtest8.o liblmdb.a -o mtest8 NO FORK : 1699840 FORK & OPEN : 1699840 FORK & COPY : 6225920 Thanks, Dimitrij On 30/07/13 23:34, Hallvard Breien Furuseth wrote: > Whoops, too hasty reply. Didn't notice your mdb_env_close(env) > before the fork. But do you mdb_env_create() again after? > mdb_env_close() destroys the MDB_env. >

1 0

(ITS#7653) Test Build Version 2.4.36 hangs
by howard.allison＠pensionsversicherung.at 30 Jul '13

30 Jul '13

Full_Name: Howard Allison Version: 2.4.36 OS: AIX URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.153.217.248) AIX 6.1 Using IBM VAC Compiler Configure and Build works, test hangs at test005 Stack Trace reading symbolic information ... stopped in __fd_select at 0xd0262f2c ($t2) 0xd0262f2c (__fd_select+0xcc) 80410014 lwz r2,0x14(r1) (dbx) where __fd_select(??, ??, ??, ??, ??) at 0xd0262f2c daemon.select(__fds = 0, __readlist = (nil), __writelist = (nil), __exceptlist = (nil), __timeout = (nil)), line 234 in "time.h" unnamed block in slapd_daemon_task(ptr = (nil)), line 2536 in "daemon.c" unnamed block in slapd_daemon_task(ptr = (nil)), line 2536 in "daemon.c" slapd_daemon_task(ptr = (nil)), line 2536 in "daemon.c"

1 0

Re: (ITS#7651) LMDB: Uncontrolled database when opened from multiple processes
by dimitrij.denissenko＠blacksquaremedia.com 30 Jul '13

30 Jul '13

--001a11c21408c992a604e2c913b8 Content-Type: text/plain; charset=UTF-8 Yes, sorry, my example wasn't very good. I call mdb_env_create in both, the parent and the child. I will create an mtest8.c today to illustrate the problem. On 30 Jul 2013 23:34, "Hallvard Breien Furuseth" <h.b.furuseth(a)usit.uio.no> wrote: > Whoops, too hasty reply. Didn't notice your mdb_env_close(env) > before the fork. But do you mdb_env_create() again after? > mdb_env_close() destroys the MDB_env. > > -- > Hallvard > --001a11c21408c992a604e2c913b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, sorry, my example wasn't very good. I call mdb_env_= create in both, the parent and the child. I will create an mtest8.c today t= o illustrate the problem. <div class=3D"gmail_quote">On 30 Jul 2013 23:34, "Hallvard Breien Furu= seth" <<a href=3D"mailto:h.b.furuseth@usit.uio.no">h.b.furuseth@usi= t.uio.no</a>> wrote: <blockquote class=3D"gmail_= quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1= ex"> Whoops, too hasty reply. =C2=A0Didn't notice your mdb_env_close(env)<br= > before the fork. =C2=A0But do you mdb_env_create() again after? mdb_env_close() destroys the MDB_env. -- Hallvard </blockquote></div> --001a11c21408c992a604e2c913b8--

1 0

Re: (ITS#7651) LMDB: Uncontrolled database when opened from multiple processes
by h.b.furuseth＠usit.uio.no 30 Jul '13

30 Jul '13

Whoops, too hasty reply. Didn't notice your mdb_env_close(env) before the fork. But do you mdb_env_create() again after? mdb_env_close() destroys the MDB_env. -- Hallvard

1 0

Re: (ITS#7651) LMDB: Uncontrolled database when opened from multiple processes
by h.b.furuseth＠usit.uio.no 30 Jul '13

30 Jul '13

dimitrij.denissenko(a)blacksquaremedia.com writes: > I found an interesting issue with LMDB. I have populated the DB with a bunch of > records and it uses ~30M on disk (after sync). Then I added a background process > to my app and populated the database again with the same record set. mdb_env_create(); fork(); mdb_env_open(); is invalid. An MDB_env may only be used in the process which created it. See Caveats in lmdb.h. This is because mdb_env_create() sets the pid which the MDB_env will use in the lockfile. We could delay this to mdb_env_open(), then your particular program would work but fork() after mdb_env_open() would not. But I don't see much point in doing so. -- Hallvard

1 0

Re: (ITS#7651) LMDB: Uncontrolled database when opened from multiple processes
by hyc＠symas.com 30 Jul '13

30 Jul '13

dimitrij.denissenko(a)blacksquaremedia.com wrote: > --001a11c2ed64c222e504e2c14561 > Content-Type: text/plain; charset=UTF-8 > > Hi, > > All writes occur in the parent process only. The child (normally) only > reopens the environment and performs a few short reads. > > But, it's the actual opening of the env in the forked child that is causing > the database growth. I tried to close the env straight after opening it in > the child (without performing any reads), and have encountered the same > issues. I don't see anything like that here. There's nothing in mdb_env_open(MDB_NOSYNC) that can even affect the size of the DB file. I don't think there's anything we can investigate without sample code that reproduces the situation. > > Hope that makes sense, > Dimitrij > On 30 Jul 2013 21:19, "Howard Chu" <hyc(a)symas.com> wrote: > >> dimitrij.denissenko(a)**blacksquaremedia.com<dimitrij.denissenko(a)blacksquaremedia.com>wrote: >> >>> Full_Name: Dimitrij Denissenko >>> Version: >>> OS: Ubuntu 12.04 >>> URL: >>> Submission from: (NULL) (62.30.100.0) >>> >>> >>> Hi, >>> >>> I found an interesting issue with LMDB. I have populated the DB with a >>> bunch of >>> records and it uses ~30M on disk (after sync). Then I added a background >>> process >>> to my app and populated the database again with the same record set. >>> Surprisingly. the resulting size on disk was >70M. >>> >>> The background process is forked periodically to perform some maintenance >>> tasks, >>> here is my (simplified) code: >>> >>> /* Close env before forking */ >>> mdb_env_close(env); >>> >>> if ((childpid = fork()) == 0) { >>> /* Child */ >>> rc = mdb_env_open(env, ".", MDB_NOSYNC, 0644); >>> ... >>> } else { >>> /* Parent */ >>> rc = mdb_env_open(env, ".", MDB_NOSYNC, 0644); >>> ... >>> } >>> >>> I could narrow it down to the mdb_env_open call in the child. If I add >>> exit(0) >>> before the mdb_env_open line, the DB size remains consistently at ~30M. >>> The data >>> size seems to grow proportionally to the number of forks performed during >>> data >>> load. What could be causing the growth? What can I do to prevent it? >>> >>> Thanks in advance >>> >>> PS: I tried it with MDB_FIXMAP and without, same result. >>> >> >> Without seeing more of your code, it's impossible to tell. Are you adding >> the data on both sides of the fork? In the above code snippet, where are >> your mdb_put calls occurring? Are both the parent and child processes >> writing identical data? >> >> -- >> -- 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/> >> > > --001a11c2ed64c222e504e2c14561 > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > Hi, > All writes occur in the parent process only. The child (norm= > ally) only reopens the environment and performs a few short reads. > But, it's the actual opening of the env in the forked ch= > ild that is causing the database growth. I tried to close the env straight = > after opening it in the child (without performing any reads), and have enco= > untered the same issues. > > Hope that makes sense, > Dimitrij > <div class=3D"gmail_quote">On 30 Jul 2013 21:19, "Howard Chu" &lt= > ;<a href=3D"mailto:hyc@symas.com">hyc(a)symas.com</a>> wrote: ttribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo= > rder-left:1px #ccc solid;padding-left:1ex"> > <a href=3D"mailto:dimitrij.denissenko@blacksquaremedia.com" target=3D"_blan= > k">dimitrij.denissenko@blacksquaremedia.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: Dimitrij Denissenko > Version: > OS: Ubuntu 12.04 > URL: > Submission from: (NULL) (62.30.100.0) > > > Hi, > > I found an interesting issue with LMDB. I have populated the DB with a bunc= > h of > records and it uses ~30M on disk (after sync). Then I added a background pr= > ocess > to my app and populated the database again with the same record set. > Surprisingly. the resulting size on disk was >70M. > > The background process is forked periodically to perform some maintenance t= > asks, > here is my (simplified) code: > > /* Close env before forking */ > mdb_env_close(env); > > if ((childpid =3D fork()) =3D=3D 0) { > =C2=A0 =C2=A0 =C2=A0/* Child */ > =C2=A0 =C2=A0 =C2=A0rc =3D mdb_env_open(env, ".", MDB_NOSYNC, 064= > 4); > =C2=A0 =C2=A0 =C2=A0... > } else { > =C2=A0 =C2=A0 =C2=A0/* Parent */ > =C2=A0 =C2=A0 =C2=A0rc =3D mdb_env_open(env, ".", MDB_NOSYNC, 064= > 4); > =C2=A0 =C2=A0 =C2=A0... > } > > I could narrow it down to the mdb_env_open call in the child. If I add exit= > (0) > before the mdb_env_open line, the DB size remains consistently at ~30M. The= > data > size seems to grow proportionally to the number of forks performed during d= > ata > load. What could be causing the growth? What can I do to prevent it? > > Thanks in advance > > PS: I tried it with MDB_FIXMAP and without, same result. > </blockquote> > > Without seeing more of your code, it's impossible to tell. Are you addi= > ng the data on both sides of the fork? In the above code snippet, where are= > your mdb_put calls occurring? Are both the parent and child processes writ= > ing identical data? > -- -- 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#7651) LMDB: Uncontrolled database when opened from multiple processes
by dimitrij.denissenko＠blacksquaremedia.com 30 Jul '13

30 Jul '13

--001a11c2ed64c222e504e2c14561 Content-Type: text/plain; charset=UTF-8 Hi, All writes occur in the parent process only. The child (normally) only reopens the environment and performs a few short reads. But, it's the actual opening of the env in the forked child that is causing the database growth. I tried to close the env straight after opening it in the child (without performing any reads), and have encountered the same issues. Hope that makes sense, Dimitrij On 30 Jul 2013 21:19, "Howard Chu" <hyc(a)symas.com> wrote: > dimitrij.denissenko(a)**blacksquaremedia.com<dimitrij.denissenko(a)blacksquaremedia.com>wrote: > >> Full_Name: Dimitrij Denissenko >> Version: >> OS: Ubuntu 12.04 >> URL: >> Submission from: (NULL) (62.30.100.0) >> >> >> Hi, >> >> I found an interesting issue with LMDB. I have populated the DB with a >> bunch of >> records and it uses ~30M on disk (after sync). Then I added a background >> process >> to my app and populated the database again with the same record set. >> Surprisingly. the resulting size on disk was >70M. >> >> The background process is forked periodically to perform some maintenance >> tasks, >> here is my (simplified) code: >> >> /* Close env before forking */ >> mdb_env_close(env); >> >> if ((childpid = fork()) == 0) { >> /* Child */ >> rc = mdb_env_open(env, ".", MDB_NOSYNC, 0644); >> ... >> } else { >> /* Parent */ >> rc = mdb_env_open(env, ".", MDB_NOSYNC, 0644); >> ... >> } >> >> I could narrow it down to the mdb_env_open call in the child. If I add >> exit(0) >> before the mdb_env_open line, the DB size remains consistently at ~30M. >> The data >> size seems to grow proportionally to the number of forks performed during >> data >> load. What could be causing the growth? What can I do to prevent it? >> >> Thanks in advance >> >> PS: I tried it with MDB_FIXMAP and without, same result. >> > > Without seeing more of your code, it's impossible to tell. Are you adding > the data on both sides of the fork? In the above code snippet, where are > your mdb_put calls occurring? Are both the parent and child processes > writing identical data? > > -- > -- 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/> > --001a11c2ed64c222e504e2c14561 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, All writes occur in the parent process only. The child (norm= ally) only reopens the environment and performs a few short reads. But, it's the actual opening of the env in the forked ch= ild that is causing the database growth. I tried to close the env straight = after opening it in the child (without performing any reads), and have enco= untered the same issues. Hope that makes sense, Dimitrij <div class=3D"gmail_quote">On 30 Jul 2013 21:19, "Howard Chu" &lt= ;<a href=3D"mailto:hyc@symas.com">hyc(a)symas.com</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex"> <a href=3D"mailto:dimitrij.denissenko@blacksquaremedia.com" target=3D"_blan= k">dimitrij.denissenko@blacksquaremedia.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: Dimitrij Denissenko Version: OS: Ubuntu 12.04 URL: Submission from: (NULL) (62.30.100.0) Hi, I found an interesting issue with LMDB. I have populated the DB with a bunc= h of records and it uses ~30M on disk (after sync). Then I added a background pr= ocess to my app and populated the database again with the same record set. Surprisingly. the resulting size on disk was >70M. The background process is forked periodically to perform some maintenance t= asks, here is my (simplified) code: /* Close env before forking */ mdb_env_close(env); if ((childpid =3D fork()) =3D=3D 0) { =C2=A0 =C2=A0 =C2=A0/* Child */ =C2=A0 =C2=A0 =C2=A0rc =3D mdb_env_open(env, ".", MDB_NOSYNC, 064= 4); =C2=A0 =C2=A0 =C2=A0... } else { =C2=A0 =C2=A0 =C2=A0/* Parent */ =C2=A0 =C2=A0 =C2=A0rc =3D mdb_env_open(env, ".", MDB_NOSYNC, 064= 4); =C2=A0 =C2=A0 =C2=A0... } I could narrow it down to the mdb_env_open call in the child. If I add exit= (0) before the mdb_env_open line, the DB size remains consistently at ~30M. The= data size seems to grow proportionally to the number of forks performed during d= ata load. What could be causing the growth? What can I do to prevent it? Thanks in advance PS: I tried it with MDB_FIXMAP and without, same result. </blockquote> Without seeing more of your code, it's impossible to tell. Are you addi= ng the data on both sides of the fork? In the above code snippet, where are= your mdb_put calls occurring? Are both the parent and child processes writ= ing identical data? -- =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> --001a11c2ed64c222e504e2c14561--

1 0

Re: (ITS#7651) LMDB: Uncontrolled database when opened from multiple processes
by hyc＠symas.com 30 Jul '13

30 Jul '13

dimitrij.denissenko(a)blacksquaremedia.com wrote: > Full_Name: Dimitrij Denissenko > Version: > OS: Ubuntu 12.04 > URL: > Submission from: (NULL) (62.30.100.0) > > > Hi, > > I found an interesting issue with LMDB. I have populated the DB with a bunch of > records and it uses ~30M on disk (after sync). Then I added a background process > to my app and populated the database again with the same record set. > Surprisingly. the resulting size on disk was >70M. > > The background process is forked periodically to perform some maintenance tasks, > here is my (simplified) code: > > /* Close env before forking */ > mdb_env_close(env); > > if ((childpid = fork()) == 0) { > /* Child */ > rc = mdb_env_open(env, ".", MDB_NOSYNC, 0644); > ... > } else { > /* Parent */ > rc = mdb_env_open(env, ".", MDB_NOSYNC, 0644); > ... > } > > I could narrow it down to the mdb_env_open call in the child. If I add exit(0) > before the mdb_env_open line, the DB size remains consistently at ~30M. The data > size seems to grow proportionally to the number of forks performed during data > load. What could be causing the growth? What can I do to prevent it? > > Thanks in advance > > PS: I tried it with MDB_FIXMAP and without, same result. Without seeing more of your code, it's impossible to tell. Are you adding the data on both sides of the fork? In the above code snippet, where are your mdb_put calls occurring? Are both the parent and child processes writing identical data? -- -- 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#7652) LMDB: mdb_copy fails on files > 2GB
by hyc＠symas.com 30 Jul '13

30 Jul '13

dimitrij.denissenko(a)blacksquaremedia.com wrote: > Full_Name: Dimitrij Denissenko > Version: > OS: Ubuntu 12.04 (64bit) > URL: > Submission from: (NULL) (62.30.100.0) > > > Hi, > > The latest mdb.master (acf20f7) fails on files that are larger than 2G, even on > 64bit systems. > > I could narrow it down to: Thanks for the report. The bogus parts of those commits have been reverted. > > --- a/mdb/libraries/liblmdb/mdb.c > +++ b/mdb/libraries/liblmdb/mdb.c > @@ -4070,7 +4070,7 @@ > else > w2 = wsize; > wres = write(fd, ptr, w2); > - rc = wres == (ssize_t)w2 ? MDB_SUCCESS : wres < 0 ? ErrCode() : EIO; > + rc = wres > 0 ? MDB_SUCCESS : ErrCode(); > if (rc) break; > wsize -= wres; > ptr += wres; > > After this change the environment was copied correctly. > > -- -- 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#7652) LMDB: mdb_copy fails on files > 2GB
by dimitrij.denissenko＠blacksquaremedia.com 30 Jul '13

30 Jul '13

Full_Name: Dimitrij Denissenko Version: OS: Ubuntu 12.04 (64bit) URL: Submission from: (NULL) (62.30.100.0) Hi, The latest mdb.master (acf20f7) fails on files that are larger than 2G, even on 64bit systems. I could narrow it down to: --- a/mdb/libraries/liblmdb/mdb.c +++ b/mdb/libraries/liblmdb/mdb.c @@ -4070,7 +4070,7 @@ else w2 = wsize; wres = write(fd, ptr, w2); - rc = wres == (ssize_t)w2 ? MDB_SUCCESS : wres < 0 ? ErrCode() : EIO; + rc = wres > 0 ? MDB_SUCCESS : ErrCode(); if (rc) break; wsize -= wres; ptr += wres; After this change the environment was copied correctly.

1 0

(ITS#7651) LMDB: Uncontrolled database when opened from multiple processes
by dimitrij.denissenko＠blacksquaremedia.com 30 Jul '13

30 Jul '13

Full_Name: Dimitrij Denissenko Version: OS: Ubuntu 12.04 URL: Submission from: (NULL) (62.30.100.0) Hi, I found an interesting issue with LMDB. I have populated the DB with a bunch of records and it uses ~30M on disk (after sync). Then I added a background process to my app and populated the database again with the same record set. Surprisingly. the resulting size on disk was >70M. The background process is forked periodically to perform some maintenance tasks, here is my (simplified) code: /* Close env before forking */ mdb_env_close(env); if ((childpid = fork()) == 0) { /* Child */ rc = mdb_env_open(env, ".", MDB_NOSYNC, 0644); ... } else { /* Parent */ rc = mdb_env_open(env, ".", MDB_NOSYNC, 0644); ... } I could narrow it down to the mdb_env_open call in the child. If I add exit(0) before the mdb_env_open line, the DB size remains consistently at ~30M. The data size seems to grow proportionally to the number of forks performed during data load. What could be causing the growth? What can I do to prevent it? Thanks in advance PS: I tried it with MDB_FIXMAP and without, same result.

1 0

Re: (ITS#7631) Overlay to rewrite value of attribute using regex
by bart＠icm.edu.pl 29 Jul '13

29 Jul '13

On Mon, 29 Jul 2013 08:30:23 -0700, Howard Chu wrote: > > I presume we still need a formal IPR notice in the ITS? Is it enough: The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch were developed by Dominik Bartkiewicz bart(a)icm.edu.pl. I have not assigned rights and/or interest in this work to any party. DB

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs