Bug#233301: Proposed glibc fix about dynamic linker reference counting problem for #233301

[GOTO Masanori <gotom@debian.or.jp>]

Hi,

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:

	http://www.gotom.jp/~gotom/debian/glibc/2.3.2.ds1-17_i386.test1-dlref/

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
result.

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.  */
>         ++map->l_opencount;
>       else
>         /* 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)
>           ++(*list)->l_opencount;
> 
> 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.

Regards,
-- gotom