Is there a clear description of exactly the problem solved by the patch?
This looks like a serious problem that we need to fix, but I have not
seen a clear "What problem are your solving?" kind of description of the
problem and how the fix relates.
It appears that the patch does:
* In _dl_close_w
(In reply to comment #6)
> + /* We can't remove the l_initfini memory because
> +it's shared with l_searchlist.r_list. We don't clear
> +the latter so when we dlopen this object again that
> +entry would point to stale memory. And we don
Reproduced with 2.15 head and trunk.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/893605
Title:
crashes with glibc-2.14/2.15 on dlopen (seen with kvm and gnucash)
To manage notifications about thi
*** Bug 12871 has been marked as a duplicate of this bug. ***
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/893605
Title:
crashes with glibc-2.14/2.15 on dlopen (seen with kvm and gnucash)
To manag
We want this fix in 2.16, setting milestone.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/929219
Title:
chromium-browser, gvfsd-http and others using eglibc crash with
SIGSEGV in __nscd_get_mappi
This is now fixed for 2.16 by my commit 0479b305c5b7c8e3fa8e3002982cf8cac02b842e
Fix invalid memory access in do_lookup_x.
[BZ #13579] Do not free l_initfini and allow it to be reused
on subsequent dl_open calls for the same library. This fixes
the invalid memory access in do_lookup_x when th
(In reply to comment #13)
> Any update on this issue?
> What is holding the obvious patch from Andreas back?
Sorry, I've been holding up the obvious patch with a lengthy review.
I've filed BZ#14274 for the actual cleanup.
At this point in the code freeze it is too risky to make the larger
chang
