On Tue, Oct 13, 2009 at 2:15 AM, Michael Matz wrote:

Hi,

On Mon, 12 Oct 2009, Cristian Morales Vega wrote:

...

Looking to some .pc (pkg-config) files I though about this... -pthread can make sure that libpthread is linked in before libc, ok. But what happens if I compile a library with -pthread and then use it from a program that doesn't uses libpthread? Wouldn't in this case the library use the symbols from libc?

And this is exactly what happens sometimes.  A program is not thread-aware, loads some plugin which does use threads (and is linked against libpthread), et voila, you get a heap of interesting and hard to diagnose locking issues, usually resulting in dead locks of the program.

...

I though that this could be fixed if every library that uses libpthread adds -pthread to the CFlags in its .pc file (so the program will link against libpthread even if it doesn't uses it). But if I'm using --as-needed this would not work.

Right.  It usually works to have it only in some strategic libs because most programs aren't multi-threaded I guess.  See below.

...

You said: "Other things (gcc .spec files) make sure that libpthread is linked in _before_ libc when -pthread is given". But this doesn't solves the problem at runtime. There is also any special exception in ld.so so libpthread is always loaded before libc?

Nope.

...

Even if libpthread is only used by a library deep in the dependency tree and not in the main binary?

Now thinking about this, you seem to have a point.  A grave point even. If the application itself isn't linked to libpthread (but to libc, which all of them are) then libc will _always_ come before libpthread in symbol search order, for all further symbol lookups.  Even from dependency shared libs.  So in effect the thread-aware versions will never be used in that scenario.  I just verified this behaviour (lib against libpthread, app against lib but not libpthread, lib uses one of the double symbols, and voila, the ones from libc are picked up, not the ones from libpthread).  Uhoh.

Hmm.  I think we're screwed.  Applications itself, when there's even a slightest chance of some of its libraries using threads plus the problematic libc functions, must be linked against libpthread; without --as-needed getting rid of it.  It's not enough if some core toolkit library links against libpthread, it must be the top-level app.

I guess we're not seeing much more of these problems, because if threads are used at all, then probably not the problematic libc functions, or if then not in contexts where it matters.  A bit fragile to rely upon this, as it's non-trivial to define the problematic set.  It's not as easy as those symbols which are exported by libc as well as by libpthread.  E.g. __open and __open64 in both libraries do the same thing.  But e.g. flockfile is indeed a noop in libc, and does locking in libpthread.

BTW, exists almost an implementation, called "yarn lock", that permit more portability between platform and pthread implementation. Some product, that aim at more cross-platform that was in the past, already use it http://www.mail-archive.com/rpm-cvs@rpm5.org/msg04187.html Regards

Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

...

...

On 10/14/2009 at 8:11, Michael Matz wrote: Now that so many of the functions turn out to do the same thing perhaps it would be worthwhile if somebody looked at each of the common ones to determine where real differences are left to explain the dead-locks we see occasionally. Perhaps we can get rid of them by some small extensions in glibc.

Sorry to hijack this thread (a little.. it's snot entirely offtopic, but I admit I do not understand half of what you guys say :) ). I've seen some dead-locks in simple-ccsm (a python app, with a native lib, libcompizconfig linked). Especially on slower notebooks I have trouble loading the app (sometimes it works, most of the time it fails). On the fast system I never experienced an issue with it. Could this be a consequence of such an issue as stated in this thread? Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Hi, On Thu, 15 Oct 2009, Cristian Morales Vega wrote:

...

Now that so many of the functions turn out to do the same thing perhaps it would be worthwhile if somebody looked at each of the common ones to determine where real differences are left to explain the dead-locks we see occasionally.  Perhaps we can get rid of them by some small extensions in glibc.

I have unpacked glibc sources and... I'm scared :-p (being unable to easily install kscope because of some stupid dependency issues doesn't help).

You don't want to look at the glibc sources to initially determine this. It's non-trivial to determine which source files are actually compiled into glibc depending on the configuration, and which headers are actually used to define some of the macros used in sources (that can expand to different things, again depending on configuration). For differences I looked at the dis-assembly of the functions in question. The list of double symbols that possibly matter is below. Some of the symbols are just aliases to each other. And after looking at the asm differences (or non-differences) I referred back to the sources to see if that made sense.

So, if no one here has time and capacity to look into this probably the best thing to do would be to raise the problem upstream. Should I? I heard scary stories about Drepper ;-)

You don't want to raise this with Drepper in this state. What do you want to ask him? "Hey, sometimes we see dead-locks, libpthread loaded later, but most functions do the same in both libs, do you know what's the cause?". He'll just laugh at you. Ciao, Michael.

2009/10/16 Michael Matz :

Hi,

On Thu, 15 Oct 2009, Cristian Morales Vega wrote:

...

...

Now that so many of the functions turn out to do the same thing perhaps it would be worthwhile if somebody looked at each of the common ones to determine where real differences are left to explain the dead-locks we see occasionally.  Perhaps we can get rid of them by some small extensions in glibc.

I have unpacked glibc sources and... I'm scared :-p (being unable to easily install kscope because of some stupid dependency issues doesn't help).

You don't want to look at the glibc sources to initially determine this. It's non-trivial to determine which source files are actually compiled into glibc depending on the configuration, and which headers are actually used to define some of the macros used in sources (that can expand to different things, again depending on configuration).  For differences I looked at the dis-assembly of the functions in question.  The list of double symbols that possibly matter is below.  Some of the symbols are just aliases to each other.  And after looking at the asm differences (or non-differences) I referred back to the sources to see if that made sense.

Sorry, my assembly knowledge is near zero. I even tried looking at open(), but I would have said libc and libpthread implementations are different... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org