#36208 [Opn]: Symbols in libphp5.so conflict with symbols in libgd.so and cause apache probs
ID: 36208 User updated by: hb at gentoo dot x256 dot org Reported By: hb at gentoo dot x256 dot org Status: Open Bug Type: Dynamic loading Operating System: Gentoo Linux x86 PHP Version: 5.1.2 New Comment: Sorry, as I said, I spent over a day tracking down this problem. I submitted a bug report to Gentoo and they told me it was not their problem and that it should be fixed in PHP, which seemed somewhat reasonable. Then I was told that it had to be configured differently, which would require a change in Gentoo, but this problem would remain in other distributions. I just want to fix it so that other people don't have to go through what I did. I will try to make a patch. Previous Comments: [2006-02-01 09:16:40] [EMAIL PROTECTED] There is no need to use this kind of language, it will not make us help you faster. That said, we actually do namespace protect those symbols in there by prefixing them with php_gd_. It seems however that some of them are not added yet, see the file main/php_compat.h. Feel free to submit a patch for that file. [2006-02-01 05:33:10] hb at gentoo dot x256 dot org This is a problem with PHP. You can't just tell me to compile it differently because in the real world, when actual users compile and install perl and PHP, they won't know this. There's no warning that I ever saw that tells me not to do this, and then my programs randomly crash, and I spent a whole day trying to work out why. This WILL happen to other people unless you fix YOUR bug, which is exporting non-standard GD symbols with standard names into the dynamic linker namespace. They should be renamed or hidden or set to a different version so they won't collide with the real GD. I guess if you're unwilling to fix it I'll have to get the Gentoo people to either patch PHP or change the portage system so it won't install PHP and mod_perl simultaneously with USE=gd. However, this has the possibility of biting people in other circumstances too. I can't understand why you say it's not your problem. You shouldn't export symbols willy-nilly especially when you modify them from the library you pulled them from originally and don't rename them. [2006-02-01 01:16:12] [EMAIL PROTECTED] In case when you need to compile another apache module that uses gdlib you need to compile php with the system library. (--with-gd=/path/to/system/gdlib) ------------------------ [2006-01-30 12:45:16] hb at gentoo dot x256 dot org Description: PHP includes a tweaked GD library. It is not compatible with libgd. The problem is, it uses the same symbols (i.e. function names) as libgd and exports them from its shared object. When I load mod_php and mod_perl into Apache, mod_perl programs using the GD library end up sometimes calling PHP's modified GD routines and sometimes not. This causes Apache children to crash semi-randomly. Since the PHP GD library is not compatible with libgd itself (and because it's likely to be co-existing with a different version of libgd on the system, regardless of tweaks), the symbols (functions and others) should be renamed. Perhaps with a PHP_ prefix. This way there will be no dynamic loading collision and PHP/PERL will be able to co-exist in Apache children without damage. I worked around this by recompiling libPHP with external GD library support. However, it took me several hours to diagnose the exact problem. I have also been bitten by this once before already. I recommend fixing this in PHP4 as well as PHP5. Reproduce code: --- This PERL/MASON script crashes every time if libphp5.so is loaded as an Apache module, but works perfectly otherwise: <%INIT> use strict; use GD::Graph::lines; my $tgraph = GD::Graph::lines->new(800, 800); my $tgd = $tgraph->plot([ [ "a" ], [ 0 ] ]); print $tgd->png(); return; Expected result: Blank graph. Actual result: -- Zero-sized reply. GLIBC memory corruption reported upon free() in error_log. -- Edit this bug report at http://bugs.php.net/?id=36208&edit=1
#36208 [WFx]: Symbols in libphp5.so conflict with symbols in libgd.so and cause apache probs
ID: 36208 User updated by: hb at gentoo dot x256 dot org Reported By: hb at gentoo dot x256 dot org Status: Wont fix Bug Type: Dynamic loading Operating System: Gentoo Linux x86 PHP Version: 5.1.2 New Comment: This is a problem with PHP. You can't just tell me to compile it differently because in the real world, when actual users compile and install perl and PHP, they won't know this. There's no warning that I ever saw that tells me not to do this, and then my programs randomly crash, and I spent a whole day trying to work out why. This WILL happen to other people unless you fix YOUR bug, which is exporting non-standard GD symbols with standard names into the dynamic linker namespace. They should be renamed or hidden or set to a different version so they won't collide with the real GD. I guess if you're unwilling to fix it I'll have to get the Gentoo people to either patch PHP or change the portage system so it won't install PHP and mod_perl simultaneously with USE=gd. However, this has the possibility of biting people in other circumstances too. I can't understand why you say it's not your problem. You shouldn't export symbols willy-nilly especially when you modify them from the library you pulled them from originally and don't rename them. Previous Comments: [2006-02-01 01:16:12] [EMAIL PROTECTED] In case when you need to compile another apache module that uses gdlib you need to compile php with the system library. (--with-gd=/path/to/system/gdlib) ------------------------ [2006-01-30 12:45:16] hb at gentoo dot x256 dot org Description: PHP includes a tweaked GD library. It is not compatible with libgd. The problem is, it uses the same symbols (i.e. function names) as libgd and exports them from its shared object. When I load mod_php and mod_perl into Apache, mod_perl programs using the GD library end up sometimes calling PHP's modified GD routines and sometimes not. This causes Apache children to crash semi-randomly. Since the PHP GD library is not compatible with libgd itself (and because it's likely to be co-existing with a different version of libgd on the system, regardless of tweaks), the symbols (functions and others) should be renamed. Perhaps with a PHP_ prefix. This way there will be no dynamic loading collision and PHP/PERL will be able to co-exist in Apache children without damage. I worked around this by recompiling libPHP with external GD library support. However, it took me several hours to diagnose the exact problem. I have also been bitten by this once before already. I recommend fixing this in PHP4 as well as PHP5. Reproduce code: --- This PERL/MASON script crashes every time if libphp5.so is loaded as an Apache module, but works perfectly otherwise: <%INIT> use strict; use GD::Graph::lines; my $tgraph = GD::Graph::lines->new(800, 800); my $tgd = $tgraph->plot([ [ "a" ], [ 0 ] ]); print $tgd->png(); return; Expected result: Blank graph. Actual result: -- Zero-sized reply. GLIBC memory corruption reported upon free() in error_log. -- Edit this bug report at http://bugs.php.net/?id=36208&edit=1
#36208 [NEW]: Symbols in libphp5.so conflict with symbols in libgd.so and cause apache probs
From: hb at gentoo dot x256 dot org Operating system: Gentoo Linux x86 PHP version: 5.1.2 PHP Bug Type: Dynamic loading Bug description: Symbols in libphp5.so conflict with symbols in libgd.so and cause apache probs Description: PHP includes a tweaked GD library. It is not compatible with libgd. The problem is, it uses the same symbols (i.e. function names) as libgd and exports them from its shared object. When I load mod_php and mod_perl into Apache, mod_perl programs using the GD library end up sometimes calling PHP's modified GD routines and sometimes not. This causes Apache children to crash semi-randomly. Since the PHP GD library is not compatible with libgd itself (and because it's likely to be co-existing with a different version of libgd on the system, regardless of tweaks), the symbols (functions and others) should be renamed. Perhaps with a PHP_ prefix. This way there will be no dynamic loading collision and PHP/PERL will be able to co-exist in Apache children without damage. I worked around this by recompiling libPHP with external GD library support. However, it took me several hours to diagnose the exact problem. I have also been bitten by this once before already. I recommend fixing this in PHP4 as well as PHP5. Reproduce code: --- This PERL/MASON script crashes every time if libphp5.so is loaded as an Apache module, but works perfectly otherwise: <%INIT> use strict; use GD::Graph::lines; my $tgraph = GD::Graph::lines->new(800, 800); my $tgd = $tgraph->plot([ [ "a" ], [ 0 ] ]); print $tgd->png(); return; Expected result: Blank graph. Actual result: -- Zero-sized reply. GLIBC memory corruption reported upon free() in error_log. -- Edit bug report at http://bugs.php.net/?id=36208&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36208&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36208&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36208&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36208&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36208&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36208&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36208&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36208&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36208&r=support Expected behavior:http://bugs.php.net/fix.php?id=36208&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36208&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36208&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36208&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36208&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36208&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36208&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36208&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36208&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36208&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36208&r=mysqlcfg
