Bug#233301: Proposed glibc fix about dynamic linker reference counting problem for #233301
- To: Steve Langasek <email@example.com>, "Adam Conrad" <firstname.lastname@example.org>, Jeff Bailey <email@example.com>, Matthew Exley <firstname.lastname@example.org>, Ryan Brown <email@example.com>, Joerg Wendland <firstname.lastname@example.org>, email@example.com, gonadman <firstname.lastname@example.org>, William Steve Applegate <email@example.com>, Todor Todorov <firstname.lastname@example.org>, oryn <email@example.com>, Birzan George Cristian <firstname.lastname@example.org>, Jeroen van Wolffelaar <email@example.com>, "Massimo Fidanza" <firstname.lastname@example.org>, Stian Jordet <email@example.com>, Jon Bright <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org
- Cc: email@example.com
- Subject: Bug#233301: Proposed glibc fix about dynamic linker reference counting problem for #233301
- From: GOTO Masanori <firstname.lastname@example.org>
- Date: Fri, 10 Sep 2004 00:48:45 +0900
- Message-id: <email@example.com>
- Reply-to: GOTO Masanori <firstname.lastname@example.org>, email@example.com
The bug #233301 is marked as Release Critical recently, and actually
it's one of the complicated and the last remained problem for glibc.
#233301 says that there's something bug around the glibc internal
runtime dynamic library loader, and it causes problem for PHP, SSL,
IMAP, and so on.
I struggled with this problem, then finally I think it's glibc's bug.
My proposed glibc .deb 2.3.2.ds1-17 is put at:
Could you test this glibc on your machine if you can? In this
version, I touched the core dynamic linking code. This means that if
my fix is wrong, then it causes another dlopen/dlclose problem.
Before duploading -17, it's important to test glibc to check the
problem which I have not known yet. Please test it and report me the
Note that my current proposed patch passed all glibc test code.
However, it may still have problem. If I find another problem, I hope
you'll test newer glibc with my another fix again.
At Wed, 18 Feb 2004 10:13:25 -0600,
Steve Langasek wrote:
> From elf/dl-lookup.c, lines 179 ff.:
> if (__builtin_expect (act < undef_map->l_reldepsmax, 1))
> undef_map->l_reldeps[undef_map->l_reldepsact++] = map;
> if (map->l_searchlist.r_list != NULL)
> /* And increment the counter in the referenced object. */
> /* We have to bump the counts for all dependencies since so far
> this object was only a normal or transitive dependency.
> Now it might be closed with _dl_close() directly. */
> for (list = map->l_initfini; *list != NULL; ++list)
> This causes the opencount for libcrypto.so to be incremented once when
> an libssl symbol is referenced (because l_searchlist.r_list is NULL and
> libcrypto is in libssl's l_initfini list), and once when a symbol from
> libcrypto itself is referenced. The second reference has a
> corresponding entry in l_reldeps which is therefore cleared on
> dlclose(), but the first does not.
> I'm not comfortable suggesting any particular fix here; the one that's
> apparent to me would be to drop the conditional altogether and always
> just increment map->l_opencount instead of mucking around with
> l_initfini, but given that I don't have an understanding of why this
> stuff is there to begin with, I could be way off base.
Yes, my patch is related with this dl-lookup reference counting part.
In this function, it bumps up all (*list)->l_opencount, but it does
not count down at _dl_close.