From: Jakub Jelinek <jakub@redhat.com>
To: Ulrich Drepper <drepper@redhat.com>
Cc: Glibc hackers <libc-hacker@sources.redhat.com>
Subject: [PATCH] dl-fini.c fix
Date: Wed, 07 Jul 2004 17:50:00 -0000 [thread overview]
Message-ID: <20040707153459.GK5191@sunsite.ms.mff.cuni.cz> (raw)
Hi!
I believe we must store GL(dl_nloaded) into a local variable before
releasing GL(dl_load_lock), as after unlock GL(dl_nloaded) can be e.g.
increased at any time and we wouldn't know exactly what size the maps
array exactly had.
2004-07-07 Jakub Jelinek <jakub@redhat.com>
* elf/dl-fini.c (_dl_fini): Add nloaded variable, load
GL(dl_nloaded) into it while still in critical section.
--- libc/elf/dl-fini.c.jj 2004-07-07 19:37:01.000000000 +0200
+++ libc/elf/dl-fini.c 2004-07-07 19:42:11.640215410 +0200
@@ -42,23 +42,24 @@ _dl_fini (void)
using `dlopen' there are possibly several other modules with its
dependencies to be taken into account. Therefore we have to start
determining the order of the modules once again from the beginning. */
- unsigned int i;
+ unsigned int i, nloaded;
struct link_map *l;
struct link_map **maps;
/* Protect against concurrent loads and unloads. */
__rtld_lock_lock_recursive (GL(dl_load_lock));
+ nloaded = GL(dl_nloaded);
+
/* XXX Could it be (in static binaries) that there is no object loaded? */
- assert (GL(dl_nloaded) > 0);
+ assert (nloaded > 0);
/* Now we can allocate an array to hold all the pointers and copy
the pointers in. */
- maps = (struct link_map **) alloca (GL(dl_nloaded)
- * sizeof (struct link_map *));
+ maps = (struct link_map **) alloca (nloaded * sizeof (struct link_map *));
for (l = GL(dl_loaded), i = 0; l != NULL; l = l->l_next)
{
- assert (i < GL(dl_nloaded));
+ assert (i < nloaded);
maps[i++] = l;
@@ -66,7 +67,7 @@ _dl_fini (void)
from underneath us. */
++l->l_opencount;
}
- assert (i == GL(dl_nloaded));
+ assert (i == nloaded);
/* Now we have to do the sorting. */
for (l = GL(dl_loaded)->l_next; l != NULL; l = l->l_next)
@@ -80,7 +81,7 @@ _dl_fini (void)
/* Find all object for which the current one is a dependency and
move the found object (if necessary) in front. */
- for (k = j + 1; k < GL(dl_nloaded); ++k)
+ for (k = j + 1; k < nloaded; ++k)
{
struct link_map **runp = maps[k]->l_initfini;
if (runp != NULL)
@@ -136,7 +137,7 @@ _dl_fini (void)
/* 'maps' now contains the objects in the right order. Now call the
destructors. We have to process this array from the front. */
- for (i = 0; i < GL(dl_nloaded); ++i)
+ for (i = 0; i < nloaded; ++i)
{
l = maps[i];
Jakub
next reply other threads:[~2004-07-07 17:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-07 17:50 Jakub Jelinek [this message]
2004-07-08 3:20 ` Ulrich Drepper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040707153459.GK5191@sunsite.ms.mff.cuni.cz \
--to=jakub@redhat.com \
--cc=drepper@redhat.com \
--cc=libc-hacker@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).