A PHP/Mapscript DSO Comment (and bug?)
bill at BINKO.NET
Wed Jan 18 23:55:35 EST 2006
Sorry for the cross-post, but I thought this should be in both list
archives (trying save future frustrations).
I recently went round and round trying to get PHP/Mapsript to display
rasters using GDAL on Linux when PHP was run as an Apache DSO. In
particular, my environment was
O/S: Mandrake 10.1
Apache Server version: 2.0.50 (running as Pre-Fork)
PHP 4.3.8 (built as CGI, CLI, and Apache DSO by default)
Mapserver CVS HEAD
GDAL CVS HEAD
In the process of whittling down the issue, I removed ECW, MrSID and many
other options from GDAL and Mapserver, so that in reality, I was running a
very stripped down version of both.
The error first showed up as occasional dropped HTTP requests (about 1 in
10 requests). The request would make it to the server, and PHP would
start, but nothing would be sent back to the client, and the Apache child
process would hang until Apache killed it (via the php max_execution_time
parameter) without any logging.
I got Apache running in debug mode and found that it was always the
_second_ PHP/Mapserver request to a particular Apache child process that
included a raster (GDAL) layer that was hanging. The reason it seemed
less often was the number of Apache children and my settings in that area.
Debugging php_mapscript.so when PHP is loaded as a DSO is a real
challenge(!). In fact, I have been unable to completely get into a clean
debugging environment for it. The reason is that all php_mapscript.so
calls are two "dlopen()" calls deep (first Apache loading mod_php and then
PHP loading php_mapscript.so).
Daniel has good instructions about how to get past the second dlopen()
However, before you can do that, you need to get mod_php loaded. I have
been fairly unsuccessful in setting breakpoints in a successfully running
process. However, when the process hung, I was able to load the symbols
for php_mapscript.so and libgdal.so by using this technique (Google is
your friend) :
What I found was that GDAL was getting hung in the
_XTIFFDefaultDirectory() method. Sometimes a floating point or divide by
zero error would occur in that place as well. For the GDAL developers, it
may be worthwhile to look at the type safety of the xtiffFieldInfo array,
but I don't have enough to really put my finger on the problem.
Luckily (for me), I have found a way around this for the moment. Don't
think I'm not interested in finding the bug: I am! However, I have to
make progress on other items, and I simply need to pass the lead on this
to someone else (if anyone cares).
The trick is to simply pre-load php_mapscript.so in the php.ini file with
a line like this:
(and remove the dl() calls from your .php scripts)
That loads php_mapscript.so (and therefore libgdal.so) _once_ avoiding the
If anyone has similar issues and wants to work with me on this, please let
me know. In the mean time, I'm not sure if this is a GDAL bug or a
Mapserver bug, so I'm not going to create either until I get some
feedback. I just wanted to document this while I had the chance.
More information about the mapserver-dev