On Wed, Feb 25, 2004 at 12:05:38AM +0900, GOTO Masanori wrote: > 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. Working with Jeff Bailey, I've put together a test case that shows this problem. http://people.debian.org/~vorlon/test.tar.gz Build the application, and strace it -- you will see that the call to dlclose() results in munmap() calls for the addresses of only 3 of the four shared objects that were mapped by dlopen(). The one at the bottom of the dependency tree, libd.so, is still in memory. I believe Jeff was bringing this to upstream's attention at my request; you probably want to coordinate with him. Thanks, -- Steve Langasek postmodern programmer
Attachment:
pgp41GAKk9iEj.pgp
Description: PGP signature