Bug#233301: linker reference count error among dependencies of dlopen()ed object

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

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.

I don't understand what the problem exists...  Could you provide short
summary and tell us what the bug is, plus small sample program?  PHP
based issue is hard to reappear for me, and relaxing complex program
dependency is good step to resolve bug, I think.

Regards,
-- gotom