Bug #14870 Updated: GD breaks SIGUSR1 and SIGHUP

ID: 14870 Updated by: sniper@php.net Reported By: msopacua@idg.nl -Status: Open +Status: Feedback -Bug Type: GD related +Bug Type: Dynamic loading Operating System: BSDi 4.x PHP Version: 4.0CVS-2002-01-05 New Comment: Ah, I missed that 'shared' point here. Reclassified.. If it happens with other extensions too..well, then it's bit bigger issue. btw. Why would you send apache a 'SIGUSR1'? And SIGHUP hasn't ever worked when PHP is compiled as DSO, you should stop/start instead of 'restart'. --Jani Previous Comments: ------------------------------------------------------------------------ [2002-06-28 06:14:39] msopacua@idg.nl Well, over time this started to happen with other extensions as well. So right now, I'm not even trying to compile a dynamic version anymore. I'll do this over the weekend though. Would you prefer to know the bundled gd results or the external? ------------------------------------------------------------------------ [2002-06-28 05:40:55] sniper@php.net Is this still happening with latest CVS checkout? ------------------------------------------------------------------------ [2002-01-05 09:00:14] msopacua@idg.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. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=14870&edit=1