openldap-bugs November 2012

openldap-bugs@openldap.org

30 participants
100 discussions

Re: (ITS#7444) Check the return value of ldap_pvt_thread_set_concurrency
by hyc＠symas.com 25 Nov '12

25 Nov '12

tixu(a)cs.ucsd.edu wrote: > Full_Name: Tianyin Xu > Version: 2.4.33 > OS: Ubuntu 12.04 (actually doesn't matter) > URL: > Submission from: (NULL) (2607:f720:1300:1241:590b:49c:889f:7b21) > > > Hi, all, > > Still the verbosity idea. In the current version of slapd, when handling users' > "concurrency" setting, slapd does not check the return value of > "ldap_pvt_thread_set_concurrency" (essentially the return value of > "pthread_setconcurrency") to see whether the setting is successful or not. > > So when the user setting is inappropriate (i.e., too big), slapd says nothing. > But users have no way to be aware of such configuration failure. I suggest to > check and notify users in this case. pthread_setconcurrency is a no-op on Linux systems. Even on systems where this setting might have an effect, it is generally unused. We have more important things to worry about than this. > Here's the patch: > > --- ../openldap-2.4.33/servers/slapd/bconfig.c 2012-10-10 > 05:18:49.000000000 -0700 > +++ servers/slapd/bconfig.c 2012-11-16 14:52:37.211421828 -0800 > @@ -1530,7 +1530,14 @@ > break; > > case CFG_CONCUR: > - ldap_pvt_thread_set_concurrency(c->value_int); > + > + if(ldap_pvt_thread_set_concurrency(c->value_int) != 0) > { > + snprintf( c->cr_msg, sizeof( c->cr_msg ), > + "concurrency=%d is not valid; using > the default setting", > + c->value_int ); > + Debug(LDAP_DEBUG_ANY, "%s: %s.\n", c->log, > c->cr_msg, 0 ); > + > + } > break; > > case CFG_THREADS: > > > -- -- 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#7450) segfault with listener-threads=8
by hyc＠symas.com 25 Nov '12

25 Nov '12

jackie.qq.zhang(a)gmail.com wrote: > Hi, Howard, > > GDB did stop at the statement: > **assert( SLAP_SOCK_NOT_ACTIVE(id, s) );** > > But the system output is > **Segmentation fault (core dumped)** > > It seems not related to whether it's a power of 2 or not, because even > I specify it as 64, i.e., 2^6, the result and error message are still > the same. That's to be expected since currently this setting has a hard-coded maximum of 16. Unless you have a machine with more than 1024 cores, I don't think your setting is valid. So again, this bug report is invalid. -- -- 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#7450) segfault with listener-threads=8
by jackie.qq.zhang＠gmail.com 25 Nov '12

25 Nov '12

Hi, Howard, GDB did stop at the statement: **assert( SLAP_SOCK_NOT_ACTIVE(id, s) );** But the system output is **Segmentation fault (core dumped)** It seems not related to whether it's a power of 2 or not, because even I specify it as 64, i.e., 2^6, the result and error message are still the same. Best regards, Jackie On Sun, Nov 25, 2012 at 5:04 PM, Howard Chu <hyc(a)symas.com> wrote: > > jackie.qq.zhang(a)gmail.com wrote: >> >> --20cf300faffd868e6d04cf5a0c62 >> Content-Type: text/plain; charset=ISO-8859-1 >> Content-Transfer-Encoding: quoted-printable >> >> >> Hi, Michael, >> >> This is my simplified configuration file which can reproduce the segfault. >> For the purpose of replay, I use "50" instead of "8" because using "8" >> sometime cannot reproduce the error. > > > This bug report is invalid. You reported a "segfault" originally, not an assert() as shown in this trace. The slapd.conf(5) manpage clearly states that the value should be a power of 2. > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> slapd.conf >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> listener-threads 50 >> include /xxx/etc/openldap/schema/core.schema >> pidfile /xxx/var/run/slapd.pid >> argsfile /xxx/var/run/slapd.args >> >> database bdb >> suffix "dc=3Dxxx,dc=3Dxxx" >> rootdn "cn=3Dxxx,dc=3Dxxx,dc=3Dxxx" >> >> rootpw secret >> directory /xxx/var/openldap-data >> index objectClass eq >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> >> The stack traces are: >> >> Thread 3 (Thread 0x7ffff4f2c700 (LWP 24897)): >> #0 0x00007ffff6d40481 in clone () from /lib/x86_64-linux-gnu/libc.so.6 >> #1 0x00007ffff7012dc0 in ?? () from /lib/x86_64-linux-gnu/libpthread.so.0 >> #2 0x00007ffff4f2c700 in ?? () >> #3 0x0000000000000000 in ?? () >> >> Thread 2 (Thread 0x7ffff572d700 (LWP 24896)): >> #0 0x000000000042543f in slapd_add (s=3D10, isactive=3D0, sl=3D0x0, id=3D0= >> ) at >> daemon.c:857 >> #1 0x0000000000429afc in slapd_daemon_task (ptr=3D0xaa8ed0) at daemon.c:21= >> >> 37 >> #2 0x00007ffff7012e9a in start_thread () from >> /lib/x86_64-linux-gnu/libpthread.so.0 >> #3 0x00007ffff6d404bd in clone () from /lib/x86_64-linux-gnu/libc.so.6 >> #4 0x0000000000000000 in ?? () >> >> Thread 1 (Thread 0x7ffff7fe1700 (LWP 24893)): >> #0 0x00007ffff6d40481 in clone () from /lib/x86_64-linux-gnu/libc.so.6 >> #1 0x00007ffff7011f70 in do_clone.constprop.4 () from >> /lib/x86_64-linux-gnu/libpthread.so.0 >> #2 0x00007ffff70138ba in pthread_create@@GLIBC_2.2.5 () from >> /lib/x86_64-linux-gnu/libpthread.so.0 >> #3 0x000000000058ccbb in ldap_pvt_thread_create (thread=3D0xaa8ed8, >> detach=3D0, start_routine=3D0x429a7c <slapd_daemon_task>, arg=3D0xaa8ed8\ >> >> ) at thr_posix.c:165 >> #4 0x000000000042bf28 in slapd_daemon () at daemon.c:2918 >> #5 0x00000000004087b8 in main (argc=3D7, argv=3D0x7fffffffe008) at main.c:= >> >> 1012 >> >> The GDB stopped at the following statement: >> >> assert( SLAP_SOCK_NOT_ACTIVE(id, s) ); >> >> which is in slapd_add, daemon.c:857. >> >> Best regards, >> Jackie >> >> >> >> On Sun, Nov 25, 2012 at 6:29 AM, Michael Str=F6der <michael(a)stroeder.com>wr= >> ote: >> >>> jackie.qq.zhang(a)gmail.com wrote: >>>> >>>> The default configuration does not have this problem. So I checked ever= >> >> y >>>> >>>> configuration setting I made and finally found it's caused by the >>> >>> following >>>> >>>> setting: >>>> >>>> listener-threads 8 >>> >>> >>> I tried to reproduce this by adding the line above to my local config. Bu= >> >> t >>> >>> slapd still works on my system. >>> >>> Could you please provide a canned config which reproduces the seg fault a= >> >> nd >>> >>> preferrably a full stack trace? >>> >>> http://www.openldap.org/faq/data/cache/59.html >>> >>> Make sure you have installed slapd with debug symbols (make install >>> STRIP=3D""). >>> >>> Ciao, Michael. >>> >> >> --20cf300faffd868e6d04cf5a0c62 >> Content-Type: text/html; charset=ISO-8859-1 >> Content-Transfer-Encoding: quoted-printable >> >> Hi, Michael, This is my simplified configuration file which can repr= >> oduce the segfault. For the purpose of replay, I use "50" instead= >> of "8" because using "8" sometime cannot reproduce the= >> error. >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> slapd.conf >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> listener-threads 50 include=A0=A0=A0=A0=A0=A0 /xxx/etc/openldap/schema/c= >> ore.schema >> pidfile=A0=A0=A0=A0=A0=A0=A0=A0 /xxx/var/run/slapd.pid >> argsfile=A0=A0=A0=A0=A0=A0 /xxx/var/run/slapd.args >> >> database=A0=A0=A0=A0=A0=A0=A0 bdb >> suffix=A0=A0=A0=A0=A0=A0=A0=A0=A0 "dc=3Dxxx,dc=3Dxxx" >> rootdn=A0=A0=A0=A0=A0=A0=A0=A0=A0 "cn=3Dxxx,dc=3Dxxx,dc=3Dxxx"<br= >>> >>> >> rootpw=A0=A0=A0=A0=A0=A0=A0=A0=A0 secret >> directory=A0=A0=A0=A0=A0=A0 /xxx/var/openldap-data >> index=A0=A0 objectClass=A0=A0=A0=A0 eq >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The stack traces are:= >> Thread 3 (Thread 0x7ffff4f2c700 (LWP 24897)): #0=A0 0x00007ffff6= >> d40481 in clone () from /lib/x86_64-linux-gnu/libc.so.6 #1=A0 0x00007fff= >> f7012dc0 in ?? () from /lib/x86_64-linux-gnu/libpthread.so.0 >> #2=A0 0x00007ffff4f2c700 in ?? () #3=A0 0x0000000000000000 in ?? () <= >> br>Thread 2 (Thread 0x7ffff572d700 (LWP 24896)): #0=A0 0x000000000042543= >> f in slapd_add (s=3D10, isactive=3D0, sl=3D0x0, id=3D0) at daemon.c:857 = >> #1=A0 0x0000000000429afc in slapd_daemon_task (ptr=3D0xaa8ed0) at daemon.c:= >> 2137 >> #2=A0 0x00007ffff7012e9a in start_thread () from /lib/x86_64-linux-gnu/libp= >> thread.so.0 #3=A0 0x00007ffff6d404bd in clone () from /lib/x86_64-linux-= >> gnu/libc.so.6 #4=A0 0x0000000000000000 in ?? () Thread 1 (Thread = >> 0x7ffff7fe1700 (LWP 24893)): >> #0=A0 0x00007ffff6d40481 in clone () from /lib/x86_64-linux-gnu/libc.so.6<b= >> r>#1=A0 0x00007ffff7011f70 in do_clone.constprop.4 () from /lib/x86_64-linu= >> x-gnu/libpthread.so.0 #2=A0 0x00007ffff70138ba in pthread_create@@GLIBC_= >> 2.2.5 () from /lib/x86_64-linux-gnu/libpthread.so.0 >> #3=A0 0x000000000058ccbb in ldap_pvt_thread_create (thread=3D0xaa8ed8, deta= >> ch=3D0, start_routine=3D0x429a7c <slapd_daemon_task>, arg=3D0xaa8ed8\= >> ) at thr_posix.c:165 #4=A0 0x000000000042bf28 in slapd_daemon () at = >> daemon.c:2918 >> #5=A0 0x00000000004087b8 in main (argc=3D7, argv=3D0x7fffffffe008) at main.= >> c:1012 The GDB stopped at the following statement: assert( S= >> LAP_SOCK_NOT_ACTIVE(id, s) ); which is in slapd_add, daemon.c:857.<b= >> r> >> Best regards, Jackie <div class=3D"gmail_quote">On Su= >> n, Nov 25, 2012 at 6:29 AM, Michael Str=F6der <<a href= >> =3D"mailto:michael@stroeder.com" target=3D"_blank">michael(a)stroeder.com</a>= >> > wrote: >> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= >> x #ccc solid;padding-left:1ex"><a href=3D"mailto:jackie.qq.zhang@gmail.com"= >>> >>> jackie.qq.zhang(a)gmail.com</a> wrote: >> >> > The default configuration does not have this problem. So I checked eve= >> ry >> > configuration setting I made and finally found it's caused by the = >> following >> > setting: >> > >> > listener-threads 8 >> >> I tried to reproduce this by adding the line above to my local config. But<= >> br> >> slapd still works on my system. >> >> Could you please provide a canned config which reproduces the seg fault and= >> >> preferrably a full stack trace? >> >> <a href=3D"http://www.openldap.org/faq/data/cache/59.html" target=3D"_blank= >> ">http://www.openldap.org/faq/data/cache/59.html</a> >> >> >> Make sure you have installed slapd with debug symbols (make install STRIP= >> =3D""). >> >> Ciao, Michael. >> </blockquote></div> >> >> --20cf300faffd868e6d04cf5a0c62-- >> >> >> > > > -- > -- 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#7450) segfault with listener-threads=8
by hyc＠symas.com 25 Nov '12

25 Nov '12

jackie.qq.zhang(a)gmail.com wrote: > --20cf300faffd868e6d04cf5a0c62 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > Hi, Michael, > > This is my simplified configuration file which can reproduce the segfault. > For the purpose of replay, I use "50" instead of "8" because using "8" > sometime cannot reproduce the error. This bug report is invalid. You reported a "segfault" originally, not an assert() as shown in this trace. The slapd.conf(5) manpage clearly states that the value should be a power of 2. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > slapd.conf > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > listener-threads 50 > include /xxx/etc/openldap/schema/core.schema > pidfile /xxx/var/run/slapd.pid > argsfile /xxx/var/run/slapd.args > > database bdb > suffix "dc=3Dxxx,dc=3Dxxx" > rootdn "cn=3Dxxx,dc=3Dxxx,dc=3Dxxx" > rootpw secret > directory /xxx/var/openldap-data > index objectClass eq > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > The stack traces are: > > Thread 3 (Thread 0x7ffff4f2c700 (LWP 24897)): > #0 0x00007ffff6d40481 in clone () from /lib/x86_64-linux-gnu/libc.so.6 > #1 0x00007ffff7012dc0 in ?? () from /lib/x86_64-linux-gnu/libpthread.so.0 > #2 0x00007ffff4f2c700 in ?? () > #3 0x0000000000000000 in ?? () > > Thread 2 (Thread 0x7ffff572d700 (LWP 24896)): > #0 0x000000000042543f in slapd_add (s=3D10, isactive=3D0, sl=3D0x0, id=3D0= > ) at > daemon.c:857 > #1 0x0000000000429afc in slapd_daemon_task (ptr=3D0xaa8ed0) at daemon.c:21= > 37 > #2 0x00007ffff7012e9a in start_thread () from > /lib/x86_64-linux-gnu/libpthread.so.0 > #3 0x00007ffff6d404bd in clone () from /lib/x86_64-linux-gnu/libc.so.6 > #4 0x0000000000000000 in ?? () > > Thread 1 (Thread 0x7ffff7fe1700 (LWP 24893)): > #0 0x00007ffff6d40481 in clone () from /lib/x86_64-linux-gnu/libc.so.6 > #1 0x00007ffff7011f70 in do_clone.constprop.4 () from > /lib/x86_64-linux-gnu/libpthread.so.0 > #2 0x00007ffff70138ba in pthread_create@@GLIBC_2.2.5 () from > /lib/x86_64-linux-gnu/libpthread.so.0 > #3 0x000000000058ccbb in ldap_pvt_thread_create (thread=3D0xaa8ed8, > detach=3D0, start_routine=3D0x429a7c <slapd_daemon_task>, arg=3D0xaa8ed8\ > ) at thr_posix.c:165 > #4 0x000000000042bf28 in slapd_daemon () at daemon.c:2918 > #5 0x00000000004087b8 in main (argc=3D7, argv=3D0x7fffffffe008) at main.c:= > 1012 > > The GDB stopped at the following statement: > > assert( SLAP_SOCK_NOT_ACTIVE(id, s) ); > > which is in slapd_add, daemon.c:857. > > Best regards, > Jackie > > > > On Sun, Nov 25, 2012 at 6:29 AM, Michael Str=F6der <michael(a)stroeder.com>wr= > ote: > >> jackie.qq.zhang(a)gmail.com wrote: >>> The default configuration does not have this problem. So I checked ever= > y >>> configuration setting I made and finally found it's caused by the >> following >>> setting: >>> >>> listener-threads 8 >> >> I tried to reproduce this by adding the line above to my local config. Bu= > t >> slapd still works on my system. >> >> Could you please provide a canned config which reproduces the seg fault a= > nd >> preferrably a full stack trace? >> >> http://www.openldap.org/faq/data/cache/59.html >> >> Make sure you have installed slapd with debug symbols (make install >> STRIP=3D""). >> >> Ciao, Michael. >> > > --20cf300faffd868e6d04cf5a0c62 > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > Hi, Michael, This is my simplified configuration file which can repr= > oduce the segfault. For the purpose of replay, I use "50" instead= > of "8" because using "8" sometime cannot reproduce the= > error. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > slapd.conf > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > listener-threads 50 include=A0=A0=A0=A0=A0=A0 /xxx/etc/openldap/schema/c= > ore.schema > pidfile=A0=A0=A0=A0=A0=A0=A0=A0 /xxx/var/run/slapd.pid > argsfile=A0=A0=A0=A0=A0=A0 /xxx/var/run/slapd.args > > database=A0=A0=A0=A0=A0=A0=A0 bdb > suffix=A0=A0=A0=A0=A0=A0=A0=A0=A0 "dc=3Dxxx,dc=3Dxxx" > rootdn=A0=A0=A0=A0=A0=A0=A0=A0=A0 "cn=3Dxxx,dc=3Dxxx,dc=3Dxxx"<br= >> > rootpw=A0=A0=A0=A0=A0=A0=A0=A0=A0 secret > directory=A0=A0=A0=A0=A0=A0 /xxx/var/openldap-data > index=A0=A0 objectClass=A0=A0=A0=A0 eq > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The stack traces are:= > Thread 3 (Thread 0x7ffff4f2c700 (LWP 24897)): #0=A0 0x00007ffff6= > d40481 in clone () from /lib/x86_64-linux-gnu/libc.so.6 #1=A0 0x00007fff= > f7012dc0 in ?? () from /lib/x86_64-linux-gnu/libpthread.so.0 > #2=A0 0x00007ffff4f2c700 in ?? () #3=A0 0x0000000000000000 in ?? () <= > br>Thread 2 (Thread 0x7ffff572d700 (LWP 24896)): #0=A0 0x000000000042543= > f in slapd_add (s=3D10, isactive=3D0, sl=3D0x0, id=3D0) at daemon.c:857 = > #1=A0 0x0000000000429afc in slapd_daemon_task (ptr=3D0xaa8ed0) at daemon.c:= > 2137 > #2=A0 0x00007ffff7012e9a in start_thread () from /lib/x86_64-linux-gnu/libp= > thread.so.0 #3=A0 0x00007ffff6d404bd in clone () from /lib/x86_64-linux-= > gnu/libc.so.6 #4=A0 0x0000000000000000 in ?? () Thread 1 (Thread = > 0x7ffff7fe1700 (LWP 24893)): > #0=A0 0x00007ffff6d40481 in clone () from /lib/x86_64-linux-gnu/libc.so.6<b= > r>#1=A0 0x00007ffff7011f70 in do_clone.constprop.4 () from /lib/x86_64-linu= > x-gnu/libpthread.so.0 #2=A0 0x00007ffff70138ba in pthread_create@@GLIBC_= > 2.2.5 () from /lib/x86_64-linux-gnu/libpthread.so.0 > #3=A0 0x000000000058ccbb in ldap_pvt_thread_create (thread=3D0xaa8ed8, deta= > ch=3D0, start_routine=3D0x429a7c <slapd_daemon_task>, arg=3D0xaa8ed8\= > ) at thr_posix.c:165 #4=A0 0x000000000042bf28 in slapd_daemon () at = > daemon.c:2918 > #5=A0 0x00000000004087b8 in main (argc=3D7, argv=3D0x7fffffffe008) at main.= > c:1012 The GDB stopped at the following statement: assert( S= > LAP_SOCK_NOT_ACTIVE(id, s) ); which is in slapd_add, daemon.c:857.<b= > r> > Best regards, Jackie <div class=3D"gmail_quote">On Su= > n, Nov 25, 2012 at 6:29 AM, Michael Str=F6der <<a href= > =3D"mailto:michael@stroeder.com" target=3D"_blank">michael(a)stroeder.com</a>= > > wrote: > <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= > x #ccc solid;padding-left:1ex"><a href=3D"mailto:jackie.qq.zhang@gmail.com"= >> jackie.qq.zhang(a)gmail.com</a> wrote: > > The default configuration does not have this problem. So I checked eve= > ry > > configuration setting I made and finally found it's caused by the = > following > > setting: > > > > listener-threads 8 > > I tried to reproduce this by adding the line above to my local config. But<= > br> > slapd still works on my system. > > Could you please provide a canned config which reproduces the seg fault and= > > preferrably a full stack trace? > > <a href=3D"http://www.openldap.org/faq/data/cache/59.html" target=3D"_blank= > ">http://www.openldap.org/faq/data/cache/59.html</a> > > Make sure you have installed slapd with debug symbols (make install STRIP= > =3D""). > > Ciao, Michael. > </blockquote></div> > > --20cf300faffd868e6d04cf5a0c62-- > > > -- -- 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#7450) segfault with listener-threads=8
by jackie.qq.zhang＠gmail.com 25 Nov '12

25 Nov '12

--20cf300faffd868e6d04cf5a0c62 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Michael, This is my simplified configuration file which can reproduce the segfault. For the purpose of replay, I use "50" instead of "8" because using "8" sometime cannot reproduce the error. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D slapd.conf =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D listener-threads 50 include /xxx/etc/openldap/schema/core.schema pidfile /xxx/var/run/slapd.pid argsfile /xxx/var/run/slapd.args database bdb suffix "dc=3Dxxx,dc=3Dxxx" rootdn "cn=3Dxxx,dc=3Dxxx,dc=3Dxxx" rootpw secret directory /xxx/var/openldap-data index objectClass eq =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The stack traces are: Thread 3 (Thread 0x7ffff4f2c700 (LWP 24897)): #0 0x00007ffff6d40481 in clone () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff7012dc0 in ?? () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007ffff4f2c700 in ?? () #3 0x0000000000000000 in ?? () Thread 2 (Thread 0x7ffff572d700 (LWP 24896)): #0 0x000000000042543f in slapd_add (s=3D10, isactive=3D0, sl=3D0x0, id=3D0= ) at daemon.c:857 #1 0x0000000000429afc in slapd_daemon_task (ptr=3D0xaa8ed0) at daemon.c:21= 37 #2 0x00007ffff7012e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #3 0x00007ffff6d404bd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x0000000000000000 in ?? () Thread 1 (Thread 0x7ffff7fe1700 (LWP 24893)): #0 0x00007ffff6d40481 in clone () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff7011f70 in do_clone.constprop.4 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007ffff70138ba in pthread_create@@GLIBC_2.2.5 () from /lib/x86_64-linux-gnu/libpthread.so.0 #3 0x000000000058ccbb in ldap_pvt_thread_create (thread=3D0xaa8ed8, detach=3D0, start_routine=3D0x429a7c <slapd_daemon_task>, arg=3D0xaa8ed8\ ) at thr_posix.c:165 #4 0x000000000042bf28 in slapd_daemon () at daemon.c:2918 #5 0x00000000004087b8 in main (argc=3D7, argv=3D0x7fffffffe008) at main.c:= 1012 The GDB stopped at the following statement: assert( SLAP_SOCK_NOT_ACTIVE(id, s) ); which is in slapd_add, daemon.c:857. Best regards, Jackie On Sun, Nov 25, 2012 at 6:29 AM, Michael Str=F6der <michael(a)stroeder.com>wr= ote: > jackie.qq.zhang(a)gmail.com wrote: > > The default configuration does not have this problem. So I checked ever= y > > configuration setting I made and finally found it's caused by the > following > > setting: > > > > listener-threads 8 > > I tried to reproduce this by adding the line above to my local config. Bu= t > slapd still works on my system. > > Could you please provide a canned config which reproduces the seg fault a= nd > preferrably a full stack trace? > > http://www.openldap.org/faq/data/cache/59.html > > Make sure you have installed slapd with debug symbols (make install > STRIP=3D""). > > Ciao, Michael. > --20cf300faffd868e6d04cf5a0c62 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Michael, This is my simplified configuration file which can repr= oduce the segfault. For the purpose of replay, I use "50" instead= of "8" because using "8" sometime cannot reproduce the= error. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D slapd.conf =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D listener-threads 50 include=A0=A0=A0=A0=A0=A0 /xxx/etc/openldap/schema/c= ore.schema pidfile=A0=A0=A0=A0=A0=A0=A0=A0 /xxx/var/run/slapd.pid argsfile=A0=A0=A0=A0=A0=A0 /xxx/var/run/slapd.args database=A0=A0=A0=A0=A0=A0=A0 bdb suffix=A0=A0=A0=A0=A0=A0=A0=A0=A0 "dc=3Dxxx,dc=3Dxxx" rootdn=A0=A0=A0=A0=A0=A0=A0=A0=A0 "cn=3Dxxx,dc=3Dxxx,dc=3Dxxx"<br= > rootpw=A0=A0=A0=A0=A0=A0=A0=A0=A0 secret directory=A0=A0=A0=A0=A0=A0 /xxx/var/openldap-data index=A0=A0 objectClass=A0=A0=A0=A0 eq =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The stack traces are:= Thread 3 (Thread 0x7ffff4f2c700 (LWP 24897)): #0=A0 0x00007ffff6= d40481 in clone () from /lib/x86_64-linux-gnu/libc.so.6 #1=A0 0x00007fff= f7012dc0 in ?? () from /lib/x86_64-linux-gnu/libpthread.so.0 #2=A0 0x00007ffff4f2c700 in ?? () #3=A0 0x0000000000000000 in ?? () <= br>Thread 2 (Thread 0x7ffff572d700 (LWP 24896)): #0=A0 0x000000000042543= f in slapd_add (s=3D10, isactive=3D0, sl=3D0x0, id=3D0) at daemon.c:857 = #1=A0 0x0000000000429afc in slapd_daemon_task (ptr=3D0xaa8ed0) at daemon.c:= 2137 #2=A0 0x00007ffff7012e9a in start_thread () from /lib/x86_64-linux-gnu/libp= thread.so.0 #3=A0 0x00007ffff6d404bd in clone () from /lib/x86_64-linux-= gnu/libc.so.6 #4=A0 0x0000000000000000 in ?? () Thread 1 (Thread = 0x7ffff7fe1700 (LWP 24893)): #0=A0 0x00007ffff6d40481 in clone () from /lib/x86_64-linux-gnu/libc.so.6<b= r>#1=A0 0x00007ffff7011f70 in do_clone.constprop.4 () from /lib/x86_64-linu= x-gnu/libpthread.so.0 #2=A0 0x00007ffff70138ba in pthread_create@@GLIBC_= 2.2.5 () from /lib/x86_64-linux-gnu/libpthread.so.0 #3=A0 0x000000000058ccbb in ldap_pvt_thread_create (thread=3D0xaa8ed8, deta= ch=3D0, start_routine=3D0x429a7c <slapd_daemon_task>, arg=3D0xaa8ed8\= ) at thr_posix.c:165 #4=A0 0x000000000042bf28 in slapd_daemon () at = daemon.c:2918 #5=A0 0x00000000004087b8 in main (argc=3D7, argv=3D0x7fffffffe008) at main.= c:1012 The GDB stopped at the following statement: assert( S= LAP_SOCK_NOT_ACTIVE(id, s) ); which is in slapd_add, daemon.c:857.<b= r> Best regards, Jackie <div class=3D"gmail_quote">On Su= n, Nov 25, 2012 at 6:29 AM, Michael Str=F6der <<a href= =3D"mailto:michael@stroeder.com" target=3D"_blank">michael(a)stroeder.com</a>= > wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><a href=3D"mailto:jackie.qq.zhang@gmail.com"= >jackie.qq.zhang(a)gmail.com</a> wrote: > The default configuration does not have this problem. So I checked eve= ry > configuration setting I made and finally found it's caused by the = following > setting: > > listener-threads 8 I tried to reproduce this by adding the line above to my local config. But<= br> slapd still works on my system. Could you please provide a canned config which reproduces the seg fault and= preferrably a full stack trace? <a href=3D"http://www.openldap.org/faq/data/cache/59.html" target=3D"_blank= ">http://www.openldap.org/faq/data/cache/59.html</a> Make sure you have installed slapd with debug symbols (make install STRIP= =3D""). Ciao, Michael. </blockquote></div> --20cf300faffd868e6d04cf5a0c62--

1 0

Re: (ITS#7450) segfault with listener-threads=8
by michael＠stroeder.com 25 Nov '12

25 Nov '12

jackie.qq.zhang(a)gmail.com wrote: > The default configuration does not have this problem. So I checked every > configuration setting I made and finally found it's caused by the following > setting: > > listener-threads 8 I tried to reproduce this by adding the line above to my local config. But slapd still works on my system. Could you please provide a canned config which reproduces the seg fault and preferrably a full stack trace? http://www.openldap.org/faq/data/cache/59.html Make sure you have installed slapd with debug symbols (make install STRIP=""). Ciao, Michael.

1 0

(ITS#7450) segfault with listener-threads=8
by jackie.qq.zhang＠gmail.com 24 Nov '12

24 Nov '12

Full_Name: Jackie Zhang Version: 2.4.33 OS: Ubuntu 10.04 URL: Submission from: (NULL) (2607:f720:1300:1241:9502:8240:b2b5:ba3f) When I start the server, I saw the following error messages: 50b1ca90 bdb_db_open: warning - no DB_CONFIG file found in directory /xxx/openldap-2.4.33/var/openldap-data: (2). Expect poor performance for suffix "dc=xxx,dc=xxx". 50b1ca90 bdb_monitor_db_open: monitoring disabled; configure monitor database to enable 50b1ca90 slapd starting Segmentation fault (core dumped) The default configuration does not have this problem. So I checked every configuration setting I made and finally found it's caused by the following setting: listener-threads 8 Is this a bug?

1 0

Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by michael＠stroeder.com 24 Nov '12

24 Nov '12

This is a cryptographically signed message in MIME format. --------------ms010608050607040608060204 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Michael Str=F6der wrote: > Michael Str=F6der wrote: >> Jan Synacek wrote: >>> On 11/08/2012 08:14 AM, michael(a)stroeder.com wrote: >>>> FYI: I sent output of bt full to Jan with some data stripped because= of >>>> privacy concerns. >>>> >>>> Note that the entry for which constraint checking is done is added t= o the >>>> database. So something might be wrong *after* the check. >>> >>> Can you please try the attached patch? >> >> It seems to work. But I will test it during the next days more thoroug= hly. >=20 > No more seg faults so far in my setup which uses slapo-constraints quit= e > heavily. So I'd appreciate if Jan's patch lands in RE24 branch. What's the status of this? Is a more formal submission of Jan's patch needed to get this in? Ciao, Michael. --------------ms010608050607040608060204 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMTI0MTgzODM2WjAjBgkq hkiG9w0BCQQxFgQUhjp9n4t+TsTiZf/tl1jlQVW+7t0wbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEALrWnmZtYumwfT8BNjaBEw1Kmu02VjZNcQJk8xzfERqdKICA8Gza7VzhEdEIarBTO35C/ FCQsaPZN7jVYmfgBmneJrHKbqvQuOAjySvrvduoRJL0ZZkGQaMksnf/8rl6SW+hvMooNvbjR d7VYbYVRqSdCGrT+vmwarGG0pS6QY/vIc855hGHjUfQbPB3/dudo2BNyZy7L20L+83f1LPJv jw4sQqumL5cDlD8gFZdz7JfIQ1BmFbDgjchnMs4iidwZBjtHv1goM1SNUA2O79G7Ra1Tc+pD EGW9ePfiEhRCUM5xayjI4okWvtGu/z081/TGh+sYNszFcs6mRbbhJ/4l1QAAAAAAAA== --------------ms010608050607040608060204--

1 0

(ITS#7449) Signedness Conversion Issue
by tixu＠cs.ucsd.edu 21 Nov '12

21 Nov '12

Full_Name: Tianyin Xu Version: 2.4.33 OS: Ubuntu 12.04 (actually doesn't matter) URL: Submission from: (NULL) (2607:f720:1300:1241:512c:f07a:5efe:8eda) The data type of "index_substr_any_len" and "index_substr_any_step" are unsigned int. They should share the same flag ARG_UINT as "index_substr_if_{min,max}len" /* servers/slapd/schema_init.c */ 158 unsigned int index_substr_if_minlen = SLAP_INDEX_SUBSTR_IF_MINLEN_DEFAULT; 159 unsigned int index_substr_if_maxlen = SLAP_INDEX_SUBSTR_IF_MAXLEN_DEFAULT; 160 unsigned int index_substr_any_len = SLAP_INDEX_SUBSTR_ANY_LEN_DEFAULT; 161 unsigned int index_substr_any_step = SLAP_INDEX_SUBSTR_ANY_STEP_DEFAULT; In the current code, they are "ARG_INT" which convert -1 to be 4294967295. ==========================PATCH========================= @@ -399,13 +399,13 @@ { "index_substr_if_maxlen", "max", 2, 2, 0, ARG_UINT|ARG_NONZERO|ARG_MAGIC|CFG_SSTR_IF_MAX, &config_generic, "( OLcfgGlAt:21 NAME 'olcIndexSubstrIfMaxLen' " "SYNTAX OMsInteger SINGLE-VALUE )", NULL, NULL }, - { "index_substr_any_len", "len", 2, 2, 0, ARG_INT|ARG_NONZERO, + { "index_substr_any_len", "len", 2, 2, 0, ARG_UINT|ARG_NONZERO, &index_substr_any_len, "( OLcfgGlAt:22 NAME 'olcIndexSubstrAnyLen' " "SYNTAX OMsInteger SINGLE-VALUE )", NULL, NULL }, - { "index_substr_any_step", "step", 2, 2, 0, ARG_INT|ARG_NONZERO, + { "index_substr_any_step", "step", 2, 2, 0, ARG_UINT|ARG_NONZERO, &index_substr_any_step, "( OLcfgGlAt:23 NAME 'olcIndexSubstrAnyStep' " "SYNTAX OMsInteger SINGLE-VALUE )", NULL, NULL }, - { "index_intlen", "len", 2, 2, 0, ARG_INT|ARG_MAGIC|CFG_IX_INTLEN, + { "index_intlen", "len", 2, 2, 0, ARG_UINT|ARG_MAGIC|CFG_IX_INTLEN, &config_generic, "( OLcfgGlAt:84 NAME 'olcIndexIntLen' " "SYNTAX OMsInteger SINGLE-VALUE )", NULL, NULL }, { "lastmod", "on|off", 2, 2, 0, ARG_DB|ARG_ON_OFF|ARG_MAGIC|CFG_LASTMOD,

1 0

Re: (ITS#7448) "assertion failed" in MDB
by artemciy＠gmail.com 21 Nov '12

21 Nov '12

--047d7b10cce921f66204cf0610ec Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 21, 2012 at 10:15 PM, Howard Chu <hyc(a)symas.com> wrote: > More information is needed than this. Your stack traces aren't even > complete. This isn't relevant. > What was the workload leading up to this? I can try to make an ltrace log, would that suffice? Give us a sample configuration that reproduces the assert. > Don't have time to make a test case now. > artemciy(a)gmail.com wrote: > >> Full_Name: Artem Grinblat >> Version: git, commit be781ab8081d7e9ad1eb89da81077c**7f936a5604 >> OS: Debian Wheezy >> URL: >> Submission from: (NULL) (213.108.212.44) >> >> >> MDB works okay for some time, then crashes with >> >> mdb.c:3778: mdb_page_search_root: Assertion `(((mp)->mp_pb.pb.pb_lower - >> ((unsigned) __builtin_offsetof (MDB_page, mp_ptrs))) >> 1) > 1' failed. >> >> (gdb) bt >> #0 WriteCoreDump (file_name=0x7f1f1f705fa0 "/tmp/tntnet.5541.core") at >> src/coredumper.c:192 >> #1 0x00007f1f4b163da9 in img2::writeCore (path=0x7f1f1f705fa0 >> "/tmp/tntnet.5541.core") at src/conf.cpp:49 >> #2 0x00007f1f4b16145d in img2::custom_sigaction (signum=6) at >> src/conf.cpp:89 >> #3 <signal handler called> >> #4 0x00007f1f469ba475 in *__GI_raise (sig=<optimized out>) at >> ../nptl/sysdeps/unix/sysv/**linux/raise.c:64 >> #5 0x00007f1f469bd6f0 in *__GI_abort () at abort.c:92 >> #6 0x00007f1f469b3621 in *__GI___assert_fail ( >> assertion=assertion@entry=**0x7f1f4155cdb0 >> "(((mp)->mp_pb.pb.pb_lower - >> ((unsigned) __builtin_offsetof (MDB_page, mp_ptrs))) >> 1) > 1", >> file=<optimized >> out>, >> file@entry=0x7f1f4155cb30 "mdb.c", line=line@entry=3778, >> function=function@entry=**0x7f1f4155d360 "mdb_page_search_root") at >> assert.c:81 >> #7 0x00007f1f41555ccd in mdb_page_search_root (mc=mc@entry >> =0x7f1f1f708500, >> key=key@entry=0x0, modify=modify@entry=0) at mdb.c:3778 >> #8 0x00007f1f4155467a in mdb_page_search (mc=mc@entry=0x7f1f1f708500, >> key=key@entry=0x0, flags=flags@entry=0) at mdb.c:3908 >> #9 0x00007f1f41554a07 in mdb_cursor_first (mc=0x7f1f1f708500, >> key=key@entry=0x7f1f1f7070f0, data=data@entry=0x0) at mdb.c:4354 >> #10 0x00007f1f4155517e in mdb_cursor_set (mc=mc@entry=0x7f1f1f708370, >> key=key@entry=0x7f1f1f708770, data=data@entry=**0x7f1f1f7070f0, >> op=op@entry=MDB_SET, >> exactp=exactp@entry=**0x7f1f1f7070d4) at mdb.c:4307 >> #11 0x00007f1f41559c8d in mdb_cursor_put (mc=0x7f1f1f708370, >> key=0x7f1f1f708770, >> data=0x7f1f1f708790, flags=0) at mdb.c:4672 >> #12 0x00007f1f4155bdc9 in mdb_put (txn=<optimized out>, dbi=<optimized >> out>, >> key=0x7f1f1f708770, data=0x7f1f1f708790, flags=<optimized out>) at >> mdb.c:6599 >> >> Also under Valgrind: >> ==7503== Warning: set address range perms: large range [0x3959d000, >> 0x7959d000) >> (defined) >> **7503** custom_sigaction, signal 6 at 0x51B6EEC: >> VALGRIND_PRINTF_BACKTRACE(char const*, ...) (valgrind.h:3771) >> ==7503== by 0x51B72A1: img2::custom_sigaction(int) (conf.cpp:77) >> ==7503== by 0x985B4EF: ??? (in /lib/x86_64-linux-gnu/libc-2.**13.so<http://libc-2.13.so> >> ) >> ==7503== by 0x985B474: raise (raise.c:64) >> ==7503== by 0x985E6EF: abort (abort.c:92) >> ==7503== by 0x9854620: __assert_fail (assert.c:81) >> ==7503== by 0xEDD9CCC: mdb_page_search_root (mdb.c:3778) >> ==7503== by 0xEDD8679: mdb_page_search (mdb.c:3908) >> ==7503== by 0xEDD8F78: mdb_cursor_set (mdb.c:4268) >> ==7503== by 0xEDD8EB0: mdb_cursor_set (mdb.c:4316) >> ==7503== by 0xEDDFCA8: mdb_del (mdb.c:6165) >> >> >> > > -- > -- 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/> > --047d7b10cce921f66204cf0610ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Nov 21, 2012 at 10:15 PM, Howard Chu <<a href= =3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a>> wr= ote: <div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> More information is needed than this. Your stack traces aren't even com= plete.</blockquote><div> </div><div>This isn't relevant.</div><div>= =A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde= r-left:1px #ccc solid;padding-left:1ex"> What was the workload leading up to this?</blockquote><div> </div><div>= I can try to make an ltrace log, would that suffice?</div><div> </div><b= lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px = #ccc solid;padding-left:1ex"> Give us a sample configuration that reproduces the assert. </blockquote>= <div> </div><div>Don't have time to make a test case now.</div><div>= </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-left:1px #ccc solid;padding-left:1ex"> <a href=3D"mailto:artemciy@gmail.com" target=3D"_blank">artemciy(a)gmail.com<= /a> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Artem Grinblat Version: git, commit be781ab8081d7e9ad1eb89da81077c7f936a5604 OS: Debian Wheezy URL: Submission from: (NULL) (213.108.212.44) MDB works okay for some time, then crashes with mdb.c:3778: mdb_page_search_root: Assertion `(((mp)->mp_pb.pb.pb_lower -= ((unsigned) __builtin_offsetof (MDB_page, mp_ptrs))) >> 1) > 1&#39= ; failed. (gdb) bt #0 =A0WriteCoreDump (file_name=3D0x7f1f1f705fa0 "/tmp/tntnet.5541.core= ") at src/coredumper.c:192 #1 =A00x00007f1f4b163da9 in img2::writeCore (path=3D0x7f1f1f705fa0 "/tmp/tntnet.5541.core") at src/conf.cpp:49 #2 =A00x00007f1f4b16145d in img2::custom_sigaction (signum=3D6) at src/conf= .cpp:89 #3 =A0<signal handler called> #4 =A00x00007f1f469ba475 in *__GI_raise (sig=3D<optimized out>) at<br= > ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #5 =A00x00007f1f469bd6f0 in *__GI_abort () at abort.c:92 #6 =A00x00007f1f469b3621 in *__GI___assert_fail ( =A0 =A0 =A0assertion=3Dassertion@entry=3D0x7f1f4155cdb0 "(((mp)= ->mp_pb.pb.pb_lower - ((unsigned) __builtin_offsetof (MDB_page, mp_ptrs))) >> 1) > 1&quo= t;, file=3D<optimized out>, =A0 =A0 =A0file@entry=3D0x7f1f4155cb30 "mdb.c", line=3Dline@entry= =3D3778, function=3Dfunction@entry=3D0x7f1f4155d360 "mdb_page_search_roo= t") at assert.c:81 #7 =A00x00007f1f41555ccd in mdb_page_search_root (mc=3Dmc@entry=3D0x7f1f1f7= 08500, key=3Dkey@entry=3D0x0, modify=3Dmodify@entry=3D0) at mdb.c:3778 #8 =A00x00007f1f4155467a in mdb_page_search (mc=3Dmc@entry=3D0x7f1f1f708500= , key=3Dkey@entry=3D0x0, flags=3Dflags@entry=3D0) at mdb.c:3908 #9 =A00x00007f1f41554a07 in mdb_cursor_first (mc=3D0x7f1f1f708500, key=3Dkey@entry=3D0x7f1f1f7070f0, data=3Ddata@entry=3D0x0) at mdb.c:4354<br= > #10 0x00007f1f4155517e in mdb_cursor_set (mc=3Dmc@entry=3D0x7f1f1f708370,<b= r> key=3Dkey@entry=3D0x7f1f1f708770, data=3Ddata@entry=3D0x7f1f1f7070f0= , op=3Dop@entry=3DMDB_SET, =A0 =A0 =A0exactp=3Dexactp@entry=3D0x7f1f1f7070d4) at mdb.c:4307 #11 0x00007f1f41559c8d in mdb_cursor_put (mc=3D0x7f1f1f708370, key=3D0x7f1f= 1f708770, data=3D0x7f1f1f708790, flags=3D0) at mdb.c:4672 #12 0x00007f1f4155bdc9 in mdb_put (txn=3D<optimized out>, dbi=3D<o= ptimized out>, key=3D0x7f1f1f708770, data=3D0x7f1f1f708790, flags=3D<optimized out>)= at mdb.c:6599 Also under Valgrind: =3D=3D7503=3D=3D Warning: set address range perms: large range [0x3959d000,= 0x7959d000) (defined) **7503** custom_sigaction, signal 6 =A0 at 0x51B6EEC: VALGRIND_PRINTF_BACKTRACE(char const*, ...) (valgrind.h:3771) =3D=3D7503=3D=3D =A0 =A0by 0x51B72A1: img2::custom_sigaction(int) (conf.cpp= :77) =3D=3D7503=3D=3D =A0 =A0by 0x985B4EF: ??? (in /lib/x86_64-linux-gnu/<a href= =3D"http://libc-2.13.so" target=3D"_blank">libc-2.13.so</a>) =3D=3D7503=3D=3D =A0 =A0by 0x985B474: raise (raise.c:64) =3D=3D7503=3D=3D =A0 =A0by 0x985E6EF: abort (abort.c:92) =3D=3D7503=3D=3D =A0 =A0by 0x9854620: __assert_fail (assert.c:81) =3D=3D7503=3D=3D =A0 =A0by 0xEDD9CCC: mdb_page_search_root (mdb.c:3778) =3D=3D7503=3D=3D =A0 =A0by 0xEDD8679: mdb_page_search (mdb.c:3908) =3D=3D7503=3D=3D =A0 =A0by 0xEDD8F78: mdb_cursor_set (mdb.c:4268) =3D=3D7503=3D=3D =A0 =A0by 0xEDD8EB0: mdb_cursor_set (mdb.c:4316) =3D=3D7503=3D=3D =A0 =A0by 0xEDDFCA8: mdb_del (mdb.c:6165) </blockquote> -- =A0 -- Howard Chu =A0 CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a> =A0 Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a> =A0 Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> </div> --047d7b10cce921f66204cf0610ec--

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2012