openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#8270) win32: fix conversion error
by hyc＠symas.com 20 Oct '15

20 Oct '15

Леонид Юрьев wrote: > 2015-10-20 23:09 GMT+03:00 <hyc(a)symas.com <mailto:hyc@symas.com>>: > > nacho.resa(a)gmail.com <mailto:nacho.resa@gmail.com> wrote: > > --047d7bb03a5ac118d20522842ead > > Content-Type: text/plain; charset=UTF-8 > > > > So I took another closer look at this issue and I went for this possible > > solution: > > > https://github.com/nice-software/lmdb/commit/03987789735141dc68ae8b2d0e5ad5… > > That looks OK. > > > Basically it errors out because MSVC needs stdcall on that method. > > You realize of course, that this change actually has no effect on the code > here? stdcall uses Pascal argument order instead of C order but it's moot > since the function only has 1 argument. > No, there is another important difference: > cdecl = the caller is responsible to clean stack from args (e.g. addl esp, N); > stdcall = the callee is responsible to clean stack from args (e.g. retn N); True, but not relevant here. This is a ThreadProc, and threads never return to their caller. Windows implicitly calls ExitThread() when this function returns, and the stack will be destroyed anyway. -- -- 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#8281) Syncrepl refresh failure when slapd is restarted midstream
by quanah＠openldap.org 20 Oct '15

20 Oct '15

Full_Name: Quanah Gibson-Mount Version: RE24 Sept 11, 2015 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) Seeing a scenario where if slapd is stopped on a new MMR node while a full REFRESH is occurring, the state of that refresh is not tracked, and the wrong CSN value is stored. This dataset has 15,000 users. We see it get up to user 625: Oct 20 16:13:09 q2 slapd[18724]: syncrepl_entry: rid=100 be_search (0) Oct 20 16:13:09 q2 slapd[18724]: syncrepl_entry: rid=100 uid=user625,ou=people,dc=q1,dc=aon,dc=zimbraview,dc=com Oct 20 16:13:09 q2 slapd[18724]: slap_queue_csn: queueing 0x44c7e30 20151020185526.862768Z#000000#000#000000 Oct 20 16:13:09 q2 slapd[18724]: slap_graduate_commit_csn: removing 0x44c87c0 20151020185526.862768Z#000000#000#000000 Oct 20 16:13:09 q2 slapd[18724]: syncrepl_entry: rid=100 be_add uid=user625,ou=people,dc=q2C2Cdc=aon,dc=zimbraview,dc=com (0) Oct 20 16:13:09 q2 slapd[18724]: slapd stopped. Then when slapd is restarted: Oct 20 16:13:16 q2 slapd[18970]: do_syncrep2: rid=100 cookie=rid=100,sid=001,csn=20151020201231.263989Z#000000#001#000000 Oct 20 16:13:16 q2 slapd[18970]: sp_p_queue_csn: queueing 0x309dfd8 20151020201231.263989Z#000000#001#000000 Oct 20 16:13:16 q2 slapd[18970]: slap_queue_csn: queueing 0x5054008 20151020201231.263989Z#000000#001#000000 Oct 20 16:13:16 q2 slapd[18970]: slap_graduate_commit_csn: removing 0x49353c0 20151020201231.263989Z#000000#001#000000 Oct 20 16:13:16 q2 slapd[18970]: slap_graduate_commit_csn: removing 0x4935060 20151020201231.263989Z#000000#001#000000 Oct 20 16:13:16 q2 slapd[18970]: syncrepl_message_to_op: rid=100 be_add cn=q2.aon.zimbraview.com,cn=servers,cn=zimbra (0) which causes it to skip the other 14,000+ users.

1 0

(ITS#8280) test056 fails due to EOL differences
by hyc＠openldap.org 20 Oct '15

20 Oct '15

Full_Name: Howard Chu Version: 2.4 OS: Win32 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.231.14) Submitted by: hyc The 2nd comparison in test056 diffs ldapsearch output against the static testdata/monitor2.out file. The output from ldapsearch contains DOS \r\n EOLs while the static file contains Unix \n EOLs and so the diff fails. In all the tests up to this point, comparisons are always between equally processed files, instead of 1 processed file and 1 static file, so there were no EOL differences to contend with.

1 0

