ID: 36208 Updated by: [EMAIL PROTECTED] Reported By: hb at gentoo dot x256 dot org -Status: Open +Status: Feedback Bug Type: Dynamic loading Operating System: Gentoo Linux x86 PHP Version: 5.1.2 New Comment:
Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Previous Comments: ------------------------------------------------------------------------ [2006-02-01 11:05:01] hb at gentoo dot x256 dot org 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. ------------------------------------------------------------------------ [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; </%INIT> 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
