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