[[!meta copyright="Copyright © 2011, 2012, 2013, 2014, 2015 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] [[!tag open_issue_libpthread]] [[!toc]] # [[FAQ entry|faq/libpthread_dlopen]] Some applications don't themselves link against libpthread, but then load plugins which do link against libpthread. This means internally switching from single-threading to multi-threading, which is only supported since libc0.3 2.19-16~2. Previously, it would result in errors such as: ./pthread/../sysdeps/generic/pt-mutex-timedlock.c:70: __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' failed. *This is now fixed as of libc0.3 2.19-16~2.* # IRC, freenode, #hurd, 2010-01-24 youpi: hm, thought about the pthread/stubs issue w/ dlopen'ed libraries currently looks like libstdc++ on hurd links to pthread-stubs, we're the only one with such configuration i was looking at the gcc 4.4 patch hurd-pthread.diff, could it be it does not set THREADLIBS in the configure.ac switch case? that's expected on linux the libc provides hooks itself, on hurd-i386 it's pthread-stubs why not explicitly link to pthread though? because there is no strict need to, for applications that don't need libpthread the dlopen case is a tricky case that pthread-stubs had not thought about hm what if the pthread stubs would be moved in our glibc? that's what we should do yes (ideally) but for this we need to build libpthread along glibc, to get it really working [[Packaging_libpthread]]. and that's the tricky part (Makefile & such) which hasn't been done yet why both (stubs + actual libpthread)? because you need the stubs to be able to call the actual libpthread as soon libpthread gets dlopened for instance +as i see (remember that nptl does this if you want to see how) (it's the libc files in nptl/) (and forward.c) also if libpthreads gets integrated with glibc don't we need to switch the hurd from cthreads then? Which has been the blocker all this time AFAIR? we don't _need_ to ok # IRC, OFTC, #debian-hurd, 2011-07-21 there's one known issue with pthreads you can't dlopen() it ... if the main application is not already linked against it. which also means you can't dlopen() a module which depends on it if the main application hasn't used -lpthread already (so as to get libpthread initialized early, not at the dlopen() call) I get this while building simgrid: cd /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console && /usr/bin/cmake -E create_symlink /home/lucas/simgrid-3.6.1/obj-i486-gnu/lib/libsimgrid.so /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console/simgrid.so cd /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console && lua /home/lucas/simgrid-3.6.1/examples/gras/console/ping_generator.lua lua: /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libpthread/sysdeps/generic/pt-mutex-timedlock.c:68: __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' failed. Aborted (core dumped) that's it, yes (or at least it has the same symptoms) it would need fixing in lua, not in SG, then, right? yes ok, thanks The fix thus being: link the main application with -lpthread. IRC, freenode, #hurd, 2011-08-17 < youpi> i.e. openjade apparently dlopen()s modules which use pthreads, but openjade itself is not liked against libpthread < youpi> which means unexpectedly loading pthreads on the fly, which is not implemented < youpi> (and hard to implement of course) < youpi> gnu_srs: so simply tell openjade people to link it with -lpthread < gnu_srs> Shuoldn't missing linking with pthread create an error when building openjade then? < youpi> no < youpi> because it's just a module which needs pthread < youpi> and that module _is_ linked with -lpthread < youpi> and dlopen() loads libpthreads too due to that < youpi> but that's unexpected, for the libpthread initialization stuff < youpi> (and too late to fix initlaization) < gnu_srs> How come that other OSes build opensp w/o problems? < youpi> because there are stubs in the libc < gnu_srs> Sorry for the delay: What hinders stubs to be present also in the Hurd libc parts too, to cope with this problem? < youpi> doing it < youpi> which is hard because you need libpthread bits inside the libc < youpi> making it simpler would need building libpthread at the same time as libc [[packaging_libpthread]] # IRC, freenode, #hurd, 2013-09-03 iceweasel: ./pthread/../sysdeps/generic/pt-mutex-timedlock.c:70: __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' failed. LD_PRELOAD libpthread why missing link to pthread? and yes, it's known already, just nobody worked on solving it # IRC, freenode, #hurd, 2014-01-28 braunr: Is this fixed by your recent patches? test_dbi: ./pthread/../sysdeps/generic/pt-mutex-timedlock.c:70: __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' failed. faq/libpthread_dlopen.mdwn: ./pthread/../sysdeps/generic/pt-mutex-timedlock.c:70: __pthread_mutex_time youpi: tks. A workaround seems to be available: LD_PRELOAD=/lib/i386-gnu/libpthread.so.0.3 Is that possible on a buildd? it would be simpler to just make the package explicitly link libpthread Package is libdbi-drivers, providing libdbd-sqlite3 needed by gnucash # IRC, freenode, #hurd, 2014-02-17 hm ok, looks like iceweasel errors all have something to do with the libc dns resolver http://darnassus.sceen.net/~rbraun/iceweasel_crash apparently, it's simply because the memory chunk isn't page aligned .. looks like not preloading libpthread tirggers lots of tricky issues anyway, apparently, the malloc/free calls in libresolv don't use locks if libpthread isn't preloaded, which explains why the program state looked impossible to reach and why crashes look random debian linux does not have the pthread load problem. congzhang: it had it maybe not debian but i've found one such report for opensuse ok the bug is simple for some reason, our glibc still uses a global _res state for dns resolution instead of per thread ones uh, apparently, it's libpthread's job to define a __res_state function for that :( ## IRC, freenode, #hurd, 2014-02-18 usually when i say it, it crashes soon after, so let's try it : i've been running iceweasel 27 fine for like 10 minutes with a patched libpthread still no crash ;p with luck this extremely lightweight patch will fix all multithreaded applications doing concurrent name resolution .... :) nice :) let's try gnash .... uh, segfault on termination gnash works :) sweet :) i'm very surprised we could live so long with that resolv bug ## IRC, freenode, #hurd, 2014-02-19 youpi: the eglibc bug is about libresolv it uses a global resolver state even in multithreaded applications libresolv is a horrible part of glibc :) which is obviously bad yes .. :) here is the patch : http://darnassus.sceen.net/~rbraun/0001-libpthread-per-thread-resolver-states.patch it's very short, it basically allocates a resolver state per thread in the pthread struct, and sets the TLS variable __resp when the thread starts should we make that hurd-specific ? or enclose that assignment with #ifdef ENABLE_TLS ? well, ENABLE_TLS is now always 1, iirc :) for the hurd, yes I'm surprised linux never had the issue no, not for the hurd ah I *had* to implement TLS for hurd because it was always 1 for everybody :) ok so all those ifdefs could be removed and libpthread can assume tls is enabled in which case my patch looks fine ah, thats a libpthread patch, not glibc patch yes nptl obviously did that from the start . :) linuxthreads had the problem a looong time ago ok i'm surprised we overlooked it for so long but anyway, that's a good fix indeed it seems all good to me well, __resp is a __thread variable i could add #ifdef ENABLE_TLS, but then what of the case where TLS isn't enabled, and do we actually care ? #error maybe ? or #warning ? I don't think we care about the non-TLS case any more ok topgit branch i suppose ? well, not, hurd libpthread repo :) oh right ... :) # libthreads vs. libpthread The same symptom appears in an odd case, for instance: buildd@hurd:~$ ldd /usr/bin/openjade libthreads.so.0.3 => /lib/libthreads.so.0.3 (0x0103d000) libosp.so.5 => /usr/lib/libosp.so.5 (0x01044000) libpthread.so.0.3 => /lib/libpthread.so.0.3 (0x01221000) libnsl.so.1 => /lib/i386-gnu/libnsl.so.1 (0x01232000) [...] openjade links against *both* libthreads and libpthread. The result is that libc early-initializes libthreads only, and thus libpthread is not early-initialized, and later on raises assertions. The solution is to just get rid of libthreads, to have only one threading library.