slapd 2.1.29 crashes
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
openldap2.2 (Debian) |
Fix Released
|
Unknown
|
|||
openldap2.2 (Ubuntu) |
Invalid
|
High
|
Fabio Massimo Di Nitto |
Bug Description
Automatically imported from Debian bug report #244827
http://
In Debian Bug tracker #244827, Nikita V. Youshchenko (yoush) wrote : same happens here ... | #1 |
In Debian Bug tracker #244827, srd (sr-gimp) wrote : Continued slapd breakage with 2.1.30-1 | #2 |
Package: slapd
Version: 2.1.30-1
Severity: normal
Followup-For: Bug #244827
I have a very similar configuration as Michael Berg (slapd for user
authentication with tls, postfix mta and fetchmail running
periodically), and the problem persists with version 2.1.30-1.
Regs,
Sven
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.6
Locale: LANG=C, LC_CTYPE=C
Versions of packages slapd depends on:
ii coreutils [fileutils] 5.0.91-2 The GNU core utilities
ii debconf 1.4.25 Debian configuration management sy
ii fileutils 5.0.91-2 The GNU file management utilities
ii libc6 2.3.2.ds1-12 GNU C Library: Shared libraries an
ii libdb4.2 4.2.52-16 Berkeley v4.2 Database Libraries [
ii libgcrypt7 1.1.90-1.1 LGPL Crypto library - runtime libr
ii libgnutls10 1.0.4-3 GNU TLS library - runtime library
ii libgpg-error0 0.7-1 library for common error values an
ii libiodbc2 3.51.2-2 iODBC Driver Manager
ii libldap2 2.1.30-1 OpenLDAP libraries
ii libltdl3 1.5.6-1 A system independent dlopen wrappe
ii libsasl2 2.1.18-4.1 Authentication abstraction library
ii libslp1 1.0.11-7 OpenSLP libraries
ii libtasn1-2 0.2.7-2 Manage ASN.1 structures (runtime)
ii libwrap0 7.6.dbs-4 Wietse Venema's TCP wrappers libra
ii perl [libmime-
ii psmisc 21.5-1 Utilities that use the proc filesy
ii zlib1g 1:1.2.1.1-3 compression library - runtime
-- debconf information excluded
In Debian Bug tracker #244827, srd (sr-gimp) wrote : Some feedback from maintainer? | #3 |
Hi,
since the package maintainer hasn't said anything to this bugreport at all
(at least from what is viewable in the bug tracking system), I would
like him to just make a short statement as to the status of the bug
resolution.
Even something along the lines of "Can't reproduce, no clue
and no time right now" would be nice to have, since this bug is really
annoying and persistant. I'd hate to download openldap, compile and
install everything by hand to have the bug resolved in debian tomorrow,
but I'd also hate having to wait with a bandaged network for weeks
without knowing what's up.
It's been 40 days since the bug was first reported and considered
"grave", so some information from the maintainer would be nice to have.
Regs,
Sven
--
Sven Riedel <email address hidden>
Liebigstr. 38
30163 Hannover "Python is merely Perl for those who
In Debian Bug tracker #244827, Torsten Landschoff (torsten) wrote : Re: Bug#244827: Some feedback from maintainer? | #4 |
Hi Sven,
On Sun, May 30, 2004 at 04:52:34PM +0200, Sven Riedel wrote:
> Even something along the lines of "Can't reproduce, no clue
> and no time right now" would be nice to have, since this bug is really
> annoying and persistant. I'd hate to download openldap, compile and
> install everything by hand to have the bug resolved in debian tomorrow,
> but I'd also hate having to wait with a bandaged network for weeks
> without knowing what's up.
>
> It's been 40 days since the bug was first reported and considered
> "grave", so some information from the maintainer would be nice to have.
Truth to say, I have no idea what's going on there. slapd is working
just fine on my machine, without it I wouldn't even be able to login...
On the other hand I don't use TLS with PAM and NSS so far so most of the
time TLS is not used.
If you could provide a core file that could prove useful to diagnose the
problem...
Greetings
Torsten
In Debian Bug tracker #244827, srd (sr-gimp) wrote : Coredump | #5 |
Hi,
Thanks for the reply. Sure, a coredump is no problem. Should I mail it
here or to you directly?
Here's a backtrace that I got from the core:
#0 0x4026c960 in gcry_mpi_get_opaque () from /usr/lib/
#1 0x4026ccef in gcry_mpi_copy () from /usr/lib/
#2 0x401f12dc in _gnutls_
#3 0x401f1172 in _gnutls_
#4 0x401e14c8 in _gnutls_
#5 0x401dc410 in _gnutls_
#6 0x401dba26 in gnutls_handshake () from /usr/lib/
#7 0x4004ba8a in gnutls_SSL_free () from /usr/lib/
#8 0x4004bc7a in gnutls_SSL_accept () from /usr/lib/
#9 0x00000001 in ?? ()
#10 0x40b8b3f8 in ?? ()
#11 0x40049823 in ldap_pvt_tls_accept () from /usr/lib/
#12 0x00000007 in ?? ()
#13 0x40b8b3e8 in ?? ()
#14 0x00000000 in ?? ()
#15 0x00000000 in ?? ()
#16 0x400536e0 in ?? () from /usr/lib/
#17 0x081726d0 in ?? ()
#18 0x00000012 in ?? ()
#19 0x4073e6d0 in ?? ()
#20 0x00000012 in ?? ()
#21 0x40b8b438 in ?? ()
#22 0x08057a6d in connection_read ()
Previous frame inner to this frame (corrupt stack?)
I don't know how libgcrypt and libgnutls interact regarding version
numbers, but this could be another symptom of the gnutls7 vs. gnutls10
problem thats' rearing it's head elsewhere in debian (e.g. cups a week
ago).
I'll install libgcrypt11 and see if the problems go away.
Regs,
Sven
--
Sven Riedel <email address hidden>
Liebigstr. 38
30163 Hannover "Python is merely Perl for those who
In Debian Bug tracker #244827, Torsten Landschoff (torsten) wrote : Re: Bug#244827: Coredump | #6 |
On Mon, May 31, 2004 at 08:20:18PM +0200, Sven Riedel wrote:
> Previous frame inner to this frame (corrupt stack?)
I hate that sort of bug. Really hard to debug :(
> I don't know how libgcrypt and libgnutls interact regarding version
> numbers, but this could be another symptom of the gnutls7 vs. gnutls10
> problem thats' rearing it's head elsewhere in debian (e.g. cups a week
> ago).
>
> I'll install libgcrypt11 and see if the problems go away.
Okay. I am curious about the result...
Greetings
Torsten
In Debian Bug tracker #244827, srd (sr-gimp) wrote : | #7 |
On Mon, May 31, 2004 at 10:47:55PM +0200, Torsten Landschoff wrote:
> On Mon, May 31, 2004 at 08:20:18PM +0200, Sven Riedel wrote:
> > I don't know how libgcrypt and libgnutls interact regarding version
> > numbers, but this could be another symptom of the gnutls7 vs. gnutls10
> > problem thats' rearing it's head elsewhere in debian (e.g. cups a week
> > ago).
> >
> > I'll install libgcrypt11 and see if the problems go away.
>
> Okay. I am curious about the result...
Unfortunately, not much better. I ln -s'ed /usr/lib/
libgcrypt.
died almost straight away. The Backtrace looks identical:
#0 0x4026c960 in gcry_mpi_get_opaque () from /usr/lib/
(no debugging symbols found)...(gdb) where
#0 0x4026c960 in gcry_mpi_get_opaque () from /usr/lib/
#1 0x4026ccef in gcry_mpi_copy () from /usr/lib/
#2 0x401f12dc in _gnutls_
#3 0x401f1172 in _gnutls_
#4 0x401e14c8 in _gnutls_
from /usr/lib/
#5 0x401dc410 in _gnutls_
#6 0x401dba26 in gnutls_handshake () from /usr/lib/
#7 0x4004ba8a in gnutls_SSL_free () from /usr/lib/
#8 0x4004bc7a in gnutls_SSL_accept () from /usr/lib/
#9 0x00000001 in ?? ()
#10 0x40b8b3f8 in ?? ()
#11 0x40049823 in ldap_pvt_tls_accept () from /usr/lib/
#12 0x00000007 in ?? ()
#13 0x40b8b3e8 in ?? ()
#14 0x00000000 in ?? ()
#15 0x00000000 in ?? ()
#16 0x400536e0 in ?? () from /usr/lib/
#17 0x081224b0 in ?? ()
#18 0x00000012 in ?? ()
#19 0x4073e6d0 in ?? ()
#20 0x00000012 in ?? ()
#21 0x40b8b438 in ?? ()
#22 0x08057a6d in connection_read ()
Regs,
Sven
In Debian Bug tracker #244827, srd (sr-gimp) wrote : No Problems with self-compiled slapd | #8 |
Hi,
I compiled slapd from openldap 2.2.13 on friday, and it's been running
stable ever since then. So the problem is either a bug in 2.1.30 or it's
a compile-time option. I used the following configure options:
./configure --with-gnu-ld --enable-bdb --enable-ldbm --enable-wrappers
-
All support-libraries needed came from debian sid.
As a general comment (no blame for this laid on Torsten): It would be
nice if debian got its act together with things ldap. Debain requires
libldap with nearly everything nowadays, but I've been having nothing
but grief with debians ldap packages (first libnss-ldap and libpam-ldap
and now slapd), and compiling each offender for myself always solved
the problem. Rant end.
Regs,
Sven
--
Sven Riedel <email address hidden>
Liebigstr. 38
30163 Hannover "Python is merely Perl for those who
In Debian Bug tracker #244827, Stephen Frost (sfrost) wrote : Re: [debian-openldap] Bug#244827: No Problems with self-compiled slapd | #9 |
* Sven Riedel (<email address hidden>) wrote:
> As a general comment (no blame for this laid on Torsten): It would be
> nice if debian got its act together with things ldap. Debain requires
> libldap with nearly everything nowadays, but I've been having nothing
> but grief with debians ldap packages (first libnss-ldap and libpam-ldap
> and now slapd), and compiling each offender for myself always solved
> the problem. Rant end.
Right, thanks for the next-to-useless rant. Perhaps you could elaborate
a bit on the problems you've had or point us to the bug reports you've
filed about these problems.
Stephen
In Debian Bug tracker #244827, Roland Bauerschmidt (roland-hbg-bremen) wrote : | #10 |
Sven Riedel wrote:
> I compiled slapd from openldap 2.2.13 on friday, and it's been running
> stable ever since then. So the problem is either a bug in 2.1.30 or it's
> a compile-time option. I used the following configure options:
Most likely, you compiled with OpenSSL rather than GNUTLS. Since the
problem seems to be GNUTLS related, you could probably also compile
2.1.30 with OpenSSL (which we can't though).
Roland
In Debian Bug tracker #244827, srd (sr-gimp) wrote : | #11 |
On Sun, Jun 27, 2004 at 02:11:03PM +0200, Roland Bauerschmidt wrote:
> Most likely, you compiled with OpenSSL rather than GNUTLS. Since the
> problem seems to be GNUTLS related, you could probably also compile
> 2.1.30 with OpenSSL (which we can't though).
Hm, true, I used OpenSSL instead of GnuTLS. Seems rather strange though,
since everything else that uses libgnutls10 on the system (kde, cups and
saslauthd) work without problems. The one thing that _is_ different is
that I have certificates from a private CA set up for use with LDAP,
which was generated with OpenSSL. Maybe the parsing of the certificates
triggers the bug in question...
Regs,
Sven
Debian Bug Importer (debzilla) wrote : | #12 |
Automatically imported from Debian bug report #244827
http://
Debian Bug Importer (debzilla) wrote : | #13 |
Message-ID: <email address hidden>
Date: Mon, 19 Apr 2004 23:41:45 -0600
From: Michael Berg <email address hidden>
To: "Debian Bug Tracking System" <email address hidden>
Subject: slapd 2.1.29 crashes
Package: slapd
Version: 2.1.29-2
Severity: grave
Justification: renders package unusable
Tags: sid
I upgraded to slapd 2.1.29 (and the corresponding libldap2) since it fixes
the TLS/SSL breakage of bug #234593 (which it does fix).
However, after upgrading, slapd 2.1.29 is crashing frequently on my system.
I'm using slapd with TLS/SSL support for user authentication. Crashing
slapd seems to be triggered fairly reliably when fetchmail retrieves
my mail and passes it to postfix for local delivery (which of course
contacts slapd to look up username and info).
Using a log level of 4095 (everything) in /etc/ldap/
obtain the syslog messages appended to the end of this email (trimmed
to what I *think* is the relevant parts -- if you need more than this,
just ask and I'll work on sanitizing usernames/schema from the rest
of it).
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.5
Locale: LANG=C, LC_CTYPE=C
Versions of packages slapd depends on:
ii coreutils [fileutils] 5.0.91-2 The GNU core utilities
ii debconf 1.4.22 Debian configuration management sy
ii fileutils 5.0.91-2 The GNU file management utilities
ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an
ii libdb4.2 4.2.52-16 Berkeley v4.2 Database Libraries [
ii libgcrypt7 1.1.90-1.1 LGPL Crypto library - runtime libr
ii libgnutls10 1.0.4-3 GNU TLS library - runtime library
ii libgpg-error0 0.7-1 library for common error values an
ii libiodbc2 3.51.2-2 iODBC Driver Manager
ii libldap2 2.1.29-2 OpenLDAP libraries
ii libltdl3 1.5.6-1 A system independent dlopen wrappe
ii libsasl2 2.1.18-4 Authentication abstraction library
ii libslp1 1.0.11-7 OpenSLP libraries
ii libtasn1-2 0.2.7-1 Manage ASN.1 structures (runtime)
ii libwrap0 7.6-ipv6.1-3 Wietse Venema's TCP wrappers libra
ii perl [libmime-
ii psmisc 21.4-1 Utilities that use the proc filesy
ii zlib1g 1:1.2.1-5 compression library - runtime
-- debconf information:
slapd/
* shared/
slapd/
slapd/backend: BDB
* slapd/allow_
slapd/
slapd/
slapd/
slapd/
slapd/
* slapd/domain: homenet
slapd/
slapd/
slapd/
slapd/
slapd/admin:
# Excerpt fro...
Debian Bug Importer (debzilla) wrote : | #14 |
Message-Id: <email address hidden>
Date: Thu, 29 Apr 2004 14:16:11 +0400
From: "Nikita V. Youshchenko" <email address hidden>
To: <email address hidden>
Subject: same happens here ...
Unfortunately, same happens here.
I had to upgrade slapd from testing to sid because of other bug (probably
fixed upstream), and now slapd crashes every several hours.
Quite bad.
Debian Bug Importer (debzilla) wrote : | #15 |
Message-Id: <email address hidden>
Date: Thu, 27 May 2004 20:27:43 +0200
From: Sven Riedel <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: Continued slapd breakage with 2.1.30-1
Package: slapd
Version: 2.1.30-1
Severity: normal
Followup-For: Bug #244827
I have a very similar configuration as Michael Berg (slapd for user
authentication with tls, postfix mta and fetchmail running
periodically), and the problem persists with version 2.1.30-1.
Regs,
Sven
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.6
Locale: LANG=C, LC_CTYPE=C
Versions of packages slapd depends on:
ii coreutils [fileutils] 5.0.91-2 The GNU core utilities
ii debconf 1.4.25 Debian configuration management sy
ii fileutils 5.0.91-2 The GNU file management utilities
ii libc6 2.3.2.ds1-12 GNU C Library: Shared libraries an
ii libdb4.2 4.2.52-16 Berkeley v4.2 Database Libraries [
ii libgcrypt7 1.1.90-1.1 LGPL Crypto library - runtime libr
ii libgnutls10 1.0.4-3 GNU TLS library - runtime library
ii libgpg-error0 0.7-1 library for common error values an
ii libiodbc2 3.51.2-2 iODBC Driver Manager
ii libldap2 2.1.30-1 OpenLDAP libraries
ii libltdl3 1.5.6-1 A system independent dlopen wrappe
ii libsasl2 2.1.18-4.1 Authentication abstraction library
ii libslp1 1.0.11-7 OpenSLP libraries
ii libtasn1-2 0.2.7-2 Manage ASN.1 structures (runtime)
ii libwrap0 7.6.dbs-4 Wietse Venema's TCP wrappers libra
ii perl [libmime-
ii psmisc 21.5-1 Utilities that use the proc filesy
ii zlib1g 1:1.2.1.1-3 compression library - runtime
-- debconf information excluded
Debian Bug Importer (debzilla) wrote : | #16 |
Message-ID: <20040530145234
Date: Sun, 30 May 2004 16:52:34 +0200
From: Sven Riedel <email address hidden>
To: <email address hidden>
Subject: Some feedback from maintainer?
Hi,
since the package maintainer hasn't said anything to this bugreport at all
(at least from what is viewable in the bug tracking system), I would
like him to just make a short statement as to the status of the bug
resolution.
Even something along the lines of "Can't reproduce, no clue
and no time right now" would be nice to have, since this bug is really
annoying and persistant. I'd hate to download openldap, compile and
install everything by hand to have the bug resolved in debian tomorrow,
but I'd also hate having to wait with a bandaged network for weeks
without knowing what's up.
It's been 40 days since the bug was first reported and considered
"grave", so some information from the maintainer would be nice to have.
Regs,
Sven
--
Sven Riedel <email address hidden>
Liebigstr. 38
30163 Hannover "Python is merely Perl for those who
Debian Bug Importer (debzilla) wrote : | #17 |
Message-ID: <email address hidden>
Date: Sun, 30 May 2004 18:11:04 +0200
From: Torsten Landschoff <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#244827: Some feedback from maintainer?
--r5Pyd7+fXNt84Ff3
Content-Type: text/plain; charset=us-ascii
Content-
Content-
Hi Sven,=20
On Sun, May 30, 2004 at 04:52:34PM +0200, Sven Riedel wrote:
=20
> Even something along the lines of "Can't reproduce, no clue
> and no time right now" would be nice to have, since this bug is really
> annoying and persistant. I'd hate to download openldap, compile and
> install everything by hand to have the bug resolved in debian tomorrow,
> but I'd also hate having to wait with a bandaged network for weeks
> without knowing what's up.
>=20
> It's been 40 days since the bug was first reported and considered
> "grave", so some information from the maintainer would be nice to have.
Truth to say, I have no idea what's going on there. slapd is working
just fine on my machine, without it I wouldn't even be able to login...
On the other hand I don't use TLS with PAM and NSS so far so most of the
time TLS is not used.=20
If you could provide a core file that could prove useful to diagnose the
problem...
Greetings
Torsten
--r5Pyd7+fXNt84Ff3
Content-Type: application/
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFAugeXdQg
tUPnr+rKN6sQHqT
=GTNf
-----END PGP SIGNATURE-----
--r5Pyd7+
Debian Bug Importer (debzilla) wrote : | #18 |
Message-ID: <20040531182018
Date: Mon, 31 May 2004 20:20:18 +0200
From: Sven Riedel <email address hidden>
To: <email address hidden>
Subject: Coredump
Hi,
Thanks for the reply. Sure, a coredump is no problem. Should I mail it
here or to you directly?
Here's a backtrace that I got from the core:
#0 0x4026c960 in gcry_mpi_get_opaque () from /usr/lib/
#1 0x4026ccef in gcry_mpi_copy () from /usr/lib/
#2 0x401f12dc in _gnutls_
#3 0x401f1172 in _gnutls_
#4 0x401e14c8 in _gnutls_
#5 0x401dc410 in _gnutls_
#6 0x401dba26 in gnutls_handshake () from /usr/lib/
#7 0x4004ba8a in gnutls_SSL_free () from /usr/lib/
#8 0x4004bc7a in gnutls_SSL_accept () from /usr/lib/
#9 0x00000001 in ?? ()
#10 0x40b8b3f8 in ?? ()
#11 0x40049823 in ldap_pvt_tls_accept () from /usr/lib/
#12 0x00000007 in ?? ()
#13 0x40b8b3e8 in ?? ()
#14 0x00000000 in ?? ()
#15 0x00000000 in ?? ()
#16 0x400536e0 in ?? () from /usr/lib/
#17 0x081726d0 in ?? ()
#18 0x00000012 in ?? ()
#19 0x4073e6d0 in ?? ()
#20 0x00000012 in ?? ()
#21 0x40b8b438 in ?? ()
#22 0x08057a6d in connection_read ()
Previous frame inner to this frame (corrupt stack?)
I don't know how libgcrypt and libgnutls interact regarding version
numbers, but this could be another symptom of the gnutls7 vs. gnutls10
problem thats' rearing it's head elsewhere in debian (e.g. cups a week
ago).
I'll install libgcrypt11 and see if the problems go away.
Regs,
Sven
--
Sven Riedel <email address hidden>
Liebigstr. 38
30163 Hannover "Python is merely Perl for those who
Debian Bug Importer (debzilla) wrote : | #19 |
Message-ID: <email address hidden>
Date: Mon, 31 May 2004 22:47:55 +0200
From: Torsten Landschoff <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#244827: Coredump
--rwEMma7ioTxnRzrJ
Content-Type: text/plain; charset=us-ascii
Content-
Content-
On Mon, May 31, 2004 at 08:20:18PM +0200, Sven Riedel wrote:
> Previous frame inner to this frame (corrupt stack?)
I hate that sort of bug. Really hard to debug :(
> I don't know how libgcrypt and libgnutls interact regarding version
> numbers, but this could be another symptom of the gnutls7 vs. gnutls10
> problem thats' rearing it's head elsewhere in debian (e.g. cups a week
> ago).
>=20
> I'll install libgcrypt11 and see if the problems go away.
Okay. I am curious about the result...
Greetings
Torsten
--rwEMma7ioTxnRzrJ
Content-Type: application/
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFAu5n7dQg
gbA46gvFSyCB/
=cEjw
-----END PGP SIGNATURE-----
--rwEMma7ioTxnR
Debian Bug Importer (debzilla) wrote : | #20 |
Message-ID: <email address hidden>
Date: Tue, 1 Jun 2004 02:55:48 -0700
From: Sven Riedel <email address hidden>
To: Torsten Landschoff <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#244827: Coredump
On Mon, May 31, 2004 at 10:47:55PM +0200, Torsten Landschoff wrote:
> On Mon, May 31, 2004 at 08:20:18PM +0200, Sven Riedel wrote:
> > I don't know how libgcrypt and libgnutls interact regarding version
> > numbers, but this could be another symptom of the gnutls7 vs. gnutls10
> > problem thats' rearing it's head elsewhere in debian (e.g. cups a week
> > ago).
> >
> > I'll install libgcrypt11 and see if the problems go away.
>
> Okay. I am curious about the result...
Unfortunately, not much better. I ln -s'ed /usr/lib/
libgcrypt.
died almost straight away. The Backtrace looks identical:
#0 0x4026c960 in gcry_mpi_get_opaque () from /usr/lib/
(no debugging symbols found)...(gdb) where
#0 0x4026c960 in gcry_mpi_get_opaque () from /usr/lib/
#1 0x4026ccef in gcry_mpi_copy () from /usr/lib/
#2 0x401f12dc in _gnutls_
#3 0x401f1172 in _gnutls_
#4 0x401e14c8 in _gnutls_
from /usr/lib/
#5 0x401dc410 in _gnutls_
#6 0x401dba26 in gnutls_handshake () from /usr/lib/
#7 0x4004ba8a in gnutls_SSL_free () from /usr/lib/
#8 0x4004bc7a in gnutls_SSL_accept () from /usr/lib/
#9 0x00000001 in ?? ()
#10 0x40b8b3f8 in ?? ()
#11 0x40049823 in ldap_pvt_tls_accept () from /usr/lib/
#12 0x00000007 in ?? ()
#13 0x40b8b3e8 in ?? ()
#14 0x00000000 in ?? ()
#15 0x00000000 in ?? ()
#16 0x400536e0 in ?? () from /usr/lib/
#17 0x081224b0 in ?? ()
#18 0x00000012 in ?? ()
#19 0x4073e6d0 in ?? ()
#20 0x00000012 in ?? ()
#21 0x40b8b438 in ?? ()
#22 0x08057a6d in connection_read ()
Regs,
Sven
Debian Bug Importer (debzilla) wrote : | #21 |
Message-ID: <20040621063758
Date: Mon, 21 Jun 2004 08:37:58 +0200
From: Sven Riedel <email address hidden>
To: <email address hidden>
Subject: No Problems with self-compiled slapd
Hi,
I compiled slapd from openldap 2.2.13 on friday, and it's been running
stable ever since then. So the problem is either a bug in 2.1.30 or it's
a compile-time option. I used the following configure options:
./configure --with-gnu-ld --enable-bdb --enable-ldbm --enable-wrappers
-
All support-libraries needed came from debian sid.
As a general comment (no blame for this laid on Torsten): It would be
nice if debian got its act together with things ldap. Debain requires
libldap with nearly everything nowadays, but I've been having nothing
but grief with debians ldap packages (first libnss-ldap and libpam-ldap
and now slapd), and compiling each offender for myself always solved
the problem. Rant end.
Regs,
Sven
--
Sven Riedel <email address hidden>
Liebigstr. 38
30163 Hannover "Python is merely Perl for those who
Debian Bug Importer (debzilla) wrote : | #22 |
Message-ID: <email address hidden>
Date: Mon, 21 Jun 2004 08:11:28 -0400
From: Stephen Frost <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: [debian-openldap] Bug#244827: No Problems with self-compiled slapd
--i3ZeZWfMixn4X/oG
Content-Type: text/plain; charset=us-ascii
Content-
Content-
* Sven Riedel (<email address hidden>) wrote:
> As a general comment (no blame for this laid on Torsten): It would be
> nice if debian got its act together with things ldap. Debain requires
> libldap with nearly everything nowadays, but I've been having nothing
> but grief with debians ldap packages (first libnss-ldap and libpam-ldap
> and now slapd), and compiling each offender for myself always solved=20
> the problem. Rant end.
Right, thanks for the next-to-useless rant. Perhaps you could elaborate
a bit on the problems you've had or point us to the bug reports you've
filed about these problems.
Stephen
--i3ZeZWfMixn4X/oG
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA1tBwrzg
ofs8nhi7ecfB76t
=3raJ
-----END PGP SIGNATURE-----
--i3ZeZWfMixn4X
Debian Bug Importer (debzilla) wrote : | #23 |
Message-ID: <email address hidden>
Date: Sun, 27 Jun 2004 14:11:03 +0200
From: Roland Bauerschmidt <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: [debian-openldap] Bug#244827: No Problems with self-compiled slapd
Sven Riedel wrote:
> I compiled slapd from openldap 2.2.13 on friday, and it's been running
> stable ever since then. So the problem is either a bug in 2.1.30 or it's
> a compile-time option. I used the following configure options:
Most likely, you compiled with OpenSSL rather than GNUTLS. Since the
problem seems to be GNUTLS related, you could probably also compile
2.1.30 with OpenSSL (which we can't though).
Roland
Debian Bug Importer (debzilla) wrote : | #24 |
Message-ID: <email address hidden>
Date: Sun, 27 Jun 2004 05:52:02 -0700
From: Sven Riedel <email address hidden>
To: Roland Bauerschmidt <email address hidden>
Cc: <email address hidden>
Subject: Re: [debian-openldap] Bug#244827: No Problems with self-compiled slapd
On Sun, Jun 27, 2004 at 02:11:03PM +0200, Roland Bauerschmidt wrote:
> Most likely, you compiled with OpenSSL rather than GNUTLS. Since the
> problem seems to be GNUTLS related, you could probably also compile
> 2.1.30 with OpenSSL (which we can't though).
Hm, true, I used OpenSSL instead of GnuTLS. Seems rather strange though,
since everything else that uses libgnutls10 on the system (kde, cups and
saslauthd) work without problems. The one thing that _is_ different is
that I have certificates from a private CA set up for use with LDAP,
which was generated with OpenSSL. Maybe the parsing of the certificates
triggers the bug in question...
Regs,
Sven
Matt Zimmerman (mdz) wrote : | #25 |
Remove myself from all these CCs now that we have the warty-bugs mailing list
Matt Zimmerman (mdz) wrote : | #26 |
Increase severity of RC bugs to major, now that we have other, non-RC bugs in
the list
In Debian Bug tracker #244827, Matthias Urlichs (smurf) wrote : My fault ;-) | #27 |
reassign 244827 libgcrypt7
thanks
I am the new maintainer of gcrypt* and gnutls*. This looks like it's now
my bug :-/ and I've reassigned it to libgcrypt7, as that's where it
crashes.
Please verify that this still happens with the latest versions from
Unstable (gnutls10 1.0.4-4; libgcrypt7 1.1.90-9).
If so: In gdb, please list the shared ibraries ("gdb> inf sha") which
are loaded and say "gdb> fr 0" so that I can see *where* in
gcry_mpi_get_opaque the bug is.
Thank you.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | <email address hidden>
Debian Bug Importer (debzilla) wrote : | #28 |
Message-ID: <20040716103700
Date: Fri, 16 Jul 2004 12:37:01 +0200
From: "Matthias Urlichs" <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: My fault ;-)
--hTiIB9CRvBOLTyqY
Content-Type: text/plain; charset=us-ascii
Content-
Content-
reassign 244827 libgcrypt7
thanks
I am the new maintainer of gcrypt* and gnutls*. This looks like it's now
my bug :-/ and I've reassigned it to libgcrypt7, as that's where it
crashes.
Please verify that this still happens with the latest versions from
Unstable (gnutls10 1.0.4-4; libgcrypt7 1.1.90-9).
If so: In gdb, please list the shared ibraries ("gdb> inf sha") which
are loaded and say "gdb> fr 0" so that I can see *where* in
gcry_mpi_get_opaque the bug is.
Thank you.
--=20
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | <email address hidden>
--hTiIB9CRvBOLTyqY
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA96/
nX8b0OWMWyC3S8V
=Gly/
-----END PGP SIGNATURE-----
--hTiIB9CRvBOLT
In Debian Bug tracker #244827, Modestas Vainius (geromanas) wrote : libgcrypt7: more info | #29 |
Package: libgcrypt7
Version: 1.1.90-9
Followup-For: Bug #244827
Hello,
The problem persists with libgcrypt7_1.1.90-9 and libgnutls10_
However, the bug is not in gcry_mpi_
gdb provides inaccurate backtrace when libgcrypt7 is compiled with -O2
That's what I got when I reproduced the problem with slapd, gnutls10 and
libgcrypt7 recompiled with DEB_BUILD_
(gdb) bt
#0 0x402a53f5 in _gcry_mpi_copy (a=0x8116a58) at mpiutil.c:229
#1 0x402a57d0 in gcry_mpi_copy (a=0x8116a58) at mpiutil.c:343
#2 0x401ffcb8 in _gnutls_
ret_p=0xbf7fc248, ret_g=0xbf7fc244) at gnutls_
#3 0x401ffb8f in proc_dhe_client_kx (session=0x814a480, data=0x814d818
"", _data_size=98) at auth_dhe.c:268
#4 0x401ebc37 in _gnutls_
gnutls_kx.c:329
#5 0x401e81c3 in _gnutls_
gnutls_
#6 0x401e6ca9 in gnutls_handshake (session=0x814a480) at
gnutls_
#7 0x400529a7 in SSL_do_handshake (ssl=0x8147598, end=GNUTLS_SERVER) at
gnutls.c:627
#8 0x40052acd in gnutls_SSL_accept (ssl=0x8147598) at gnutls.c:670
#9 0x40050394 in ldap_pvt_tls_accept (sb=0x814e230, ctx_arg=0x0) at
tls.c:928
#10 0x08058ff0 in connection_read ()
#11 0x080564ab in slapd_daemon_
#12 0x4032be51 in pthread_
#13 0x4032becf in pthread_
/lib/libpthread
#14 0x4046169a in clone () from /lib/libc.so.6
slapd segfaults, because:
(gdb) p a->d
$2 = (mpi_limb_t *) 0x10
The bug can be reproduced this way:
1) Start slapd ( slapd -d0 -h "ldap:/// ldaps:///" ). Be sure TLS is
enabled in slapd.conf
2) Run the script below concurrently in 4 (the number may vary) consoles
I=1; while ldapwhoami -ZZ -D "<your login DN>" -w "<password>" -x > /dev/null; do I=$[I+1]; done
3) Patience. Usually slapd crashes in 1-2 mins (on Pentium4
2.67ghz), however, sometimes it keeps running for 5-10 mins or even
more. If you were waiting for too long with no "success", restart slapd
and rerun the scripts. You may try increasing/
concurrent instances of the script too.
By the way, I was able to trigger the bug only with the script
concurrenly running in two or more consoles, so it seems that the bug
only occurs in a threaded environment.
"info sharedlibrary" says the following:
(gdb) info sharedlibrary
>From To Syms Read Shared Object Library
0x400280f0 0x40055920 Yes /usr/lib/
0x4005e5b0 0x40066df0 Yes /usr/lib/
0x40082530 0x4012c2a0 Yes /usr/lib/
0x40144a70 0x40174250 Yes /usr/lib/
0x40181320 0x40188090 Yes /usr/lib/
0x4018cf40 0x40194870 Yes /usr/lib/
0x40199540 0x401b0fd0 Yes /lib/libm.so.6
0x401bb180 0x401c98e0 Yes /usr/lib/
0x401dd530 0x4023a000 Yes /usr/lib/
0x4024d190 0x40258360 Yes /usr/lib/
0x4025f3b0 0x402abf60 Yes /usr/lib/
0x402bfc30 0x402cbac0 ...
Debian Bug Importer (debzilla) wrote : | #30 |
Message-Id: <email address hidden>
Date: Mon, 19 Jul 2004 16:06:16 +0300
From: Modestas Vainius <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: libgcrypt7: more info
Package: libgcrypt7
Version: 1.1.90-9
Followup-For: Bug #244827
Hello,
The problem persists with libgcrypt7_1.1.90-9 and libgnutls10_
However, the bug is not in gcry_mpi_
gdb provides inaccurate backtrace when libgcrypt7 is compiled with -O2
That's what I got when I reproduced the problem with slapd, gnutls10 and
libgcrypt7 recompiled with DEB_BUILD_
(gdb) bt
#0 0x402a53f5 in _gcry_mpi_copy (a=0x8116a58) at mpiutil.c:229
#1 0x402a57d0 in gcry_mpi_copy (a=0x8116a58) at mpiutil.c:343
#2 0x401ffcb8 in _gnutls_
ret_p=0xbf7fc248, ret_g=0xbf7fc244) at gnutls_
#3 0x401ffb8f in proc_dhe_client_kx (session=0x814a480, data=0x814d818
"", _data_size=98) at auth_dhe.c:268
#4 0x401ebc37 in _gnutls_
gnutls_kx.c:329
#5 0x401e81c3 in _gnutls_
gnutls_
#6 0x401e6ca9 in gnutls_handshake (session=0x814a480) at
gnutls_
#7 0x400529a7 in SSL_do_handshake (ssl=0x8147598, end=GNUTLS_SERVER) at
gnutls.c:627
#8 0x40052acd in gnutls_SSL_accept (ssl=0x8147598) at gnutls.c:670
#9 0x40050394 in ldap_pvt_tls_accept (sb=0x814e230, ctx_arg=0x0) at
tls.c:928
#10 0x08058ff0 in connection_read ()
#11 0x080564ab in slapd_daemon_
#12 0x4032be51 in pthread_
#13 0x4032becf in pthread_
/lib/libpthread
#14 0x4046169a in clone () from /lib/libc.so.6
slapd segfaults, because:
(gdb) p a->d
$2 = (mpi_limb_t *) 0x10
The bug can be reproduced this way:
1) Start slapd ( slapd -d0 -h "ldap:/// ldaps:///" ). Be sure TLS is
enabled in slapd.conf
2) Run the script below concurrently in 4 (the number may vary) consoles
I=1; while ldapwhoami -ZZ -D "<your login DN>" -w "<password>" -x > /dev/null; do I=$[I+1]; done
3) Patience. Usually slapd crashes in 1-2 mins (on Pentium4
2.67ghz), however, sometimes it keeps running for 5-10 mins or even
more. If you were waiting for too long with no "success", restart slapd
and rerun the scripts. You may try increasing/
concurrent instances of the script too.
By the way, I was able to trigger the bug only with the script
concurrenly running in two or more consoles, so it seems that the bug
only occurs in a threaded environment.
"info sharedlibrary" says the following:
(gdb) info sharedlibrary
>From To Syms Read Shared Object Library
0x400280f0 0x40055920 Yes /usr/lib/
0x4005e5b0 0x40066df0 Yes /usr/lib/
0x40082530 0x4012c2a0 Yes /usr/lib/
0x40144a70 0x40174250 Yes /usr/lib/
0x40181320 0x40188090 Yes /usr/lib/
0x4018cf40 0x40194870 Yes /usr/lib/
0x40199540 0x401b0fd0 Yes /lib/libm.so.6
0x401bb180 0x401c98e0 Yes /us...
In Debian Bug tracker #244827, Matthias Urlichs (smurf) wrote : Re: Bug#244827: libgcrypt7: more info | #31 |
Hi,
Modestas Vainius:
> The problem persists with libgcrypt7_1.1.90-9 and libgnutls10_
Thanks for the info.
> However, the bug is not in gcry_mpi_
Thought so...
> gdb provides inaccurate backtrace when libgcrypt7 is compiled with -O2
Not really -- gcc just suppresses symbol names which aren't externally
reachable, and gdb then uses the sybols it does see...
> (gdb) p a->d
> $2 = (mpi_limb_t *) 0x10
>
*Grumble* I hate bugs like these.
> 1) Start slapd ( slapd -d0 -h "ldap:/// ldaps:///" ). Be sure TLS is
> enabled in slapd.conf
>
Actually, /etc/default/slapd. ;-)
> By the way, I was able to trigger the bug only with the script
> concurrenly running in two or more consoles, so it seems that the bug
> only occurs in a threaded environment.
>
Looks like a nicely impossible-to-find memory corruption bug. Happiness.
Did you try to reproduce it under Electric Fence?
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | <email address hidden>
Debian Bug Importer (debzilla) wrote : | #32 |
Message-ID: <20040719153535
Date: Mon, 19 Jul 2004 17:35:36 +0200
From: "Matthias Urlichs" <email address hidden>
To: Modestas Vainius <email address hidden>, <email address hidden>
Subject: Re: Bug#244827: libgcrypt7: more info
--9l24NVCWtSuIVIod
Content-Type: text/plain; charset=us-ascii
Content-
Content-
Hi,
Modestas Vainius:
> The problem persists with libgcrypt7_1.1.90-9 and libgnutls10_
Thanks for the info.
> However, the bug is not in gcry_mpi_
Thought so...
> gdb provides inaccurate backtrace when libgcrypt7 is compiled with -O2
Not really -- gcc just suppresses symbol names which aren't externally
reachable, and gdb then uses the sybols it does see...
> (gdb) p a->d
> $2 =3D (mpi_limb_t *) 0x10
>=20
*Grumble* I hate bugs like these.
> 1) Start slapd ( slapd -d0 -h "ldap:/// ldaps:///" ). Be sure TLS is
> enabled in slapd.conf
>=20
Actually, /etc/default/slapd. ;-)
> By the way, I was able to trigger the bug only with the script
> concurrenly running in two or more consoles, so it seems that the bug
> only occurs in a threaded environment.
>=20
Looks like a nicely impossible-to-find memory corruption bug. Happiness.
Did you try to reproduce it under Electric Fence?
--=20
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | <email address hidden>
--9l24NVCWtSuIVIod
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA+
6CIZF3bMgnqoI+
=YHEg
-----END PGP SIGNATURE-----
--9l24NVCWtSuIV
In Debian Bug tracker #244827, Werner Koch (wk) wrote : | #33 |
On Mon, 19 Jul 2004 17:35:36 +0200, Matthias Urlichs said:
>> (gdb) p a->d
>> $2 = (mpi_limb_t *) 0x10
>>
> *Grumble* I hate bugs like these.
A glance at the ChangeLog doesn't reveal any interesting except for
* mpiutil.c (_gcry_
something even if NLIMBS is passed as 0.
I don't think it is the reason but I would give libgcrypt 1.2.0 a
short try, anyway
Werner
Debian Bug Importer (debzilla) wrote : | #34 |
Message-ID: <email address hidden>
Date: Mon, 19 Jul 2004 19:49:09 +0200
From: Werner Koch <email address hidden>
To: "Matthias Urlichs" <email address hidden>
Cc: <email address hidden>, Modestas Vainius <email address hidden>
Subject: Re: Bug#244827: libgcrypt7: more info
On Mon, 19 Jul 2004 17:35:36 +0200, Matthias Urlichs said:
>> (gdb) p a->d
>> $2 = (mpi_limb_t *) 0x10
>>
> *Grumble* I hate bugs like these.
A glance at the ChangeLog doesn't reveal any interesting except for
* mpiutil.c (_gcry_
something even if NLIMBS is passed as 0.
I don't think it is the reason but I would give libgcrypt 1.2.0 a
short try, anyway
Werner
In Debian Bug tracker #244827, Roland Bauerschmidt (bauerschmidt) wrote : | #35 |
On Mon, Jul 19, 2004 at 07:49:09PM +0200, Werner Koch wrote:
> A glance at the ChangeLog doesn't reveal any interesting except for
>
> * mpiutil.c (_gcry_
> something even if NLIMBS is passed as 0.
>
> I don't think it is the reason but I would give libgcrypt 1.2.0 a
> short try, anyway
Sven Riedel already has and I also just verified that the problem is
still present.
Thanks for your help though,
Roland
Debian Bug Importer (debzilla) wrote : | #36 |
Message-ID: <email address hidden>
Date: Tue, 20 Jul 2004 09:53:43 +0200
From: <email address hidden> (Roland Bauerschmidt)
To: Werner Koch <email address hidden>
Cc: Matthias Urlichs <email address hidden>, <email address hidden>,
Modestas Vainius <email address hidden>
Subject: Re: Bug#244827: libgcrypt7: more info
On Mon, Jul 19, 2004 at 07:49:09PM +0200, Werner Koch wrote:
> A glance at the ChangeLog doesn't reveal any interesting except for
>
> * mpiutil.c (_gcry_
> something even if NLIMBS is passed as 0.
>
> I don't think it is the reason but I would give libgcrypt 1.2.0 a
> short try, anyway
Sven Riedel already has and I also just verified that the problem is
still present.
Thanks for your help though,
Roland
In Debian Bug tracker #244827, Roland Bauerschmidt (bauerschmidt) wrote : | #37 |
On Mon, Jul 19, 2004 at 05:35:36PM +0200, Matthias Urlichs wrote:
> Looks like a nicely impossible-to-find memory corruption bug. Happiness.
> Did you try to reproduce it under Electric Fence?
I have just reproduced the bug under Electric Fence. The SEGV occurs
slightly earlier:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16386 (LWP 15079)]
0x402924fe in _gcry_mpi_copy (a=0x85cfbff6) at mpiutil.c:216
216 if( a && (a->flags & 4) ) {
(gdb) bt
#0 0x402924fe in _gcry_mpi_copy (a=0x85cfbff6) at mpiutil.c:216
#1 0x40292a48 in gcry_mpi_copy (a=0x85cfbff6) at mpiutil.c:343
#2 0x401fe3fc in _gnutls_
at gnutls_
#3 0x401fe292 in proc_dhe_client_kx (session=
_data_
#4 0x401ee548 in _gnutls_
#5 0x401e94c0 in _gnutls_
#6 0x401e8ad6 in gnutls_handshake (session=
#7 0x400569a7 in SSL_do_handshake (ssl=0x485d0fdc, end=GNUTLS_SERVER) at gnutls.c:627
#8 0x40056acd in gnutls_SSL_accept (ssl=0x485d0fdc) at gnutls.c:670
#9 0x40054394 in ldap_pvt_tls_accept (sb=0x6bc15fe4, ctx_arg=0x0) at tls.c:928
#10 0x08058ff0 in connection_read (s=32) at /root/tls/
#11 0x080564ab in slapd_daemon_task (ptr=0x0) at /root/tls/
#12 0x40312e51 in pthread_
#13 0x40312ecf in pthread_
#14 0x4044969a in clone () from /lib/libc.so.6
That a->d pointed to 0x10 in a previous post doesn't seem to be the
root of failure, but rather a consequence of this:
(gdb) f 0
#0 0x402924fe in _gcry_mpi_copy (a=0x85cfbff6) at mpiutil.c:216
216 if( a && (a->flags & 4) ) {
(gdb) p *a
Cannot access memory at address 0x85cfbff6
(gdb)
The variable 'a' is the same as cred->dh_params in #3:
(gdb) f 3
#3 0x401fe292 in proc_dhe_client_kx (session=
_data_
268 if ( (ret=_gnutls_
(gdb) p cred->dh_params
Cannot access memory at address 0x85cfbff6
(gdb)
Before, cred gets assigned the following:
auth_dhe.c:
cred = _gnutls_
const void *_gnutls_get_cred( GNUTLS_KEY key, gnutls_
const void *retval = NULL;
int _err = -1;
AUTH_CRED * ccred;
if (key == NULL) goto out;
ccred = key->cred;
if (ccred-
}
}
if (ccred==NULL) goto out;
_err = 0;
retval = ccred->credentials;
out:
if (err!=NULL) *err=_err;
return retval;
}
_gnutls_get_cred walks through the l...
In Debian Bug tracker #244827, Matthias Urlichs (smurf) wrote : | #38 |
Hi,
Roland Bauerschmidt:
> I have just reproduced the bug under Electric Fence. The SEGV occurs
> slightly earlier:
>
Yes -- still not terribly helpful however, we need to find out who
releases the memory.
Sometimes it occurs still earlier:
0x40200384 in _gnutls_
ret_
37 if (dh_primes == NULL || dh_primes->_prime == NULL ||
(gdb) whe
#0 0x40200384 in _gnutls_
ret_
#1 0x40200292 in proc_dhe_client_kx (session=
data=0x486baff8 '' <repeats 200 times>..., _data_size=
at auth_dhe.c:268
#2 0x401f0548 in _gnutls_
at gnutls_kx.c:329
#3 0x401eb4c0 in _gnutls_
at gnutls_
#4 0x401eaad6 in gnutls_handshake (session=
at gnutls_
#5 0x400599a7 in SSL_do_handshake (ssl=0x48572fdc, end=GNUTLS_SERVER)
at gnutls.c:627
#6 0x40059acd in gnutls_SSL_accept (ssl=0x48572fdc) at gnutls.c:670
> Consequently, session-
> *identical*. But they aren't (0x47210fb8 != 0x85cfbff6):
>
Umm...
> (gdb) p session-
> $53 = (void *) 0x47210fb8
> (gdb) p cred
> $54 = <value optimized out>
> (gdb) p *cred
> Cannot access memory at address 0x85cfbff6
... gdb actually uses the wrong value here (optimization!), especially since
session-
You might also try the helpful
(gdb) set env EF_FREE_WIPES 1
If you do that, you see
(gdb) p *((const CERTIFICATE_
$40 = {_prime = 0xbdbdbdbd, _generator = 0xbdbdbdbd}
=> something freed the dh_params vector.
I haven't found the culprit yet.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | <email address hidden>
In Debian Bug tracker #244827, Modestas Vainius (geromanas) wrote : | #39 |
Tuesday 20 July 2004 14:44, Matthias Urlichs rašė:
> Yes -- still not terribly helpful however, we need to find out who
> releases the memory.
This is what I discovered with valgrind:
==12898== Thread 2:
==12898== Invalid read of size 4
==12898== at 0x3C217C4B: _gnutls_
==12898== by 0x3C217B8E: proc_dhe_client_kx (auth_dhe.c:268)
==12898== by 0x3C203C36: _gnutls_
==12898== by 0x3C2001C2: _gnutls_
==12898== by 0x3C1FECA8: gnutls_handshake (gnutls_
==12898== by 0x3C0619A6: SSL_do_handshake (gnutls.c:627)
==12898== by 0x3C061ACC: gnutls_SSL_accept (gnutls.c:670)
==12898== by 0x3C05F393: ldap_pvt_tls_accept (tls.c:928)
==12898== by 0x8058FEF: connection_read (in /mnt/user/
==12898== by 0x80564AA: (within /mnt/user/
==12898== Address 0x3C510FE0 is 0 bytes inside a block of size 8 free'd
==12898== at 0x3C01F918: free (vg_replace_
==12898== by 0x3C2182C9: gnutls_
==12898== by 0x3C061AA2: SSL_do_handshake (gnutls.c:662)
==12898== by 0x3C061ACC: gnutls_SSL_accept (gnutls.c:670)
==12898== by 0x3C05F393: ldap_pvt_tls_accept (tls.c:928)
==12898== by 0x8058FEF: connection_read (in /mnt/user/
==12898== by 0x80564AA: (within /mnt/user/
==12898== by 0x3C34B110: thread_wrapper (vg_libpthread.
==12898== by 0xB800FACC: do__quit (vg_scheduler.
In Debian Bug tracker #244827, Roland Bauerschmidt (bauerschmidt) wrote : | #40 |
On Tue, Jul 20, 2004 at 01:44:46PM +0200, Matthias Urlichs wrote:
> => something freed the dh_params vector.
>
> I haven't found the culprit yet.
I think I might've found it (though not verified yet). In gnutls.c
(OpenLDAP code), SSL_do_handshake:
[...]
if (!ssl->session) {
[...]
[...]
[...]
[...]
[...]
}
[...]
if (rsa_params)
gnutls_
if (dh_params)
gnutls_
I'm afraid, the _params_deinit functions should only be called when the
session is closed. ldap_gnutls_
gnutls_
those functions only set a pointer...
Roland
In Debian Bug tracker #244827, Matthias Urlichs (smurf) wrote : OK, so it's slapd after all | #41 |
reassign 244827 slapd
thanks
Looks like it's not my problem after all ...
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | <email address hidden>
Debian Bug Importer (debzilla) wrote : | #42 |
Message-ID: <email address hidden>
Date: Tue, 20 Jul 2004 13:34:16 +0200
From: <email address hidden> (Roland Bauerschmidt)
To: Matthias Urlichs <email address hidden>
Cc: Modestas Vainius <email address hidden>, <email address hidden>
Subject: Re: Bug#244827: libgcrypt7: more info
On Mon, Jul 19, 2004 at 05:35:36PM +0200, Matthias Urlichs wrote:
> Looks like a nicely impossible-to-find memory corruption bug. Happiness.
> Did you try to reproduce it under Electric Fence?
I have just reproduced the bug under Electric Fence. The SEGV occurs
slightly earlier:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16386 (LWP 15079)]
0x402924fe in _gcry_mpi_copy (a=0x85cfbff6) at mpiutil.c:216
216 if( a && (a->flags & 4) ) {
(gdb) bt
#0 0x402924fe in _gcry_mpi_copy (a=0x85cfbff6) at mpiutil.c:216
#1 0x40292a48 in gcry_mpi_copy (a=0x85cfbff6) at mpiutil.c:343
#2 0x401fe3fc in _gnutls_
at gnutls_
#3 0x401fe292 in proc_dhe_client_kx (session=
_data_
#4 0x401ee548 in _gnutls_
#5 0x401e94c0 in _gnutls_
#6 0x401e8ad6 in gnutls_handshake (session=
#7 0x400569a7 in SSL_do_handshake (ssl=0x485d0fdc, end=GNUTLS_SERVER) at gnutls.c:627
#8 0x40056acd in gnutls_SSL_accept (ssl=0x485d0fdc) at gnutls.c:670
#9 0x40054394 in ldap_pvt_tls_accept (sb=0x6bc15fe4, ctx_arg=0x0) at tls.c:928
#10 0x08058ff0 in connection_read (s=32) at /root/tls/
#11 0x080564ab in slapd_daemon_task (ptr=0x0) at /root/tls/
#12 0x40312e51 in pthread_
#13 0x40312ecf in pthread_
#14 0x4044969a in clone () from /lib/libc.so.6
That a->d pointed to 0x10 in a previous post doesn't seem to be the
root of failure, but rather a consequence of this:
(gdb) f 0
#0 0x402924fe in _gcry_mpi_copy (a=0x85cfbff6) at mpiutil.c:216
216 if( a && (a->flags & 4) ) {
(gdb) p *a
Cannot access memory at address 0x85cfbff6
(gdb)
The variable 'a' is the same as cred->dh_params in #3:
(gdb) f 3
#3 0x401fe292 in proc_dhe_client_kx (session=
_data_
268 if ( (ret=_gnutls_
(gdb) p cred->dh_params
Cannot access memory at address 0x85cfbff6
(gdb)
Before, cred gets assigned the following:
auth_dhe.c:
cred = _gnutls_
const void *_gnutls_get_cred( GNUTLS_KEY key, gnutls_
const void *retval = NULL;
int _err = -1;
AUTH_CRED * ccred;
if (key == NULL) goto out;
ccred = key->cred;
if (ccred->a...
Debian Bug Importer (debzilla) wrote : | #43 |
Message-ID: <20040720114445
Date: Tue, 20 Jul 2004 13:44:46 +0200
From: "Matthias Urlichs" <email address hidden>
To: Roland Bauerschmidt <email address hidden>
Cc: Modestas Vainius <email address hidden>, <email address hidden>
Subject: Re: Bug#244827: libgcrypt7: more info
--+KJYzRxRHjYqLGl5
Content-Type: text/plain; charset=us-ascii
Content-
Content-
Hi,
Roland Bauerschmidt:
> I have just reproduced the bug under Electric Fence. The SEGV occurs
> slightly earlier:
>=20
Yes -- still not terribly helpful however, we need to find out who
releases the memory.
Sometimes it occurs still earlier:
0x40200384 in _gnutls_
c248,
ret_
37 if (dh_primes =3D=3D NULL || dh_primes->_prime =3D=3D NULL =
||
(gdb) whe
#0 0x40200384 in _gnutls_
ret_
#1 0x40200292 in proc_dhe_client_kx (session=
data=
at auth_dhe.c:268
#2 0x401f0548 in _gnutls_
at gnutls_kx.c:329
#3 0x401eb4c0 in _gnutls_
at gnutls_
#4 0x401eaad6 in gnutls_handshake (session=
at gnutls_
#5 0x400599a7 in SSL_do_handshake (ssl=3D0x48572fdc, end=3DGNUTLS_
at gnutls.c:627
#6 0x40059acd in gnutls_SSL_accept (ssl=3D0x48572fdc) at gnutls.c:670
> Consequently, session-
> *identical*. But they aren't (0x47210fb8 !=3D 0x85cfbff6):
>=20
Umm...
> (gdb) p session-
> $53 =3D (void *) 0x47210fb8
> (gdb) p cred
> $54 =3D <value optimized out>
> (gdb) p *cred
> Cannot access memory at address 0x85cfbff6
=2E.. gdb actually uses the wrong value here (optimization!), especially si=
nce
session-
You might also try the helpful
(gdb) set env EF_FREE_WIPES 1
If you do that, you see
(gdb) p *((const CERTIFICATE_
als)->dh_params
$40 =3D {_prime =3D 0xbdbdbdbd, _generator =3D 0xbdbdbdbd}
=3D> something freed the dh_params vector.
I haven't found the culprit yet.
--=20
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | <email address hidden>
--+KJYzRxRHjYqLGl5
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA/
ztll+BNIeVAHKgm
=TLQM
-----END PGP SIGNATURE-----
--+KJYzRxRHjYqL
In Debian Bug tracker #244827, Roland Bauerschmidt (bauerschmidt) wrote : Re: Bug#244827: Info received (was Bug#244827: libgcrypt7: more info) | #44 |
reassign 244827 slapd
thanks
Debian Bug Importer (debzilla) wrote : | #45 |
Message-Id: <email address hidden>
Date: Tue, 20 Jul 2004 15:15:33 +0300
From: Modestas Vainius <email address hidden>
To: "Matthias Urlichs" <email address hidden>
Cc: Roland Bauerschmidt <email address hidden>,
<email address hidden>
Subject: Re: Bug#244827: libgcrypt7: more info
--Boundary-
Content-Type: text/plain;
charset=
Content-
Content-
Tuesday 20 July 2004 14:44, Matthias Urlichs ra=F0=EB:
> Yes -- still not terribly helpful however, we need to find out who
> releases the memory.
This is what I discovered with valgrind:
=3D=3D12898=3D=3D Thread 2:
=3D=3D12898=3D=3D Invalid read of size 4
=3D=3D12898=3D=3D at 0x3C217C4B: _gnutls_
=2Ec:37)
=3D=3D12898=3D=3D by 0x3C217B8E: proc_dhe_client_kx (auth_dhe.c:268)
=3D=3D12898=3D=3D by 0x3C203C36: _gnutls_
kx.c:329)
=3D=3D12898=3D=3D by 0x3C2001C2: _gnutls_
ake.c:2241)
=3D=3D12898=3D=3D by 0x3C1FECA8: gnutls_handshake (gnutls_
92)
=3D=3D12898=3D=3D by 0x3C0619A6: SSL_do_handshake (gnutls.c:627)
=3D=3D12898=3D=3D by 0x3C061ACC: gnutls_SSL_accept (gnutls.c:670)
=3D=3D12898=3D=3D by 0x3C05F393: ldap_pvt_tls_accept (tls.c:928)
=3D=3D12898=3D=3D by 0x8058FEF: connection_read (in /mnt/user/
lapd)
=3D=3D12898=3D=3D by 0x80564AA: (within /mnt/user/
=3D=3D12898=3D=3D Address 0x3C510FE0 is 0 bytes inside a block of size 8 f=
ree'd
=3D=3D12898=3D=3D at 0x3C01F918: free (vg_replace_
=3D=3D12898=3D=3D by 0x3C2182C9: gnutls_
es.c:229)
=3D=3D12898=3D=3D by 0x3C061AA2: SSL_do_handshake (gnutls.c:662)
=3D=3D12898=3D=3D by 0x3C061ACC: gnutls_SSL_accept (gnutls.c:670)
=3D=3D12898=3D=3D by 0x3C05F393: ldap_pvt_tls_accept (tls.c:928)
=3D=3D12898=3D=3D by 0x8058FEF: connection_read (in /mnt/user/
lapd)
=3D=3D12898=3D=3D by 0x80564AA: (within /mnt/user/
=3D=3D12898=3D=3D by 0x3C34B110: thread_wrapper (vg_libpthread.
=3D=3D12898=3D=3D by 0xB800FACC: do__quit (vg_scheduler.
--Boundary-
Content-Type: application/
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQBA/
XLhwlkMjRPY9HrF
=IJL2
-----END PGP SIGNATURE-----
--Boundary-
Debian Bug Importer (debzilla) wrote : | #46 |
Message-ID: <email address hidden>
Date: Tue, 20 Jul 2004 14:20:15 +0200
From: <email address hidden> (Roland Bauerschmidt)
To: Matthias Urlichs <email address hidden>
Cc: Modestas Vainius <email address hidden>, <email address hidden>
Subject: Re: Bug#244827: libgcrypt7: more info
On Tue, Jul 20, 2004 at 01:44:46PM +0200, Matthias Urlichs wrote:
> => something freed the dh_params vector.
>
> I haven't found the culprit yet.
I think I might've found it (though not verified yet). In gnutls.c
(OpenLDAP code), SSL_do_handshake:
[...]
if (!ssl->session) {
[...]
[...]
[...]
[...]
[...]
}
[...]
if (rsa_params)
gnutls_
if (dh_params)
gnutls_
I'm afraid, the _params_deinit functions should only be called when the
session is closed. ldap_gnutls_
gnutls_
those functions only set a pointer...
Roland
Debian Bug Importer (debzilla) wrote : | #47 |
Message-ID: <20040720124113
Date: Tue, 20 Jul 2004 14:41:13 +0200
From: "Matthias Urlichs" <email address hidden>
To: <email address hidden>
Subject: OK, so it's slapd after all
--tVmo9FyGdCe4F4YN
Content-Type: text/plain; charset=us-ascii
Content-
Content-
reassign 244827 slapd
thanks
Looks like it's not my problem after all ...
--=20
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | <email address hidden>
--tVmo9FyGdCe4F4YN
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA/
1gRgvzQX/
=OW2G
-----END PGP SIGNATURE-----
--tVmo9FyGdCe4F
In Debian Bug tracker #244827, Roland Bauerschmidt (bauerschmidt) wrote : Fixed in SVN | #48 |
tags 244827 +pending
thanks
Fixed in SVN.
Debian Bug Importer (debzilla) wrote : | #49 |
Message-ID: <email address hidden>
Date: Tue, 20 Jul 2004 15:47:47 +0200
From: <email address hidden> (Roland Bauerschmidt)
To: <email address hidden>
Subject: Re: Bug#244827: Info received (was Bug#244827: libgcrypt7: more info)
reassign 244827 slapd
thanks
Debian Bug Importer (debzilla) wrote : | #50 |
Message-ID: <email address hidden>
Date: Tue, 20 Jul 2004 16:13:53 +0200
From: <email address hidden> (Roland Bauerschmidt)
To: <email address hidden>
Subject: Fixed in SVN
tags 244827 +pending
thanks
Fixed in SVN.
Matt Zimmerman (mdz) wrote : | #51 |
Matt Zimmerman (mdz) wrote : | #52 |
I don't have time for this tonight; Fabio, please take a look in the morning, it
should be straightforward to fix in Warty
Fabio Massimo Di Nitto (fabbione) wrote : | #53 |
Bug fixed for us with openldap2_
Fabio Massimo Di Nitto (fabbione) wrote : | #54 |
Fix in rev323 was not complete. backport from r326 and upload as
openldap2_
In Debian Bug tracker #244827, Roland Bauerschmidt (rb) wrote : Bug#244827: fixed in openldap2 2.1.30-3 | #55 |
Source: openldap2
Source-Version: 2.1.30-3
We believe that the bug you reported is fixed in the latest version of
openldap2, which is due to be installed in the Debian FTP archive:
ldap-utils_
to pool/main/
libldap2-
to pool/main/
libldap2_
to pool/main/
libslapd2-
to pool/main/
openldap2_
to pool/main/
openldap2_
to pool/main/
slapd_2.
to pool/main/
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Roland Bauerschmidt <email address hidden> (supplier of updated openldap2 package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Mon, 26 Jul 2004 18:41:23 +0200
Source: openldap2
Binary: libslapd2-dev slapd libldap2 ldap-utils libldap2-dev
Architecture: source i386 all
Version: 2.1.30-3
Distribution: unstable
Urgency: high
Maintainer: Torsten Landschoff <email address hidden>
Changed-By: Roland Bauerschmidt <email address hidden>
Description:
ldap-utils - OpenLDAP utilities
libldap2 - OpenLDAP libraries
libldap2-dev - OpenLDAP development libraries
libslapd2-dev - OpenLDAP slapd back-end development headers
slapd - OpenLDAP server (slapd)
Closes: 244827
Changes:
openldap2 (2.1.30-3) unstable; urgency=high
.
* Urgeny high since previous releases were hardly usable (at least
with TLS).
* Roland Bauerschmidt <email address hidden>
+ libraries/
rsa_params (this is also the way, it's done with OpenSSL). We need
GNUTLS 1.0.9 for this. With the new version of libgcrypt, we also
need to initialize threading explicitly. The previous
segmentation faults resulted from the *global* param structure
being recreated and freed for every session. Many thanks to
Matthias Urlichs who helped debugging a lot and also packaged
GNUTLS 1.0.16 very quickly... Closes: #244827.
+ debian/control: Add build dependency to libgcrypt11-dev (we're
initializing it directly now) and change libgnutls10-dev to
+ libraries/
(formerly ldap_gnutls_
doing unlink before opening and opening them with O_EXCL. This is
necessary because under Linux 2....
Debian Bug Importer (debzilla) wrote : | #56 |
Message-Id: <email address hidden>
Date: Tue, 27 Jul 2004 02:32:05 -0400
From: Roland Bauerschmidt <email address hidden>
To: <email address hidden>
Subject: Bug#244827: fixed in openldap2 2.1.30-3
Source: openldap2
Source-Version: 2.1.30-3
We believe that the bug you reported is fixed in the latest version of
openldap2, which is due to be installed in the Debian FTP archive:
ldap-utils_
to pool/main/
libldap2-
to pool/main/
libldap2_
to pool/main/
libslapd2-
to pool/main/
openldap2_
to pool/main/
openldap2_
to pool/main/
slapd_2.
to pool/main/
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Roland Bauerschmidt <email address hidden> (supplier of updated openldap2 package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Mon, 26 Jul 2004 18:41:23 +0200
Source: openldap2
Binary: libslapd2-dev slapd libldap2 ldap-utils libldap2-dev
Architecture: source i386 all
Version: 2.1.30-3
Distribution: unstable
Urgency: high
Maintainer: Torsten Landschoff <email address hidden>
Changed-By: Roland Bauerschmidt <email address hidden>
Description:
ldap-utils - OpenLDAP utilities
libldap2 - OpenLDAP libraries
libldap2-dev - OpenLDAP development libraries
libslapd2-dev - OpenLDAP slapd back-end development headers
slapd - OpenLDAP server (slapd)
Closes: 244827
Changes:
openldap2 (2.1.30-3) unstable; urgency=high
.
* Urgeny high since previous releases were hardly usable (at least
with TLS).
* Roland Bauerschmidt <email address hidden>
+ libraries/
rsa_params (this is also the way, it's done with OpenSSL). We need
GNUTLS 1.0.9 for this. With the new version of libgcrypt, we also
need to initialize threading explicitly. The previous
segmentation faults resulted from the *global* param structure
being recreated and freed for every session. Many thanks to
Matthias Urlichs who helped debugging a lot and also packaged
GNUTLS 1.0.16 very quickly... Closes: #244827.
+ debian/control: Add build dependency to libgcrypt11-dev (we're
initializing it directly now) and change libgnutls10-dev to
+ libraries/
Changed in openldap2.2: | |
status: | Unknown → Fix Released |
Unfortunately, same happens here.
I had to upgrade slapd from testing to sid because of other bug (probably
fixed upstream), and now slapd crashes every several hours.
Quite bad.