diff options
Diffstat (limited to 'open_issues/libpthread_dlopen.mdwn')
| -rw-r--r-- | open_issues/libpthread_dlopen.mdwn | 104 |
1 files changed, 103 insertions, 1 deletions
diff --git a/open_issues/libpthread_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn index 3c36eb26..a825fdff 100644 --- a/open_issues/libpthread_dlopen.mdwn +++ b/open_issues/libpthread_dlopen.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011, 2012, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2011, 2012, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -125,6 +125,108 @@ IRC, freenode, #hurd, 2011-08-17 <pinotree> and yes, it's known already, just nobody worked on solving it +# IRC, freenode, #hurd, 2014-01-28 + + <gnu_srs> braunr: Is this fixed by your recent patches? test_dbi: + ./pthread/../sysdeps/generic/pt-mutex-timedlock.c:70: + <gnu_srs> __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' + failed. + <youpi> faq/libpthread_dlopen.mdwn: + ./pthread/../sysdeps/generic/pt-mutex-timedlock.c:70: + __pthread_mutex_time + <gnu_srs> youpi: tks. A workaround seems to be available: + LD_PRELOAD=/lib/i386-gnu/libpthread.so.0.3 + <gnu_srs> Is that possible on a buildd? + <youpi> it would be simpler to just make the package explicitly link + libpthread + <gnu_srs> Package is libdbi-drivers, providing libdbd-sqlite3 needed by + gnucash + + +# IRC, freenode, #hurd, 2014-02-17 + + <braunr> hm ok, looks like iceweasel errors all have something to do with + the libc dns resolver + <braunr> http://darnassus.sceen.net/~rbraun/iceweasel_crash + <braunr> apparently, it's simply because the memory chunk isn't page + aligned .. + <braunr> looks like not preloading libpthread tirggers lots of tricky + issues + <braunr> 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 + <congzhang> debian linux does not have the pthread load problem. + <braunr> congzhang: it had it + <braunr> maybe not debian but i've found one such report for opensuse + + <braunr> ok the bug is simple + <braunr> for some reason, our glibc still uses a global _res state for dns + resolution instead of per thread ones + <braunr> uh, apparently, it's libpthread's job to define a __res_state + function for that :( + +## IRC, freenode, #hurd, 2014-02-18 + + <braunr> usually when i say it, it crashes soon after, so let's try it : + <braunr> i've been running iceweasel 27 fine for like 10 minutes with a + patched libpthread + <braunr> still no crash ;p + <braunr> with luck this extremely lightweight patch will fix all + multithreaded applications doing concurrent name resolution .... :) + <teythoon> nice :) + <braunr> let's try gnash .... + <braunr> uh, segfault on termination + <braunr> gnash works :) + <teythoon> sweet :) + <braunr> i'm very surprised we could live so long with that resolv bug + + +## IRC, freenode, #hurd, 2014-02-19 + + <braunr> youpi: the eglibc bug is about libresolv + <braunr> it uses a global resolver state even in multithreaded applications + <youpi> libresolv is a horrible part of glibc :) + <braunr> which is obviously bad + <braunr> yes .. :) + <braunr> here is the patch : + http://darnassus.sceen.net/~rbraun/0001-libpthread-per-thread-resolver-states.patch + <braunr> 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 + <braunr> should we make that hurd-specific ? + <braunr> or enclose that assignment with #ifdef ENABLE_TLS ? + <youpi> well, ENABLE_TLS is now always 1, iirc :) + <braunr> for the hurd, yes + <youpi> I'm surprised linux never had the issue + <youpi> no, not for the hurd + <braunr> ah + <youpi> I *had* to implement TLS for hurd because it was always 1 for + everybody :) + <braunr> ok + <braunr> so all those ifdefs could be removed and libpthread can assume tls + is enabled + <braunr> in which case my patch looks fine + <youpi> ah, thats a libpthread patch, not glibc patch + <braunr> yes + <braunr> nptl obviously did that from the start . :) + <braunr> linuxthreads had the problem a looong time ago + <youpi> ok + <braunr> i'm surprised we overlooked it for so long + <braunr> but anyway, that's a good fix + <youpi> indeed + <youpi> it seems all good to me + <braunr> well, __resp is a __thread variable + <braunr> i could add #ifdef ENABLE_TLS, but then what of the case where TLS + isn't enabled, and do we actually care ? + <braunr> #error maybe ? + <braunr> or #warning ? + <youpi> I don't think we care about the non-TLS case any more + <braunr> ok + <braunr> topgit branch i suppose ? + <youpi> well, not, hurd libpthread repo :) + <braunr> oh right ... :) + + # libthreads vs. libpthread The same symptom appears in an odd case, for instance: |