I've made some progress into figuring out the source of the glibc 2.3, apache, php4, php4-imap segfaults. I suspect that php4 and openssl are ultimately at fault (at least, a change with regards to these two packages seems to correct the error), but I'm not certain, so I'm sending a follow-up to the bug report to get feedback before reassigning back to PHP4. What I noticed in the startup behavior of Apache is that there are two cycles of loading/unloading the Apache DSOs. After loading the DSOs once, Apache then unloads them (God knows why), and loads them again. The unload (dlclose) also causes all DSO-specific dependency libs to be unloaded -- with the singular exception of OpenSSL's libcrypto. This horrid library has probably been inadvertently referenced by Apache itself, because it contains symbols with such original names as 'string_to_hex', 'crypt', and 'MD5_Init'. Five to one says that 'crypt' is the culprit somehow. Now, it's entirely possible that the unloading of the library has nothing at all to do with the final segfaults people have been experiencing; at least, I haven't been able to figure out how glibc 2.3 would cause this problem if glibc 2.2 didn't. Nevertheless, it did set me on the path to a fix, as I tried to recompile libphp4.so without that ridiculous OpenSSL dependency. Adam, I don't know if you were aware of this (I was not), but upstream has overloaded the meaning of the --with-ssl configure option such that it not only controls whether OpenSSL should be used when linking other extensions (e.g., snmp), it also enables an 'openssl' extension that *can't be built as a shared extension*. This means that the only way to get rid of libphp4's dependency on libcrypto is to recompile it without OpenSSL support -- which also means that the snmp extension can't be built at the same time. I want to discuss with you how to best solve this packaging problem, both in the short term and in the long term, before trying to upload any sort of a "hotfix". Note, BTW, that just rebuilding php4 against glibc 2.3 does not fix the problem. Only compiling it without OpenSSL support fixes the problem. Michael, thank you for the use of your machine in tracking this down. There is a libphp4.so binary that has been unceremoniously dropped in your /usr/lib/apache/1.3/ directory which appears to do the trick as far as getting Apache running. Since it may still be a few weeks before everything is sorted out in unstable, I hope this file might prove useful to you in the meantime. Michel, thank you also for your offer. As you can see, it turned out to be unnecessary, but if you would also like a copy of the fixed libphp4.so binary (it's too raw yet to be distributed in a package), or if you would like me to guide you through building a fixed local php4 package, just let me know. -- Steve Langasek postmodern programmer
Attachment:
pgpapvdWfzZrx.pgp
Description: PGP signature