Full_Name: Geert Hendrickx Version: 2.3.27 OS: NetBSD/amd64 URL: ftp://ftp.openldap.org/incoming/slapd-bus-error.out Submission from: (NULL) (84.193.54.131) I'm running OpenLDAP 2.3.27 (latest stable release) on NetBSD 3.1 (latest stable release) on x86_64 (amd64), using a default slapd.conf file. Backend is BDB 4.4.20 (latest stable release). When running "ldapsearch -b dc=mydomain,dc=be mail=myuser@mydomain.tld maildrop" (where dc=mydomain,dc=tld is the rootdn), everything is fine. However when I do the same search in a subtree (where the looked up object is actually located), e.g. "ldapsearch -b ou=hosting,dc=mydomain,dc=tld mail=myuser@mydomain.tld maildrop", slapd returns an answer and then crashes (bus error) every time. This does not happen when I search in the rootdn, or in a non-existing subtree. It does happen when I search for a non-existing object in an existing subtree. This is the first OpenLDAP setup I'm running on a 64-bit system. I manage severel OpenLDAP setups on 32-bit NetBSD systems and I've never seen it there. I'm not sure 64-bit is the cause though, as the setups are not identical (different schema's etc). In the provided "slapd -d -1" output, I first ran a (successful) search in the rootdn, then a (successful) search in a subtree, after which slapd crashed.
--On Monday, September 18, 2006 7:15 PM +0000 ghen@telenet.be wrote: > Full_Name: Geert Hendrickx > Version: 2.3.27 > OS: NetBSD/amd64 > URL: ftp://ftp.openldap.org/incoming/slapd-bus-error.out > Submission from: (NULL) (84.193.54.131) > > > I'm running OpenLDAP 2.3.27 (latest stable release) on NetBSD 3.1 (latest > stable release) on x86_64 (amd64), using a default slapd.conf file. > Backend is BDB 4.4.20 (latest stable release). What OpenLDAP database type are you using? bdb, hdb, ldbm? --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
On Mon, Sep 18, 2006 at 12:32:44PM -0700, Quanah Gibson-Mount wrote: > --On Monday, September 18, 2006 7:15 PM +0000 ghen@telenet.be wrote: > >I'm running OpenLDAP 2.3.27 (latest stable release) on NetBSD 3.1 (latest > >stable release) on x86_64 (amd64), using a default slapd.conf file. > >Backend is BDB 4.4.20 (latest stable release). > > What OpenLDAP database type are you using? bdb, hdb, ldbm? bdb. Here is my slapd.conf (comments removed). include /etc/pkg/openldap/schema/core.schema include /etc/pkg/openldap/schema/cosine.schema include /etc/pkg/openldap/schema/nis.schema include /etc/pkg/openldap/schema/authldap.schema include /etc/pkg/openldap/schema/inetorgperson.schema pidfile /var/db/openldap/run/slapd.pid argsfile /var/db/openldap/run/slapd.args database bdb suffix "dc=ghen,dc=be" rootdn "cn=Manager,dc=ghen,dc=be" rootpw {SSHA}... directory /var/db/openldap/openldap-data index objectClass eq index mail,cn eq Geert
The problem goes away if I bump my stacksize ulimit. I'll use that as a workaround for now. Geert
ghen@telenet.be wrote: > The problem goes away if I bump my stacksize ulimit. I'll use that as a > workaround for now. Ordinarily libldap_r will use double the stack on 64bit machines vs 32bit machines for its worker threads. The process stacksize limit should have no effect unless you built slapd without threads. Are you using threads? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/
On Thu, Sep 21, 2006 at 12:49:00AM -0700, Howard Chu wrote: > ghen@telenet.be wrote: > >The problem goes away if I bump my stacksize ulimit. I'll use that as > >a workaround for now. > > Ordinarily libldap_r will use double the stack on 64bit machines vs 32bit > machines for its worker threads. The process stacksize limit should have > no effect unless you built slapd without threads. Are you using threads? slapd has been ./configure'd --with-threads, and ldd shows its indeed linked with -lpthread. Traffic however is (still) very low at this site, so only one thread is actually running. Geert
changed notes changed state Open to Feedback
changed state Feedback to Closed
Why was tick ticket closed? The problem still exists. Geert
--On Wednesday, November 15, 2006 3:53 PM +0000 ghen@telenet.be wrote: > Why was tick ticket closed? The problem still exists. Did you read the notes in the ITS system? --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
On Fri, Nov 17, 2006 at 12:19:58PM -0800, Quanah Gibson-Mount wrote: > --On Wednesday, November 15, 2006 3:53 PM +0000 ghen@telenet.be wrote: > >Why was tick ticket closed? The problem still exists. > > Did you read the notes in the ITS system? I did. It says "NetBSD-specific, raise stacksize ulimit". I hope you don't count such a work-around as a fix... Geert
ghen@telenet.be wrote: > On Fri, Nov 17, 2006 at 12:19:58PM -0800, Quanah Gibson-Mount wrote: >> --On Wednesday, November 15, 2006 3:53 PM +0000 ghen@telenet.be wrote: >>> Why was tick ticket closed? The problem still exists. >> Did you read the notes in the ITS system? > > I did. It says "NetBSD-specific, raise stacksize ulimit". I hope you > don't count such a work-around as a fix... The fact that altering your ulimit changes the behavior indicates that your OS's pthread implementation is broken. We cannot fix that. We use the documented, portable pthread API to specify the stack size that we need for each thread, and it seems your platform will not honor our request without you raising your ulimit. The stacksize ulimit should only affect non-threaded processes, or the main thread in a threaded process. It should not affect any threads created by the application, especially when we set an explicit size at thread creation time. So you have to set an explicit ulimit before starting slapd. This is no different from having to set the nfiles limit on some platforms to raise the number of available file descriptors. That's an administration detail, not a software bug. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/
moved from Incoming to Archive.Incoming
NetBSD-specific, raise stacksize ulimit.