Bug#617759: icedove: symbol lookup error: /usr/lib/icedove/components/libdbusservice.so: undefined symbol: NS_Alloc

[Jonathan Nieder <jrnieder@gmail.com>]

tags 617759 - moreinfo
quit

Jonathan Nieder wrote:

>  $ icedove; echo $?
>  /usr/lib/icedove/icedove-bin: symbol lookup error: /usr/lib/icedove/components/libdbusservice.so: undefined symbol: NS_Alloc
>  127

I tried reproducing this with upstream glibc.  I'm way too lazy to
rebuild icedove in a sysroot, so that meant:

	git checkout 9f94d2ea
	cd ..
	mkdir glibc-build
	cd glibc-build
	../glibc/configure --prefix=$HOME/opt/glibc
	make install

In a root shell, kept open for safety:

	cd ~jrn/src/glibc-build
	cp -dp /lib/ld-linux-x86-64.so.2 ld-linux-x86-64.so.2.backup
	ln -sf $(pwd)/elf/ld.so /lib/ld-linux-x64-64.so.2

As an ordinary user:

	LD_LIBRARY_PATH=$HOME/opt/glibc:/usr/local/lib:/usr/lib:/lib
	export LD_LIBRARY_PATH
	icedove

Worked great --- icedove opened without trouble.  So probably either
the bug is caused by a Debian or eglibc patch, or it is related to
ld.so.cache.  Next step will be to try the patched source.

A less puzzling finding: LD_BIND_NOW avoids trouble, too.

The icedove source says

	/**
	 * Static helper routines to manage memory. These routines allow easy access
	 * to xpcom's built-in (global) nsIMemory implementation, without needing
	 * to go through the service manager to get it. However this requires clients
	 * to link with the xpcom DLL.
	 *
	 * This class is not threadsafe and is intented for use only on the main
	 * thread.
	 */

Maybe the warning is relevant?  But this does not feel like a race
(especially with a narrow window like that between the following "if"
and "return")

	if (!xpcomFunctions.allocFunc)
	    return nsnull;
	return xpcomFunctions.allocFunc(size);

since the result of running icedove is the same every time.