[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#223384: marked as done (libc6: Global constructors from shared objects are sometimes run in the wrong order)

Your message dated Mon, 14 Mar 2016 12:12:07 +0100
with message-id <20160314111206.GA2334@aurel32.net>
and subject line Bug#223384: libc7: Global constructors from shared objects are sometimes run in the wrong order
has caused the Debian Bug report #223384,
regarding libc6: Global constructors from shared objects are sometimes run in the wrong order
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
223384: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=223384
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: libc6
Version: 2.3.2.ds1-10
Severity: normal

Here's a greatly simplified test case of a problem I had today.

If you extract the attached tarball and type the following,

	cd ldtest
	export LD_LIBRARY_PATH=$PWD
	make
	./main
	
The output is as follows:

	creating libwvstreams.so
	creating libpthread.so
	creating libdb-4.0.so
	creating libwvutils.so
	starting

The output should be like this instead:

	creating libwvutils.so
	creating libwvstreams.so
	creating libpthread.so
	creating libdb-4.0.so
	starting

Or, at any rate, libwvutils.so should somehow be initialized before
libwvstreams.so, since libwvstreams.so depends on that library, and not the
other way around.  As you can see in the Makefile, there are no dependency
loops, so there's no reason to initialize the libraries in the wrong order.

Removing libdb entirely, or linking libpthread.so to main *before*
libwvstreams.so instead of after, eliminates the problem.

Note that, in my test case, all the libraries are actually empty except for
the global object whose constructor prints the above messages; there are no
symbol inter-references between the libraries.

This test case performs identically with glibc 2.3.2 in the current Red
Hat, so it's not a debian-specific bug.

Thanks,

Avery


-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux insight 2.4.19 #1 mer sep 4 10:52:04 EDT 2002 i686
Locale: LANG=fr_CA, LC_CTYPE=fr_CA

Versions of packages libc6 depends on:
ii  libdb1-compat                 2.1.3-7    The Berkeley database routines [gl

Attachment: ldtest.tar.gz
Description: Binary data


--- End Message ---
--- Begin Message --- 
Version: 2.13-38

On 2003-12-08 19:39, Avery Pennarun wrote:
> Package: libc6
> Version: 2.3.2.ds1-10
> Severity: normal
> 
> Here's a greatly simplified test case of a problem I had today.
> 
> If you extract the attached tarball and type the following,
> 
> 	cd ldtest
> 	export LD_LIBRARY_PATH=$PWD
> 	make
> 	./main
> 	
> The output is as follows:
> 
> 	creating libwvstreams.so
> 	creating libpthread.so
> 	creating libdb-4.0.so
> 	creating libwvutils.so
> 	starting
> 
> The output should be like this instead:
> 
> 	creating libwvutils.so
> 	creating libwvstreams.so
> 	creating libpthread.so
> 	creating libdb-4.0.so
> 	starting
> 
> Or, at any rate, libwvutils.so should somehow be initialized before
> libwvstreams.so, since libwvstreams.so depends on that library, and not the
> other way around.  As you can see in the Makefile, there are no dependency
> loops, so there's no reason to initialize the libraries in the wrong order.
> 
> Removing libdb entirely, or linking libpthread.so to main *before*
> libwvstreams.so instead of after, eliminates the problem.
> 
> Note that, in my test case, all the libraries are actually empty except for
> the global object whose constructor prints the above messages; there are no
> symbol inter-references between the libraries.
> 
> This test case performs identically with glibc 2.3.2 in the current Red
> Hat, so it's not a debian-specific bug.

This bug is reproducible in squeeze (2.11.3-4+deb6u11), but not in
wheezy (2.13-38+deb7u10), so I believe it has been fixed in between. I
am therefore closing the bug. Don't hesitate to reopen it if I am wrong.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

--- End Message ---
Reply to: