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

[Ian Goldberg]

On Tue, Feb 20, 2007 at 06:10:18AM -0500, Ian Goldberg wrote:
> 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.

Has this been resolved in the debian package?  The upstream source has a
"Makefile.static" that statically links libgcrypt into pidgin-otr.so.

[D'oh.  The version of Makefile.static in the 3.2.0 release forgot to
link in the new tooltipmenu.o file.  It's fixed in cvs.]

   - Ian