On Fri, Apr 15, 2005 at 08:40:59AM +0200, [EMAIL PROTECTED] wrote: > >Well, in spite of the lack of detail, I have been able to reproduce this > >crash when running slapd on an alpha with a 2.6 kernel. I'm currently > >working on rebuilding openldap with debugging symbols so I can get a > >sensible backtrace.
> Well, sorry for the lack of detail. I have just upgraded slapd from > 2.1.30 to 2.2.23 via apt-get dist-upgrade. I wasn't able to get it > running again. Using the backup copy of the database or replaying the > data from ldif didn't help. So I had to downgrade to 2.1.30. Yes, this doesn't look like it'll be fixed very quickly, so that's probably best. > >The bug was not reproducible using a trivial default directory; I had to > >throw a sizable chunk of real data into slapd to trigger the failure. > Well, I haven't that much date in the directory. Only about 30. I use > LDAP for managing my samba and unix user accounts. Maybe there are some > special case characters which cause the termination. All signs point to this being an alpha-specific problem with the handling of per-thread stacks. Even though slapd explicitly sets the stack size to 4MB using pthread_attr_setstacksize(), the moment the stack needs to grow beyond 2MB, a segfault occurs. Unsurprisingly (since we're not at the limit yet), bumping slapd's hard-coded limit to 8MB has no effect. In either case, we don't seem to be hitting a ulimit either, since raising the stack ulimit also has no effect. I'm going to try to get some glibc eyeballs on this issue; it really doesn't look like a bug in OpenLDAP to me. -- Steve Langasek postmodern programmer
signature.asc
Description: Digital signature
