openldap-bugs March 2008

openldap-bugs@openldap.org

34 participants
162 discussions

Re: (ITS#5416) slapd core dump
by ando＠sys-net.it 13 Mar '08

13 Mar '08

rui.yan(a)gmail.com wrote: > Full_Name: yanr > Version: 2.4.8 > OS: Linux 2.6.22 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.221.197.21) > > > Verion: 2.4.8 > Desc: client runs some codes like ldap_modify_ext, sometimes slapd core dump. > The same codes works on 2.3.38. > > [root@test1 /]# uname -r > 2.6.22.9-2.smp.gcc3.4.x86_64 > > (gdb) bt > > #0 0x00002b018fa6da3d in *__GI_raise (sig=19040) > at ../nptl/sysdeps/unix/sysv/linux/raise.c:67 > 67 int res = INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); > (gdb) bt > #0 0x00002b018fa6da3d in *__GI_raise (sig=19040) > at ../nptl/sysdeps/unix/sysv/linux/raise.c:67 > #1 0x00002b018fa6ef1e in *__GI_abort () at ../sysdeps/generic/abort.c:88 > #2 0x00002b018fa67720 in *__GI___assert_fail (assertion=0x56ad43 "i > 0", > file=0x56acf8 "schema_init.c", line=366, > function=0x56ad30 "octetStringIndexer") at assert.c:83 > #3 0x00000000004664b3 in octetStringIndexer (use=163, flags=4, > syntax=0x77ea70, mr=0x77ed70, prefix=0x77ec48, values=0x2aaaaacad6b0, > keysp=0x42001598, ctx=0x83d970) at schema_init.c:366 > #4 0x000000000046ffde in objectSubClassIndexer (use=163, mask=4, > syntax=0x77ea70, mr=0x77ed70, prefix=0x77ec48, values=0x87b7e0, > keysp=0x42001598, ctx=0x83d970) at schema_prep.c:305 You should provide: - your slapd.conf - the LDIF of the modification that caused the issue - the contents of some variables from gdb: (gdb) frame 4 (gdb) print nocs (gdb) print values (gdb) print values[0] p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5420) test048-syncrepl-multiproxy: ldapsearch failed at P1 slave (32)!
by hyc＠symas.com 13 Mar '08

13 Mar '08

Dup of ITS#5419. michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: OpenSUSE Linux 10.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.68.253) > > > make test fails with current HEAD synced right now. > > michael@nb2:~/src/openldap/HEAD/openldap/tests> ./run -b bdb test048 > Cleaning up test run directory leftover from previous run. > Running ./scripts/test048-syncrepl-multiproxy... > running defines.sh > Starting master slapd on TCP/IP port 9011... > Using ldapsearch to check that master slapd is running... > Using ldapadd to create the context prefix entry in the master... > Starting P1 slave slapd on TCP/IP port 9012... > Using ldapsearch to check that P1 slave slapd is running... > Starting R1 slave slapd on TCP/IP port 9013... > Using ldapsearch to check that R1 slave slapd is running... > 1> Using ldapadd to populate the master directory... > Waiting 15 seconds for syncrepl to receive changes... > ldapsearch failed at P1 slave (32)! > > > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5420) test048-syncrepl-multiproxy: ldapsearch failed at P1 slave (32)!
by michael＠stroeder.com 13 Mar '08

13 Mar '08

Full_Name: Michael Ströder Version: HEAD OS: OpenSUSE Linux 10.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.68.253) make test fails with current HEAD synced right now. michael@nb2:~/src/openldap/HEAD/openldap/tests> ./run -b bdb test048 Cleaning up test run directory leftover from previous run. Running ./scripts/test048-syncrepl-multiproxy... running defines.sh Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... Using ldapadd to create the context prefix entry in the master... Starting P1 slave slapd on TCP/IP port 9012... Using ldapsearch to check that P1 slave slapd is running... Starting R1 slave slapd on TCP/IP port 9013... Using ldapsearch to check that R1 slave slapd is running... 1 > Using ldapadd to populate the master directory... Waiting 15 seconds for syncrepl to receive changes... ldapsearch failed at P1 slave (32)!

1 0

