[Bug 893605]
Carlos-odonell
893605 at bugs.launchpad.net
Fri Apr 6 08:48:59 UTC 2012
(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
Foundations Bugs, which is subscribed to eglibc in Ubuntu.
https://bugs.launchpad.net/bugs/893605
Title:
crashes with glibc-2.14/2.15 on dlopen (seen with kvm and gnucash)
Status in The GNU C Library:
Confirmed
Status in “eglibc” package in Ubuntu:
Fix Released
Status in “glibc” package in Fedora:
Unknown
Bug description:
seen with glibc-2.14/glibc-2.15:
kvm -cdrom <iso>
Program received signal SIGSEGV, Segmentation fault.
0xb7fe7740 in ?? () from /lib/ld-linux.so.2
(gdb) bt
#0 0xb7fe7740 in ?? () from /lib/ld-linux.so.2
#1 0xb7fe7eb9 in ?? () from /lib/ld-linux.so.2
#2 0xb7a26490 in do_sym (handle=0xb7d86860,
name=0xb7c7ff4f "XAllocClassHint", who=<optimized out>, vers=0x0, flags=2)
at dl-sym.c:178
#3 0xb7a26927 in _dl_sym (handle=<optimized out>, name=<optimized out>,
who=<optimized out>) at dl-sym.c:283
#4 0xb778cd67 in dlsym_doit (a=0xbfffeef0) at dlsym.c:51
#5 0xb7feccaf in ?? () from /lib/ld-linux.so.2
#6 0xb778d33a in _dlerror_run (operate=0xb778cd40 <dlsym_doit>,
args=0xbfffeef0) at dlerror.c:164
#7 0xb778cde4 in __dlsym (handle=0xb7d86860,
name=0xb7c7ff4f "XAllocClassHint") at dlsym.c:71
#8 0xb7c56b5a in SDL_LoadFunction () from /usr/lib/libSDL-1.2.so.0
#9 0xb7c58511 in ?? () from /usr/lib/libSDL-1.2.so.0
#10 0xb7c5a8aa in ?? () from /usr/lib/libSDL-1.2.so.0
#11 0xb7c61825 in ?? () from /usr/lib/libSDL-1.2.so.0
#12 0xb7c5155a in SDL_VideoInit () from /usr/lib/libSDL-1.2.so.0
#13 0xb7c25c7a in SDL_InitSubSystem () from /usr/lib/libSDL-1.2.so.0
#14 0xb7c25cfb in SDL_Init () from /usr/lib/libSDL-1.2.so.0
#15 0x00202967 in ?? ()
---Type <return> to continue, or q <return> to quit---
#16 0x0013cfdc in main ()
gnucash:
Program received signal SIGSEGV, Segmentation fault.
0x00119740 in ?? () from /lib/ld-linux.so.2
(gdb) bt
#0 0x00119740 in ?? () from /lib/ld-linux.so.2
#1 0x00119eb9 in ?? () from /lib/ld-linux.so.2
#2 0x00c0a490 in do_sym (handle=0xb7ffd000,
name=0x10eeec4 "g_module_check_init", who=<optimized out>, vers=0x0,
flags=2) at dl-sym.c:178
#3 0x00c0a927 in _dl_sym (handle=<optimized out>, name=<optimized out>,
who=<optimized out>) at dl-sym.c:283
#4 0x03195d67 in dlsym_doit (a=0xbfffedc0) at dlsym.c:51
#5 0x0011ecaf in ?? () from /lib/ld-linux.so.2
#6 0x0319633a in _dlerror_run (operate=0x3195d40 <dlsym_doit>,
args=0xbfffedc0) at dlerror.c:164
#7 0x03195de4 in __dlsym (handle=0xb7ffd000,
name=0x10eeec4 "g_module_check_init") at dlsym.c:71
#8 0x010ee065 in g_module_symbol ()
from /usr/lib/i386-linux-gnu/libgmodule-2.0.so.0
#9 0x010ee54f in g_module_open ()
from /usr/lib/i386-linux-gnu/libgmodule-2.0.so.0
#10 0x003ff61e in ?? () from /usr/lib/gnucash/libgnc-module.so.0
#11 0x003ff90b in gnc_module_load () from /usr/lib/gnucash/libgnc-module.so.0
#12 0x0804ca5f in _start ()
To manage notifications about this bug go to:
https://bugs.launchpad.net/glibc/+bug/893605/+subscriptions
More information about the foundations-bugs
mailing list