Re: (ITS#8270) win32: fix conversion error
by leo＠yuriev.ru 20 Oct '15

20 Oct '15

2015-10-20 23:09 GMT+03:00 <hyc(a)symas.com>: > > nacho.resa(a)gmail.com wrote: > > --047d7bb03a5ac118d20522842ead > > Content-Type: text/plain; charset=UTF-8 > > > > So I took another closer look at this issue and I went for this possible > > solution: > > https://github.com/nice-software/lmdb/commit/03987789735141dc68ae8b2d0e5ad5… > > That looks OK. > > > Basically it errors out because MSVC needs stdcall on that method. > > You realize of course, that this change actually has no effect on the code > here? stdcall uses Pascal argument order instead of C order but it's moot > since the function only has 1 argument. > Oops, sorry (dummy gmail...). No, there is another important difference: cdecl = the caller is responsible to clean stack from args (e.g. addl esp, N); stdcall = the callee is responsible to clean stack from args (e.g. retn N);

1 0

Re: (ITS#8270) win32: fix conversion error
by leo＠yuriev.ru 20 Oct '15

20 Oct '15

--001a11c23788b1353405228fbfbd Content-Type: text/plain; charset=UTF-8 2015-10-20 23:09 GMT+03:00 <hyc(a)symas.com>: > nacho.resa(a)gmail.com wrote: > > --047d7bb03a5ac118d20522842ead > > Content-Type: text/plain; charset=UTF-8 > > > > So I took another closer look at this issue and I went for this possible > > solution: > > > https://github.com/nice-software/lmdb/commit/03987789735141dc68ae8b2d0e5ad5… > > That looks OK. > > > Basically it errors out because MSVC needs stdcall on that method. > > You realize of course, that this change actually has no effect on the code > here? stdcall uses Pascal argument order instead of C order but it's moot > since the function only has 1 argument. > > No, there is another important difference: cdecl = the caller is responsible to clean stack from args (e.g. addl esp, N); stdcall = the callee is responsible to clean stack from args (e.g. retn N); --001a11c23788b1353405228fbfbd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2015= -10-20 23:09 GMT+03:00 <span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.c= om" target=3D"_blank">hyc(a)symas.com</a>></span>:<br><blockquote class=3D= "gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde= r-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><a = href=3D"mailto:nacho.resa@gmail.com">nacho.resa(a)gmail.com</a> wrote:<br> > --047d7bb03a5ac118d20522842ead<br> > Content-Type: text/plain; charset=3DUTF-8<br> ><br> > So I took another closer look at this issue and I went for this possib= le<br> > solution:<br> > <a href=3D"https://github.com/nice-software/lmdb/commit/03987789735141= dc68ae8b2d0e5ad52d82cc80d0" rel=3D"noreferrer" target=3D"_blank">https://gi= thub.com/nice-software/lmdb/commit/03987789735141dc68ae8b2d0e5ad52d82cc80d0= </a><br> <br> That looks OK.<br> <br> > Basically it errors out because MSVC needs stdcall on that method.<br> <br> You realize of course, that this change actually has no effect on the code<= br> here? stdcall uses Pascal argument order instead of C order but it's mo= ot<br> since the function only has 1 argument.<br> <br></blockquote><div><br><div>No, there is another important difference:</= div><div>cdecl =3D the caller is responsible to clean stack from args (e.g.= addl esp, N);</div>stdcall =3D the callee is responsible to clean stack fr= om args (e.g. retn N);=C2=A0</div></div></div></div> --001a11c23788b1353405228fbfbd--

1 0

Re: (ITS#8270) win32: fix conversion error
by nacho.resa＠gmail.com 20 Oct '15

20 Oct '15

--f46d043895179821ec05228f3c91 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 20, 2015 at 10:09 PM, Howard Chu <hyc(a)symas.com> wrote: > nacho.resa(a)gmail.com wrote: > >> --047d7bb03a5ac118d20522842ead >> Content-Type: text/plain; charset=UTF-8 >> >> So I took another closer look at this issue and I went for this possible >> solution: >> >> https://github.com/nice-software/lmdb/commit/03987789735141dc68ae8b2d0e5ad5… >> > > That looks OK. > > Basically it errors out because MSVC needs stdcall on that method. >> > > You realize of course, that this change actually has no effect on the code > here? stdcall uses Pascal argument order instead of C order but it's moot > since the function only has 1 argument. > yeah... but if this fixes the error I am fine with it, after all it end ups being just a define > > >> Cheers. >> >> On Mon, Oct 19, 2015 at 2:55 PM, Ignacio Casal Quinteiro < >> nacho.resa(a)gmail.com> wrote: >> >> Sorry! I did indeed meant to change just the windows part, for some reason >>> I thought it was already ifdeffed that part. >>> >>> >>> https://github.com/nice-software/lmdb/commit/42577fe173923c1166f8382a53523a… >>> >>> This is the right patch. >>> >>> On Mon, Oct 19, 2015 at 1:43 PM, Hallvard Breien Furuseth < >>> h.b.furuseth(a)usit.uio.no> wrote: >>> >>> On 19. okt. 2015 08:57, nacho.resa(a)gmail.com wrote: >>>> >>>> I do not understand, I tested also with mingw64 (...) >>>>> >>>>> >>>> There's no LPTHREAD_START_ROUTINE type on non-Windows machines. >>>> You could replace 'start' with '(LPTHREAD_START_ROUTINE)(start)' >>>> in the _WIN32 variant of '#define THREAD_CREATE...'. >>>> >>>> However, it's still wrong to call a function via another prototype. >>>> Maybe that'd fall on 32-bit Windows or something, I don't know >>>> how LPTHREAD_START_ROUTINE is defined. The safe way would be to >>>> give mdb_env_copythr() a prototype which does not need a cast. >>>> There is some code for that already. Maybe it can be improved. >>>> >>>> -- >>>> Hallvard >>>> >>>> >>> >>> >>> -- >>> Ignacio Casal Quinteiro >>> >>> >> >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- Ignacio Casal Quinteiro --f46d043895179821ec05228f3c91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= te">On Tue, Oct 20, 2015 at 10:09 PM, Howard Chu <span dir=3D"ltr"><<a h= ref=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a>></span>= wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor= der-left:1px #ccc solid;padding-left:1ex"><a href=3D"mailto:nacho.resa@gmai= l.com" target=3D"_blank">nacho.resa(a)gmail.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> --047d7bb03a5ac118d20522842ead<br> Content-Type: text/plain; charset=3DUTF-8<span class=3D""><br> <br> So I took another closer look at this issue and I went for this possible<br= > solution:<br> <a href=3D"https://github.com/nice-software/lmdb/commit/03987789735141dc68a= e8b2d0e5ad52d82cc80d0" rel=3D"noreferrer" target=3D"_blank">https://github.= com/nice-software/lmdb/commit/03987789735141dc68ae8b2d0e5ad52d82cc80d0</a><= br> </span></blockquote> <br> That looks OK.<span class=3D""><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Basically it errors out because MSVC needs stdcall on that method.<br> </blockquote> <br></span> You realize of course, that this change actually has no effect on the code = here? stdcall uses Pascal argument order instead of C order but it's mo= ot since the function only has 1 argument.<span class=3D"im HOEnZb"><br></s= pan></blockquote><div><br></div><div>yeah... but if this fixes the error I = am fine with it, after all it end ups being just a define<br></div><div>=C2= =A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde= r-left:1px #ccc solid;padding-left:1ex"><span class=3D"im HOEnZb"> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> Cheers.<br> <br> On Mon, Oct 19, 2015 at 2:55 PM, Ignacio Casal Quinteiro <<br> <a href=3D"mailto:nacho.resa@gmail.com" target=3D"_blank">nacho.resa(a)gmail.= com</a>> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Sorry! I did indeed meant to change just the windows part, for some reason<= br> I thought it was already ifdeffed that part.<br> <br> <a href=3D"https://github.com/nice-software/lmdb/commit/42577fe173923c1166f= 8382a53523a31479f9d43" rel=3D"noreferrer" target=3D"_blank">https://github.= com/nice-software/lmdb/commit/42577fe173923c1166f8382a53523a31479f9d43</a><= br> <br> This is the right patch.<br> <br> On Mon, Oct 19, 2015 at 1:43 PM, Hallvard Breien Furuseth <<br> <a href=3D"mailto:h.b.furuseth@usit.uio.no" target=3D"_blank">h.b.furuseth@= usit.uio.no</a>> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 19. okt. 2015 08:57, <a href=3D"mailto:nacho.resa@gmail.com" target=3D"_= blank">nacho.resa(a)gmail.com</a> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I do not understand, I tested also with mingw64 (...)<br> <br> </blockquote> <br> There's no LPTHREAD_START_ROUTINE type on non-Windows machines.<br> You could replace 'start' with '(LPTHREAD_START_ROUTINE)(start)= '<br> in the _WIN32 variant of '#define THREAD_CREATE...'.<br> <br> However, it's still wrong to call a function via another prototype.<br> Maybe that'd fall on 32-bit Windows or something, I don't know<br> how LPTHREAD_START_ROUTINE is defined.=C2=A0 The safe way would be to<br> give mdb_env_copythr() a prototype which does not need a cast.<br> There is some code for that already. Maybe it can be improved.<br> <br> --<br> Hallvard<br> <br> </blockquote> <br> <br> <br> --<br> Ignacio Casal Quinteiro<br> <br> </blockquote> <br> <br> <br> </blockquote> <br> <br> -- <br></span><div class=3D"HOEnZb"><div class=3D"h5"> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www.symas= .com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun.com/h= yc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org/proje= ct/</a><br> </div></div></blockquote></div><br><br clear=3D"all"><br>-- <br><div class= =3D"gmail_signature">Ignacio Casal Quinteiro</div> </div></div> --f46d043895179821ec05228f3c91--

1 0

Re: (ITS#8270) win32: fix conversion error
by hyc＠symas.com 20 Oct '15

20 Oct '15

nacho.resa(a)gmail.com wrote: > --047d7bb03a5ac118d20522842ead > Content-Type: text/plain; charset=UTF-8 > > So I took another closer look at this issue and I went for this possible > solution: > https://github.com/nice-software/lmdb/commit/03987789735141dc68ae8b2d0e5ad5… That looks OK. > Basically it errors out because MSVC needs stdcall on that method. You realize of course, that this change actually has no effect on the code here? stdcall uses Pascal argument order instead of C order but it's moot since the function only has 1 argument. > > Cheers. > > On Mon, Oct 19, 2015 at 2:55 PM, Ignacio Casal Quinteiro < > nacho.resa(a)gmail.com> wrote: > >> Sorry! I did indeed meant to change just the windows part, for some reason >> I thought it was already ifdeffed that part. >> >> https://github.com/nice-software/lmdb/commit/42577fe173923c1166f8382a53523a… >> >> This is the right patch. >> >> On Mon, Oct 19, 2015 at 1:43 PM, Hallvard Breien Furuseth < >> h.b.furuseth(a)usit.uio.no> wrote: >> >>> On 19. okt. 2015 08:57, nacho.resa(a)gmail.com wrote: >>> >>>> I do not understand, I tested also with mingw64 (...) >>>> >>> >>> There's no LPTHREAD_START_ROUTINE type on non-Windows machines. >>> You could replace 'start' with '(LPTHREAD_START_ROUTINE)(start)' >>> in the _WIN32 variant of '#define THREAD_CREATE...'. >>> >>> However, it's still wrong to call a function via another prototype. >>> Maybe that'd fall on 32-bit Windows or something, I don't know >>> how LPTHREAD_START_ROUTINE is defined. The safe way would be to >>> give mdb_env_copythr() a prototype which does not need a cast. >>> There is some code for that already. Maybe it can be improved. >>> >>> -- >>> Hallvard >>> >> >> >> >> -- >> Ignacio Casal Quinteiro >> > > > -- -- 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#8278) slapd fails to start when built with --enable-slp on freebsd
by h.b.furuseth＠usit.uio.no 20 Oct '15

20 Oct '15

On 20. okt. 2015 00:28, quanah(a)openldap.org wrote: > slapd will not start, exits with "slap_schema_init: Error registering matching > rule ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' SYNTAX > 1.3.6.1.4.1.1466.115.121.1.24 )" Reported to OpenSLP: <http://sourceforge.net/p/openslp/bugs/149/>. libslp 2.0.0 redefines strncasecmp() unless HAVE_STRNCASECMP, which it does not #define. Building OpenSLP (not OpenLDAP) with './configure CPPFLAGS=-DHAVE_STRNCASECMP' fixes it. -- Hallvard

1 0

Re: (ITS#8278) slapd fails to start when built with --enable-slp on freebsd
by ryan＠nardis.ca 20 Oct '15

20 Oct '15

On Mon, Oct 19, 2015 at 10:28:40PM +0000, quanah(a)openldap.org wrote: >OS: FreeBSD 10.1 FTR, this is not FreeBSD specific. I reproduced it easily on Linux (Debian unstable). Only happens when using OpenSLP 2.0.0, not with 1.2.1. Have not figured out whether it's an OpenSLP bug or a change we need to adapt to.

1 0

(ITS#8279) back-mdb maxsize should accept suffixes
by matthieu.cerda＠normation.com 20 Oct '15

20 Oct '15

Full_Name: Matthieu CERDA Version: 2.4.31 OS: Debian 7.8 URL: http://www.openldap.org/doc/admin24/backends.html Submission from: (NULL) (91.223.73.146) Hello, Would it be possible (without too much hassle and without interfering with OpenLDAP configuration and coding standards) to make the maxsize / olcDbMaxSize configuration parameter able to handle K / M / G suffixes ? Regards, -- Matthieu CERDA

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs