A PHP/Mapscript DSO Comment (and bug?)

[Bill Binko]

Hi everyone,

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() 
here:
http://mapserver.gis.umn.edu/data2/wilma/mapserver-users/0201/msg00187.html

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) :

http://primates.ximian.com/~federico/news-2005-03.html#19

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:

extension=php_mapscript.so
(and remove the dl() calls from your .php scripts)

That loads php_mapscript.so (and therefore libgdal.so) _once_ avoiding the 
problem.

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.

Bill