[OTR-dev] Re: Bug#411301: gaim DNS children die when gaim-otr is installed

Ian Goldberg ian at cypherpunks.ca
Tue Feb 20 06:10:18 EST 2007


On Mon, Feb 19, 2007 at 08:34:21PM -0700, Berg, Michael wrote:
> 
> Steve Langasek wrote:
> > Well, this problem indeed doesn't seem to be reproducible on i386 or amd64
> > when not using nss_ldap.  Given that users of other gnutls- or gcrypt-using
> > packages aren't reporting similar problems, it seems likely that this is a
> > bug in gaim-otr or libotr, but I don't think it's one that should block the
> > package from being released; it is generally usable, just not in certain
> > system configurations.
> 
> Yeah, I do have a system configuration that you don't run across every day ;-)
> 
> 
> Ian Goldberg wrote:
> > Is it reproducible on other systems that *do* use nss_ldap?  Can you
> > turn nss_ldsp on on one of those other systems you tested, and try
> > again?
> 
> I did a clean install of Debian unstable onto a x86 (32-bit) laptop, tested
> gaim with and without gaim-otr installed.  gaim and gaim+otr both worked
> properly.
> 
> Then I installed libnss-ldap and libpam-ldap and configured them for my
> network setup.  gaim (without otr) worked, but gaim+otr had the same errors
> as I reported for my amd64 system (and the 32-bit chroot I also tested
> there).  So I can duplicate the bug when nss_ldap is in use.
> 
> Valgrind output is attached for the following 4 test cases:
> 1) gaim (without otr or nss_ldap): gaim.9110.gz
> 2) gaim+otr (without nss_ldap):    gaim+otr.9180.gz
> 3) gaim with nss_ldap in use:      gaim+ldap.10134.gz
> 4) gaim+otr with nss_ldap in use:  gaim+otr+ldap.10038.gz
> 
> Unfortunately, all of these valgrind runs on that x86 laptop have a TON of
> =====
> Conditional jump or move depends on uninitialised value(s)
>   at 0x5C55DC7: (within /usr/lib/libsoftokn3.so.0d)
>   by 0x5C5617D: (within /usr/lib/libsoftokn3.so.0d)
>   by 0x5C56243: (within /usr/lib/libsoftokn3.so.0d)
>   by 0x5C56471: (within /usr/lib/libsoftokn3.so.0d)
>   by 0x5C566D8: (within /usr/lib/libsoftokn3.so.0d)
>   by 0x5C445C4: (within /usr/lib/libsoftokn3.so.0d)
>   by 0x5C44721: (within /usr/lib/libsoftokn3.so.0d)
>   by 0x5B9B7C2: (within /usr/lib/libnss3.so.0d)
>   by 0x5B9B8C2: (within /usr/lib/libnss3.so.0d)
>   by 0x5BA4133: SECMOD_LoadModule (in /usr/lib/libnss3.so.0d)
>   by 0x5BA428A: SECMOD_LoadModule (in /usr/lib/libnss3.so.0d)
>   by 0x5B8342D: (within /usr/lib/libnss3.so.0d)
> =====
> that occur in each capture.
> I didn't see these on the amd64 system or the x86 chroot I set up on that
> system.  Do you guys get pages and pages of that output when you run
> valgrind on gaim on a 32-bit x86 system?  If not, I'll try to figure out
> what's causing it on that freshly installed laptop.

OK, I think I see the problem.  libldap_r.so.2.0.130 and gaim-otr both
use libgcrypt.  libgcrypt has a well-known problem that it can't be
used as a shared library by more than one client in the same program.
This is because it uses global variables that the two clients (gaim-otr
and libldap) both need to use in different ways.  We also see this
problem, for example, if you try to use gaim-otr and another encrypting
plugin that uses libgcrypt.

One solution would be to statically link libgcrypt into gaim-otr (so it
gets its own copies of global data).  Can one of the Debian people try
to build a package like that?

A better solution, of course, would be to make libgcrypt
sharing-friendly.  This had been discussed on libgcrypt's mailing list
a while back, but I don't know what, if anything, became of it.

Thanks,

   - Ian



More information about the OTR-dev mailing list