openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#6361) Failed assertion in slapd when running on OpenWRT/glibc
by mike＠flyn.org 16 Nov '09

16 Nov '09

Followup 4 states that slapd did not initially crash when using "threads 1" and no indexes. In this case, slapd did eventually crash as before.

1 0

Re: (ITS#6304) Slapd freezes during SSL handshake when TLSVerifyClient=allow
by hyc＠symas.com 15 Nov '09

15 Nov '09

Jan Zelený wrote: > Dne čtvrtek 24 září 2009 22:19:40 Howard Chu napsal(a): >> jzeleny(a)redhat.com wrote: >>> Full_Name: Jan Zeleny >>> Version: 2.4.18 >>> OS: Fedora 11 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (62.40.79.66) >>> >> I'm unable to reproduce this using slapd on a debian x86-64 system, whether >> on the local LAN or from 13 hops away. I've also used the tcp-buffer >> option to set a minimum sized socket buffer and still could not duplicate >> the problem. You will need to provide more explicit information on how to >> reproduce this issue. Perhaps providing a set of CA/server certs will also >> be necessary. > I'm not sure I have much more explicit information for you. I'm sending > certificate in attachment. It's a self signed testing certificate I generated on > my system. I'm also sending you slapd.conf with relevant information and CA > bundle file. If you need anything else, just let me know. > > Just for complete information: > I tried slapd on Fedora 12 and RHEL 5.3 (x86_64) and on Ubuntu 9.04 (i386). On > each system I used different self signed certificate. In both cases attached > slapd.conf file was used. To reproduce error, I just started the slapd service > (slapd -h 'ldaps:///' -u ldap) with given config file and connected to it. When > I tried to connect with openssl s_client -connect fedora12-64, I received this > output (and then freeze): > > CONNECTED(00000003) > depth=0 /C=CZ/ST=Moravia/L=Brno/O=Red Hat Czech > s.r.o./OU=Engineering/CN=fedora12-64/emailAddress=jzeleny(a)redhat.com > verify error:num=18:self signed certificate > verify return:1 > depth=0 /C=CZ/ST=Moravia/L=Brno/O=Red Hat Czech > s.r.o./OU=Engineering/CN=fedora12-64/emailAddress=jzeleny(a)redhat.com > verify return:1 > > >> Please note that the bug report you reference (509230) gives inconsistent >> information; it says that no hang occurs with -d2, but that hangs occur >> with no diagnostics, even with -d -1. Obviously -d -1 includes -d 2, so: >> does it hang, or not, with -d -1? > > I believe what is stated there is that hangs don't occur with -d2, but they do > with -d1 (not -d -1). I can also confirm this behaviour, that with -d1 hangs > occur, but with -d2 they don't. (or at least I didn't encounter them during my > testing). > > Hopefully I provided some useful information. Thanks, that helped, a fix is now in CVS HEAD. I should point out that the configuration used to reproduce this problem is quite a poor one. As the OpenLDAP Admin Guide clearly states, your server should only be configured with the CA certs for which it will accept client certs. Your ca-bundle.crt file is 670KB and loaded with a lot of CAs that are irrelevant; it's when slapd sends the client its list of acceptable CAs that the connection was getting jammed. -- -- 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#6325) test054: test failed - producer and consumer databases differ
by michael＠stroeder.com 15 Nov '09

15 Nov '09

hyc(a)symas.com wrote: > hyc(a)symas.com wrote: >> michael(a)stroeder.com wrote: >>> Download testrun/ here: >>> >>> http://www.stroeder.com/temp/openldap/its6325-test054-testrun.tar.gz >> It's certainly a mystery. The *.flt shows that an entry is missing on the >> slave. The slapd.1.log shows that the provider sent the entry. The slapd.4.log >> shows that the consumer received the entry and ignored it. (See slapd.4.log >> line 3307-3313. Compare with the previously received entry, lines 3161-3169.) >> >> The most puzzling part is that every code path in the consumer that rejects an >> entry logs an error message, and there is no error message in the log file. >> Without any means to reproduce this there's not much we can do. Setting a >> higher debug level might be useful, but any error messages in this path should >> have shown up regardless. > > The same problem is in your ITS#6126 logs. The entry was received on the > consumer but skipped without any error message. > > I see now, the entry was skipped because its CSN was too old. (And that CSN > too old message is only logged with SYNC debug is enabled.) This should be > fixed by the patch for ITS#6346. > > It was also suggested that we should only reject mods if their CSN is actually > older than the target entry's CSN. That's still a possibility if the current > patch is insufficient. These ITS were filed based on failed test runs on my old Pentium III Mobile 1,8 GHz laptop (now broken). I always suspected that it might be something others won't see because their hardware is faster. Maybe it would be good to run the test suite on really slow systems from time to time. Ciao, Michael.

1 0

Re: (ITS#6325) test054: test failed - producer and consumer databases differ
by hyc＠symas.com 15 Nov '09

15 Nov '09

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Download testrun/ here: >> >> http://www.stroeder.com/temp/openldap/its6325-test054-testrun.tar.gz > > It's certainly a mystery. The *.flt shows that an entry is missing on the > slave. The slapd.1.log shows that the provider sent the entry. The slapd.4.log > shows that the consumer received the entry and ignored it. (See slapd.4.log > line 3307-3313. Compare with the previously received entry, lines 3161-3169.) > > The most puzzling part is that every code path in the consumer that rejects an > entry logs an error message, and there is no error message in the log file. > Without any means to reproduce this there's not much we can do. Setting a > higher debug level might be useful, but any error messages in this path should > have shown up regardless. The same problem is in your ITS#6126 logs. The entry was received on the consumer but skipped without any error message. I see now, the entry was skipped because its CSN was too old. (And that CSN too old message is only logged with SYNC debug is enabled.) This should be fixed by the patch for ITS#6346. It was also suggested that we should only reject mods if their CSN is actually older than the target entry's CSN. That's still a possibility if the current patch is insufficient. -- -- 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#6200) slapd crashes under load w/ syncrepl
by hyc＠symas.com 15 Nov '09

15 Nov '09

joacim.breiler(a)hgo.se wrote: > Thanks for your fast replies! The 'make install STRIP=""' did the trick. > > I ran the server for about a week with no segfaults, then I decided that > I couldn't wait for it any longer. So I connected to the server using an > LDAP browser, and then after about ten minutes it segfaulted. So to > reproduce I need one connection that is reading/updating/creating > entries. And one connection that does an occasional read, otherwise the > server will keep on running. > > The traceback from gdb gives: This trace looks like the problem fixed in ITS#6335. The fix is in CVS HEAD and RE24 (2.4.20 pre-release). > > 0x00007f96c3fc00ad in syncprov_op_mod (op=0x7f9688000ac0, rs=0x44688c80) > at syncprov.c:1970 > 1970 for ( m2 = mt->mt_mods; m2->mi_next != mi; > (gdb) where > #0 0x00007f96c3fc00ad in syncprov_op_mod (op=0x7f9688000ac0, > rs=0x44688c80) at syncprov.c:1970 > #1 0x00000000004c438a in overlay_op_walk (op=0x7f9688000ac0, > rs=0x44688c80, which=op_modify, oi=0x12293c0, on=0x12295a0) at > backover.c:659 > #2 0x00000000004c4667 in over_op_func (op=0x7f9688000ac0, > rs=0x44688c80, which=op_modify) at backover.c:721 > #3 0x00000000004c47ac in over_op_modify (op=0x7f9688000ac0, > rs=0x44688c80) at backover.c:760 > #4 0x000000000045bb21 in fe_op_modify (op=0x7f9688000ac0, > rs=0x44688c80) at modify.c:301 > #5 0x000000000045b430 in do_modify (op=0x7f9688000ac0, rs=0x44688c80) > at modify.c:175 > #6 0x000000000043c3ec in connection_operation (ctx=0x44688de0, > arg_v=0x7f9688000ac0) at connection.c:1123 > #7 0x000000000043c975 in connection_read_thread (ctx=0x44688de0, > argv=0x17) at connection.c:1259 > #8 0x0000000000525193 in ldap_int_thread_pool_wrapper (xpool=0x1190290) > at tpool.c:685 > #9 0x00007f96c49613ea in start_thread () from /lib/libpthread.so.0 > #10 0x00007f96c44b9cbd in clone () from /lib/libc.so.6 > #11 0x0000000000000000 in ?? () > > /J -- -- 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#6325) test054: test failed - producer and consumer databases differ
by hyc＠symas.com 15 Nov '09

15 Nov '09

michael(a)stroeder.com wrote: > Download testrun/ here: > > http://www.stroeder.com/temp/openldap/its6325-test054-testrun.tar.gz It's certainly a mystery. The *.flt shows that an entry is missing on the slave. The slapd.1.log shows that the provider sent the entry. The slapd.4.log shows that the consumer received the entry and ignored it. (See slapd.4.log line 3307-3313. Compare with the previously received entry, lines 3161-3169.) The most puzzling part is that every code path in the consumer that rejects an entry logs an error message, and there is no error message in the log file. Without any means to reproduce this there's not much we can do. Setting a higher debug level might be useful, but any error messages in this path should have shown up regardless. -- -- 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: RE : (ITS#6367) syncprov ... changed by peer, ignored
by hyc＠symas.com 15 Nov '09

15 Nov '09

CHIROSSEL Olivier wrote: > sorry for this > > the url is ok now Thanks. This is now fixed in HEAD. > > Cdt, > > Olivier > ________________________________________ > De : Howard Chu [hyc(a)symas.com] > Date d'envoi : vendredi 13 novembre 2009 23:33 > À : CHIROSSEL Olivier > Cc : openldap-its(a)openldap.org > Objet : Re: (ITS#6367) syncprov ... changed by peer, ignored > > olivier.chirossel(a)sfr.com wrote: >> Full_Name: olivier chirossel >> Version: 2.4.17 and 2.4.19 >> OS: linux >> URL: http://86.64.145.174:8080/ >> Submission from: (NULL) (62.39.9.251) >> >> >> in refreshend persist mode, the replication is incorrect for an entry which be >> delete/add after master restart and before the reconnection of the slave. > >> 2) master set up >> >> on /etc/openldap tar xvf slapd_master.tar (get on the url ) > > The URL you provided always times out for me, so I've been unable to set up > this test. > -- -- 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#6362) slapd 2.4.19 Segmentation fault under load
by hyc＠symas.com 15 Nov '09

15 Nov '09

alexs(a)ulgsm.ru wrote: > Full_Name: Aleksey > Version: 2.4.19 > OS: Freebsd7.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (93.93.136.26) > > > Openldap 2.4.19 installed from freebsd ports. All configs in defauls > Freebsd 7.2 amd64 > Slapd built with the "-g" flag and install with the make install STRIP="" > > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. > In slapd config added using hdb as backend and indexes. > > Testing database consist of 1000 users accounts with minimum attributes. > > On stress test load slapd Segmentation fault in 10-30 sec. Looks like you've had a stack overrun. The "be" parameter should be the same in your frame 0 and frame 1. > #gdb /usr/local/libexec/slapd > (gdb) run -d 0 > Starting program: /usr/local/libexec/slapd -d 0 > [New LWP 100311] > [New Thread 0x801a020b0 (LWP 100311)] > [New Thread 0x801a02880 (LWP 100073)] > [New Thread 0x8034040b0 (LWP 100076)] > [New Thread 0x803404240 (LWP 100077)] > [New Thread 0x8034043d0 (LWP 100078)] > [New Thread 0x803404560 (LWP 100116)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x803404560 (LWP 100116)] > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory address > 0x7ffffd9f9f38: Bad s. > ) at idl.c:511 > 511 { > (gdb) > (gdb) > (gdb) where > #0 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory > address 0x7ffffd9f9f38: dress. > ) at idl.c:511 > #1 0x0000000802d50dc5 in hdb_key_read (be=0x801a853d0, db=0x803519800, > txn=0x80352b040, k=0x8069005 > 70, ids=0x806a00000, saved_cursor=0x0, get_flag=0) at key.c:50 > #2 0x0000000802d5363c in equality_candidates (op=0x803521000, rtxn=0x80352b040, > ava=0x7ffffda7a4f0, > ids=0x806c00000, tmp=0x806a00000) at filterindex.c:788 > #3 0x0000000802d51d10 in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a550, > ids=0x806c00000, tmp=0x806a00000, stack=0x806d00000) at filterindex.c:154 > #4 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > flist=0x7ffffda7a5 f > type=161, ids=0x806b00000, tmp=0x806a00000, save=0x806c00000) at > filterindex.c:581 > #5 0x0000000802d5229c in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a530, > ids=0x806b00000, tmp=0x806a00000, stack=0x806c00000) at filterindex.c:204 > #6 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > flist=0x7ffffda7a5 f > type=160, ids=0x7ffffdafa760, tmp=0x806a00000, save=0x806b00000) at > filterindex.c:581 > #7 0x0000000802d521e4 in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a570, > ids=0x7ffffdafa760, tmp=0x806a00000, stack=0x806b00000) at filterindex.c: > #8 0x0000000802d4dca9 in search_candidates (op=0x803521000, rs=0x7ffffdbfab30, > e=0x7ffffda7a71 tx > n=0x80352b040, ids=0x7ffffdafa760, scopes=0x7ffffda7a760) at search.c:1206 > #9 0x0000000802d4befa in hdb_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:586 > #10 0x0000000000439bb5 in fe_op_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:366 > #11 0x0000000000439520 in do_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:217 > #12 0x000000000043613d in connection_operation (ctx=0x7ffffdbfac70, > arg_v=0x803521000) at connection > .c:1123 > #13 0x00000000004366d9 in connection_read_thread (ctx=0x7ffffdbfac70, argv=0x12) > at connection.c:125 > 9 > #14 0x0000000800797052 in ldap_int_thread_pool_wrapper () from > /usr/local/lib/libldap_r-2.4.so. > #15 0x000000080164b4d1 in pthread_getprio () from /lib/libthr.so.3 > #16 0x0000000000000000 in ?? () > Error accessing memory address 0x7ffffdbfb000: Bad address. -- -- 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#6381) connection_fake_init() from db_open() is unsafe
by hyc＠OpenLDAP.org 15 Nov '09

15 Nov '09

Full_Name: Howard Chu Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Originally the db_open() handlers only ran from slapd's main context, at startup time before threading was active. But with back-config, backends and overlays can be added at runtime and the db_open() handler then runs in a back-config operation thread. If a db_open handler calls connection_fake_init() using its current thread context, it will get the current sl_malloc memory context as well, and reset it to zero. Any sl_mallocs called up to that point will be forgotten and they'll be overwritten by subsequent calls in that thread. We never saw any problems with this prior to ITS#6380, because the prior mallocs tended to be higher up in the sl_malloc heap. So even though the heap was reset, the new mallocs didn't collide with the old ones. This is already fixed in HEAD: back-sql/init.c, back-monitor/init.c, and overlays/{dds.c, pcache.c, syncprov.c}

1 0

(ITS#6380) slap_sl_free is too lazy
by hyc＠OpenLDAP.org 15 Nov '09

15 Nov '09

Full_Name: Howard Chu Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc slap_sl_free() would only reclaim memory if you were freeing the last allocated block. If you wanted to free a chain of alloc'd memory you would have to free them in the exact reverse order of allocation. Calling slap_sl_free() out of order would be a no-op. This was OK most of the time because a single operation would seldom live long enough to use much memory. But for long-lived tasks (like syncrepl or syncprov) it would often run out and allocs would fallback to ch_malloc. sl_malloc.c in HEAD has been changed to mark freed blocks no matter what order they're freed in. It still only reclaims from the last block forward, but it's more effective now.

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