Re: (ITS#5419) test048 fails...
by h.b.furuseth＠usit.uio.no 13 Mar '08

13 Mar '08

hyc(a)symas.com writes: > op->o_bd is essentially supposed to be a constant once it is set on an > operation. Operations within a backend are generally not allowed to > access other backends so it should not be overriding the backend that > was given to it. "grep -n -e '.->o_bd *=[^=]' *.c */*.c" finds 10 from 'orig'something. Some of the other 202 matches also restore an old o_bd. -- Hallvard

1 0

Re: (ITS#5419) test048 fails...
by hyc＠symas.com 13 Mar '08

13 Mar '08

luca(a)OpenLDAP.org wrote: > Full_Name: Luca Scamoni > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > > > consistently > > Running ./scripts/test048-syncrepl-multiproxy... > running defines.sh > Starting master slapd on TCP/IP port 9011... > Using ldapsearch to check that master slapd is running... > Using ldapadd to create the context prefix entry in the master... > Starting P1 slave slapd on TCP/IP port 9012... > Using ldapsearch to check that P1 slave slapd is running... > Starting R1 slave slapd on TCP/IP port 9013... > Using ldapsearch to check that R1 slave slapd is running... > 1> Using ldapadd to populate the master directory... > Waiting 15 seconds for syncrepl to receive changes... > ldapsearch failed at P1 slave (32)! > > modifications to the master are not propagated to the slaves Yes, I see this as well. syncrepl is trying to use backend_attribute() to retrieve the underlying DB's contextCSN, but backend_attribute is discarding the current op->o_bd and using select_backend() to pick which backend to query. This is definitely the wrong behavior; op->o_bd is essentially supposed to be a constant once it is set on an operation. Operations within a backend are generally not allowed to access other backends so it should not be overriding the backend that was given to it. -- -- Howard Chu Chief Architect, 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#5391) hdb deadlock
by h.b.furuseth＠usit.uio.no 13 Mar '08

13 Mar '08

hyc(a)symas.com writes: >Hallvard B Furuseth wrote: >> How about making #bytes-based checkpoints signal or (pthread_kill?) the >> timed checkpoints thread, so that thread can handle all checkpoints? > > It's an interesting idea. But that means we have to count bytes ourselves, > rather than letting BerkeleyDB do it. Whoops, good point. > Personally I don't think byte counts are very useful here. They're made > somewhat superfluous because the data volume will tend to cause the > transaction log buffers to fill up and be flushed regardless. I don't think Berkeley DB writes a checkpoint record then, at least I don't see that in the docs. If not, #bytes do help keep recovery and checkpoint times down. Anyway, unless you are proposing to ignore the #bytes parameter: If this is a Berkeley DB bug we could hear what they say, and in the meantime put a mutex_trylock around checpoints. Unless db has some feature which defeats that, like if txn_checkpoint() merely schedules a checkpoint. #define CHECKPOINT_WORKAROUND /* hopefully an ITS#5391 workaround */ struct bdb_info { ... #ifdef CHECKPOINT_WORKAROUND # ldap_pvt_thread_mutex_t bi_checkpoint_mutex; #define CHECKPOINT_LOCK(op, bdb) op(&(bdb)->bi_checkpoint_mutex) #else #define CHECKPOINT_LOCK(op, bdb) 0 #endif ... }; #define TXN_CHECKPOINT(bdb, k, m, f) do { \ if ( CHECKPOINT_LOCK( ldap_pvt_thread_mutex_trylock, bdb ) == 0 ) { \ (bdb)->bi_dbenv->txn_checkpoint( (bdb)->bi_dbenv, k, m, f ); \ (void) CHECKPOINT_LOCK( ldap_pvt_thread_mutex_unlock, bdb ); \ } \ } while (0) -- Hallvard

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by jclarke＠linagora.com 13 Mar '08

13 Mar '08

Hi, michael(a)stroeder.com a écrit : > I'd be interested to add support for something like this to my LDAP client. > > BTW: I'd vote against ";x-allowed" or ";x-required" since a schema-aware > client can already determine this in a non-proprietary way from the subschema. > > The overlay's source is quite old. Does it still build with recent HEAD? I'm also interested in an overlay of this type. I started hacking into it recently, and don't remember any problems getting it to build on HEAD (a couple of months ago). This was related to an implementation of Get Effective Rights [1], which returns rights the current user has on each attribute in an object. I had a premilinary working version, but it did not work as a control, just returned extra attributes. Similarly, this would be useful to LDAP GUI clients. If you're interested, I could dig out the code. [1] http://directory.fedoraproject.org/wiki/Get_Effective_Rights_Design and http://www.ietf.org/proceedings/01dec/I-D/draft-ietf-ldapext-acl-model-08.t… Regards, Jonathan -- Jonathan Clarke Cellule OSSA - Groupe LINAGORA 27 rue de Berri, 75008 Paris Tél: 01 58 18 68 28, fax: 01 58 18 68 29 http://www.linagora.com - http://www.08000linux.com

1 0

(ITS#5419) test048 fails...
by luca＠OpenLDAP.org 13 Mar '08

13 Mar '08

Full_Name: Luca Scamoni Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) consistently Running ./scripts/test048-syncrepl-multiproxy... running defines.sh Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... Using ldapadd to create the context prefix entry in the master... Starting P1 slave slapd on TCP/IP port 9012... Using ldapsearch to check that P1 slave slapd is running... Starting R1 slave slapd on TCP/IP port 9013... Using ldapsearch to check that R1 slave slapd is running... 1 > Using ldapadd to populate the master directory... Waiting 15 seconds for syncrepl to receive changes... ldapsearch failed at P1 slave (32)! modifications to the master are not propagated to the slaves

1 0

Re: (ITS#5391) hdb deadlock
by hyc＠symas.com 13 Mar '08

13 Mar '08

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> One thing that I've started doing recently in my configs is to skip >> the #bytes option (leave it zero), so that only time-based checkpoints >> occur. Since they're done in a dedicated task, only one thread at a >> time can trigger a checkpoint. > > How about making #bytes-based checkpoints signal or (pthread_kill?) the > timed checkpoints thread, so that thread can handle all checkpoints? It's an interesting idea. But that means we have to count bytes ourselves, rather than letting BerkeleyDB do it. And that's rather difficult, since we don't know the actual volume of writes resulting from a given operation. Personally I don't think byte counts are very useful here. They're made somewhat superfluous because the data volume will tend to cause the transaction log buffers to fill up and be flushed regardless. -- -- Howard Chu Chief Architect, 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#5401) slapd crashes in mirrormode
by hyc＠symas.com 13 Mar '08

13 Mar '08

A patch for this is now in CVS HEAD. Please test. I was unable to reproduce the reported crash, so your feedback is important here. ali.pouya(a)free.fr wrote: > Full_Name: Ali Pouya > Version: 2.4.8 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (145.242.11.4) > > > Hi, > I am testing OpenLdap 2.4.8 in mirrormode. > I have two mirror servers (A, and B) synchronized in SearchAndPersist mode with > a retry interval of 10 seconds : retry="10 +". > An injector writes data to A. The data is replicated in B. But this server > UNBINDs then reBINDs to A every 10 seconds ! > This continues until slapd on A crashes with a SIGIOT. More investigation in the > slapd log shows that the crash is caused by the losing of the client syncrepl > connection coming from B ! -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2008