[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Package: libc6
Version: 2.3.2.ds1-11
Severity: important

This appears to be the problem at the root of bug #205553.

I have confirmed that there is a reference counting problem in glibc 2.3
under certain conditions when dlopen()ing a shared object with certain
ELF dependencies.

imap.so: links against libc-client.so.2002edebian, and depends on
  symbols provided by it

libc-client.so.2002edebian: links against libssl.so.0.9.7 and
  libcrypto.so.0.9.7, and depends on symbols provided by both

libssl.so.0.9.7: links against libcrypto.so.0.9.7, and depends on
  symbols provided by it

Setting 'extension=imap.so' in /etc/php4/cgi/php.ini will cause the php4
binary (from the php4-cgi package) to dlopen() the imap.so object (from
the php4-imap package).  After loading everything, and after calling the
ssl_onceonlyinit() function:

- the l_opencount on the link map entry for libcrypto.so.0.9.7 is 3,
  which appears to be correct (consistent with other libraries): 1 for
  the dlopen call itself, 1 for the symbol bindings from
  libc-client.so.2002edebian, and 1 for the symbol bindings from
  libssl.so.0.9.7.
- the l_reldeps list for libssl.so.0.9.7 is one entry long, pointing to
  libcrypto.so.0.9.7
- the l_reldeps list for libc-client.so.2002edebian is *also* one entry
  long, pointing to libssl.so.0.9.7 only.

In the case where php4 is itself being run as a DSO under apache (1.3),
which has a two-stage dlopen()/dlclose()/dlopen() init process, this
means that the reference count is non-zero on libcrypto at the end, and
this library is therefore not unmapped and re-mapped.  This can be
verified even when running php4 as a standalone, since it will dlclose()
imap.so before exiting, but in the apache case this seems to lead
directly to a segfault during the second part of the initialization
routine.

Still digging through the glibc code here to see if I can spot the bug,
but I'd be happy if someone else who might be more familiar with that
code might also have time to look at this.

-- 
Steve Langasek
postmodern programmer

Attachment: pgpIlh3B8VDVL.pgp
Description: PGP signature


Reply to: