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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
