|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2002-01-05 09:00 UTC] msopacua at idg dot nl
First some details:
gd version: 2.0.1, using custom Makefile (will send it seperately to the php-dev list).
Tested OS: BSDi 4.2, but bug exists in elder versions of all components (OS/PHP/GD)
When apache receives a SIGUSR1, the childs start cycling, eating CPU power and causing a load of appr. 3 per apache child.
A SIGHUP doesn't work correctly:
[Sat Jan 5 13:52:57 2002] [notice] caught SIGTERM, shutting down
[Sat Jan 5 13:55:56 2002] [notice] Apache/1.3.22 (Unix) PHP/4.2.0-dev mod_perl/1.26 configured -- resuming normal operations
[Sat Jan 5 13:55:56 2002] [notice] Accept mutex: flock (Default: flock)
[Sat Jan 5 13:56:00 2002] [warn] child process 18897 did not exit, sending another SIGHUP
[Sat Jan 5 13:56:00 2002] [warn] child process 18898 did not exit, sending another SIGHUP
[Sat Jan 5 13:56:00 2002] [warn] child process 18899 did not exit, sending another SIGHUP
[Sat Jan 5 13:56:00 2002] [warn] child process 18900 did not exit, sending another SIGHUP
[Sat Jan 5 13:56:00 2002] [warn] child process 18901 did not exit, sending another SIGHUP
[Sat Jan 5 13:56:02 2002] [warn] child process 18897 still did not exit, sending a SIGTERM
[Sat Jan 5 13:56:02 2002] [warn] child process 18898 still did not exit, sending a SIGTERM
[Sat Jan 5 13:56:02 2002] [warn] child process 18899 still did not exit, sending a SIGTERM
[Sat Jan 5 13:56:02 2002] [warn] child process 18900 still did not exit, sending a SIGTERM
[Sat Jan 5 13:56:02 2002] [warn] child process 18901 still did not exit, sending a SIGTERM
[Sat Jan 5 13:56:06 2002] [error] child process 18897 still did not exit, sending a SIGKILL
[Sat Jan 5 13:56:06 2002] [error] child process 18898 still did not exit, sending a SIGKILL
[Sat Jan 5 13:56:06 2002] [error] child process 18899 still did not exit, sending a SIGKILL
[Sat Jan 5 13:56:06 2002] [error] child process 18900 still did not exit, sending a SIGKILL
[Sat Jan 5 13:56:06 2002] [error] child process 18901 still did not exit, sending a SIGKILL
[Sat Jan 5 13:56:06 2002] [notice] SIGHUP received. Attempting to restart
[Sat Jan 5 13:56:06 2002] [notice] Apache/1.3.22 (Unix) PHP/4.2.0-dev mod_perl/1.26 configured -- resuming normal operations
[Sat Jan 5 13:56:06 2002] [notice] Accept mutex: flock (Default: flock)
All this disappears, when eliminating gd from the equasion.
I think the cause lies in the linking of the library. Even though I have configured php to use the shared version:
--with-gd=shared,/weblib/local \
--with-freetype-dir=/weblib/local
gd is linked into libphp4.so:
$ ldd libphp4.so
./libphp4.so => ./libphp4.so (0x4805b000)
libdl.so => /shlib/libdl.so (0x481f9000)
libm.so => /shlib/libm.so.0.0 (0x481fd000)
libsablot.so.0 => /weblib/local/lib/libsablot.so.0 (0x4820e000)
libexpat.so.0 => /weblib/local/lib/libexpat.so.0 (0x482b6000)
libmysqlclient.so.10 => /weblib/local/lib/mysql/libmysqlclient.so.10 (0x482d7000)
libiconv.so.2 => /weblib/local/lib/libiconv.so.2 (0x482f4000)
libgd.so.2 => /weblib/local/lib/libgd.so.2 (0x483c9000)
libfreetype.so.6 => /weblib/local/lib/libfreetype.so.6 (0x483fc000)
libssl.so.0.9.6 => /weblib/local/lib/libssl.so.0.9.6 (0x48430000)
libcrypto.so.0.9.6 => /weblib/local/lib/libcrypto.so.0.9.6 (0x484e6000)
libc.so.2 => /shlib/libc.so.2 (0x485a8000)
libgcc.so.1 => /shlib/libgcc.so.1 (0x48674000)
libz.so => /usr/lib/libz.so (0x48681000)
libpng.so.2 => /weblib/local/lib/libpng.so.2 (0x48690000)
The shared lib in lib/php/20010901-debug only links itself and the standard c libs:
$ ldd libgd.so
./libgd.so => ./libgd.so (0x4805b000)
libc.so.2 => /shlib/libc.so.2 (0x48070000)
libgcc.so.1 => /shlib/libgcc.so.1 (0x4813c000)
If I compare this to pg for instance, it is not in the php4 lib and it shows proper linking with the pg native libs:
$ ldd libpgsql.so
./libpgsql.so => ./libpgsql.so (0x4805b000)
libpq.so.2 => /pgsql/lib/libpq.so.2 (0x48069000)
libc.so.2 => /shlib/libc.so.2 (0x48079000)
libgcc.so.1 => /shlib/libgcc.so.1 (0x48145000)
libssl.so.0.9.6 => /weblib/local/lib/libssl.so.0.9.6 (0x48152000)
libcrypto.so.0.9.6 => /weblib/local/lib/libcrypto.so.0.9.6 (0x48208000)
libdl.so => /shlib/libdl.so (0x482ca000)
The reason I need a custom Makefile for gd, is because the standard gd library Makefile, creates a libgd.so, which generates a crash on startup of apache, and ldd on this library, doesn't even detect any dependancies, nor does it give 'statically linked' - just a blank line.
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2024 The PHP GroupAll rights reserved. |
Last updated: Sat Dec 21 12:01:31 2024 UTC |
Sorry - but I can't retry: mdev@valygar.idg.nl ~/_src/php4-200210160300 $ gmake install Installing PHP SAPI module [activating module `php4' in /apache/conf/httpd.conf] cp libs/libphp4.so /apache/libexec/libphp4.so cp: libs/libphp4.so: No such file or directory apxs:Break: Command failed with rc=1 gmake: *** [install-sapi] Error 1 mdev@valygar.idg.nl ~/_src/php4-200210160300 $ ls libs libphp4.a libphp4.la mdev@valygar.idg.nl ~/_src/php4-200210160300 $ cat configure-cmd.sh #!/bin/sh ./configure \ --prefix=/php \ --with-mysql=/weblib/local \ --with-zlib-dir=/usr \ --with-gd=php \ --with-jpeg-dir=/weblib/local \ --with-freetype-dir=/weblib/local \ --enable-sockets \ --with-apxs=/apache/bin/apxsNope - wrong guess :-). It is not just GD. When I removed GD from the below configuration, it still didn't work. The following works correctly: ./configure \ --prefix=/php \ --disable-mbstring \ --with-zlib=/usr \ --with-zlib-dir=/usr \ --with-apxs=/apache/bin/apxs I'll use --disable-all and make a list of extensions that have/expose these problems. Maybe there's a common factor.I've created a php script, to test this :-). Output is as follows: ============================================================ RESULTS SIGTEST ------------------------------------------------------------ Mysql bundled: OK Mysql external: NOT OK Aspell external: NOT OK GD bundled: OK XML Bundled: OK XML external: OK XSLT external: NOT OK Iconv external: OK GNU gettext, external: OK OpenSSL external: NOT OK Curl external, without SSL: NOT OK Curl external, with SSL: NOT OK ============================================================ The commonalities seem to be, that the modules which fail, load more than 1 external shared library. MySQL loads zlib, Aspell loads several aspell libs, OpenSSL has -lssl and -lcrypt and curl loads -lssl ("Curl external, without SSL", simply means --with-openssl was not given. -lssl and -lcrypt are still linked in). The only exceptions to this, are the Bundled GD, which is compiled with libjpeg, libpng, libz and libfreetype and the Bundled MySQL. The common factors with these is, that libphp4.so doesn't call libgd/libmysqlclient, but has this code built in. Concluding this goes wrong when there are 2 levels of dynamic loading: apache -> libphp4 -> libfoo -> libbar It reminded me of bug in BSD/OS 4.x series, on how symbols are resolved: http://www.geocrawler.com/archives/3/127/1999/5/0/1795873/ Can somebody experience in this, take a look if it makes any sense in comparison to what PHP is doing?