php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #36208 Symbols in libphp5.so conflict with symbols in libgd.so and cause apache probs
Submitted: 2006-01-30 12:45 UTC Modified: 2006-02-01 14:54 UTC
From: hb at gentoo dot x256 dot org Assigned:
Status: Closed Package: Dynamic loading
PHP Version: 5.1.2 OS: Gentoo Linux x86
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: hb at gentoo dot x256 dot org
New email:
PHP Version: OS:

 

 [2006-01-30 12:45 UTC] 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.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-02-01 01:16 UTC] edink@php.net 
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-02-01 05:33 UTC] 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 09:16 UTC] derick@php.net 
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 11:05 UTC] 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 12:05 UTC] tony2001@php.net 
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.
 [2006-02-01 13:16 UTC] jakub at gentoo dot org 
patch for 5.0.5:
http://bugs.gentoo.org/attachment.cgi?id=78638

patch for 5.1.2, adding 6 additional compatibility symbols exported by libgd:
http://bugs.gentoo.org/attachment.cgi?id=78639&action=view

Reference Gentoo bug:
http://bugs.gentoo.org/show_bug.cgi?id=120908

Should be backported to 4.4.x as well, but that's really upstream job. ;)
 [2006-02-01 14:54 UTC] jorton@php.net 
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

Thanks a lot for the patch Jakub, committed to HEAD/5.1.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Thu Jan 02 12:01:29 2025 UTC