[Bug 893605]
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_worker we don't swap back the old l_orig_initfini maps (is this what was causing the access to dangling memory?) we made at startup, and we don't free the current l_initfini maps we were using (they will get freed elsewhere). * In _dl_map_object_deps we immediately free the old l_initfini maps instead of saving them to l_orig_initfini. We also use a new flag l_free_initfini to mark that the maps were dynamically allocated and need to be free'd. * Given that we free the old l_initfini immediately, we only have the current l_initfini to free when l_free_initfini is 1, and that is done in libc_freeres_fn. This seems logical and the change looks correct. However, what was *actually* wrong with the original implementation? Was it the swapping back of the l_orig_initfini? What is wrong with the old l_orig_initfini? -- 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 this bug go to: https://bugs.launchpad.net/glibc/+bug/893605/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 893605]
(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't want
> +to recompute it as it would involve a new call to
> +map_object_deps.
> + _dl_scope_free (oldp); */
Thanks this is starting to explain the problem.
Why is l_searchlist.r_list sharing the memory of l_initfini, they each
have nothing to do with eachother, other than the fact that they are
both of type `struct link_map **`.
In dl-close.c I see this:
~~~
318 if (imap->l_searchlist.r_list == NULL && imap->l_initfini != NULL)
319 {
320 /* The object is still used. But one of the objects we are
321 unloading right now is responsible for loading it. If
322 the current object does not have it's own scope yet we
323 have to create one. This has to be done before running
324 the finalizers.
325
326 To do this count the number of dependencies. */
327 unsigned int cnt;
328 for (cnt = 1; imap->l_initfini[cnt] != NULL; ++cnt)
329 ;
330
331 /* We simply reuse the l_initfini list. */
332 imap->l_searchlist.r_list = &imap->l_initfini[cnt + 1];
333 imap->l_searchlist.r_nlist = cnt;
334
335 new_list = &imap->l_searchlist;
336 }
~~~
Which doesn't make any sense to me. Why are we resusing l_initfini for what
appears to be a completely orthogonal purpose?
However, in dl-deps.c(_dl_map_object_deps) we clearly get:
~~~
513 /* Store the search list we built in the object. It will be used for
514 searches in the scope of this object. */
515 struct link_map **l_initfini =
516 (struct link_map **) malloc ((2 * nlist + 1)
517 * sizeof (struct link_map *));
518 if (l_initfini == NULL)
519 _dl_signal_error (ENOMEM, map->l_name, NULL,
520 N_("cannot allocate symbol search list"));
521
522
523 map->l_searchlist.r_list = &l_initfini[nlist + 1];
524 map->l_searchlist.r_nlist = nlist;
~~~
Which allocates a list of 2*nlist+1 size, and points l_searchlist.r_list into
nlist+1 which is 2 beyond nlist pointers, and we see why it does this in a
second...
Then we point l_initfini at the start of the memory block and terminate it:
~~~
687 /* Terminate the list of dependencies. */
688 l_initfini[nlist] = NULL;
689 atomic_write_barrier ();
690 map->l_initfini = l_initfini;
~~~
So we have a contiguous allocation of pointers split in two with a NULL
entry:
|A---|NULL|B-|
Where map->l_initfini points to A [0,nlist], including NULL, it is
nlist+1 pointers.
Where map->l_searchlist.r_list points to B [nlist+1,2*nlist+1] which is
only nlist pointers.
Obviously freeing l_initfini is impossible unless you also clear
l_searchlist.r_list, and then you'd have to recompute the r_list.
I need to think about this some more.
--
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 this bug go to:
https://bugs.launchpad.net/glibc/+bug/893605/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 893605]
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 this bug go to: https://bugs.launchpad.net/glibc/+bug/893605/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 893605]
*** 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 manage notifications about this bug go to: https://bugs.launchpad.net/glibc/+bug/893605/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 929219]
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_mapping() or gethostbyname2_r() To manage notifications about this bug go to: https://bugs.launchpad.net/eglibc/+bug/929219/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 893605]
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 the previously free'd l_initfini was accessed through l_searchlist when a library had been opened for the second time. ~~~ http://sourceware.org/git/?p=glibc.git;a=commit;h=0479b305c5b7c8e3fa8e3002982cf8cac02b842e Filed BZ #14284 for the backport request. -- 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 this bug go to: https://bugs.launchpad.net/glibc/+bug/893605/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 893605]
(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 change. I'm running some final tests on the smaller patch and I'll post to libc- alpha for final review, then we'll check it in for 2.16. -- 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 this bug go to: https://bugs.launchpad.net/glibc/+bug/893605/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
