[MS4W-Users] php-cgi crash with PostGIS

[Jeff McKenna]

Johan Forsman wrote:
> Hello All:
> 
> I do not know what the proper place to report this issue may be, but I thought I would start here hoping you can steer me in the right direction.
> 
> We have a small, internal to my organization, mapserver on WinXP, currently using MS4W 3.0 beta 6, with GeoMoose 2.0.1, primarily with shapefiles. The query function in GeoMoose is too slow for practical use for a particular point-data set and it was suggested by the developers to try the PostGIS system instead to speed up response time of the query.
> 
> I installed and configured PostgreSQL 8.4.0 and PostGIS 1.4 without issues, and I am using pgAdmin to help me along with configuration. I created a new database "sdwp" instead of using the default "postgres" database
> 
> I ingested the shapefile into PostGIS without issues and built an index on the field of interest to the query, then changed the mapfile to point to PostGIS instead of the shapefile.
> 
> Display of data from PostGIS works fine, but every time I execute the query there is a crash of php-cgi.exe on the server. The message on the server is the generic crash message from WinXP: CGI/FastCGI has encountered a problem and needs to close.
> 
> One strange thing is that the crash occurs in two separate modules depending on which dataset I query against.
> 
> Dataset A: Full dataset of ~180000 water wells.
> Dataset B: Subset of dataset A, ~20000 water wells.
> 
> Both are point data, and were ingested from individual shapefiles, and are currently stored as separate tables in the same PostGIS database, with separate indexes.
> 
> For dataset A the crash first occurs in gdal17dev.dll, then repeatedly in ntdll.dll shortly after clicking the "Don't Send" button (Remote Desktop control). I click the Don't Send button several times to dismiss the crash dialogs that pop up.
> 
> For dataset B the crash occurs only in ntdll.dll, and only once per query attempt.  
> 
> Once the crash has occurred I click the Don't Send button in the crash dialog on the server and one of two things will happen depending on the active dataset. 
> 
> Dataset A: 1) if there ARE NO matches for the query parameter GeoMoose immediately returns a message to that effect; 2) if there ARE matches to the query parameter GeoMoose returns the correct number of records.
> 
> Dataset B: 1) if there ARE NO matches for the query parameter GeoMoose immediately returns a message to that effect; 2) if there ARE  matches to the query parameter the server returns an Unhandled Request return, Internal Server Error message after a several-second delay.
> 
> There are more permutations than the above if I change the "turn highlight layer on" and/or "zoom to first hit" properties inside of the GeoMoose mapbook.
> 
> I don't even know where to start collecting evidence. Red herrings everywhere I suspect. This problem does not appear if I use shapefiles, but the query takes too long for practical use. PHP issue? GeoMoose issue? Mapserver issue? Windows issue? PostGIS issue? Yes to all or some of that?
> 
> There is an error shown in the PostGIS log, but I do not know if it is relevant (symptom or disease):
> 
> 2009-12-03 09:23:24 CSTLOG:  could not receive data from client: No connection could be made because the target machine actively refused it.	
> 2009-12-03 09:23:24 CSTLOG:  unexpected EOF on client connection	
> 
> What information do I need to collect, how do I collect it, and where should I send it to help with resolving this?
> 
> Thank you for your consideration.
> 

Johan,

Yes that does sound tricky.

I think you should try to take as many factors out of the equation as 
you can and still generate the error:

- remove GeoMoose, use a simple MapServer CGI viewer to execute query
- remove MS4W, try your tests with another Windows package like FWTools
- narrow the data down to the smallest subset that will still throw the 
error (one table with one record and one column, if possible)

One you've done some of those you could possibly package a test package 
(mapfile with one layer, shapefile that has only a few records and only 
the fields that you need for display, commands to import into postgis) 
and post here or to the other lists that you are trying.  If you're 
lucky someone will take time out of this/her day to run your test 
package (and your chances for this to occur greatly increase by how much 
time your spend beforehand in making the package the smallest you can).

-jeff



-- 
Jeff McKenna
FOSS4G Consulting and Training Services
http://www.gatewaygeomatics.com/