500 Internal Server Errors

[Roland Martin]

OK, this is probably yet another stupid query to which I should know the
answer... however, I'm on a roll here.

I've got an application which is intermittently (i.e. most of the time, but
not always) throwing a 500 Internal Server Error. The application is almost
a direct clone of another which does not exhibit the same error.

I've spent most of the afternoon trying to figure out why this might be, and
as far as I can tell, it's something to do with the PostGIS database which
holds most of the data. If I remove all the PostGIS layers, it seems to work
fine (although interestingly doesn't work if they're all in the map file but
turned off - does MapScript try to load the layers regardless?)

The database contains converted CAD (DWG) data with typically stupid
contents (meaningless fields, escape characters, etc). I wondered if it
might be to do with the sizes of the tables (>30 000 records in each), but
dissolving them doesn't seem to have made much difference. At the moment I'm
leaning towards thinking it may be because of the aforementioned escape
characters (looking down the tables, a number just contain the entry " which
might upset things; others start with an asterisk). However, some of the
tables causing the issue don't contain anything nearly as nasty.

The error is being thrown on loading the map; approximately 80-90% of the
time.

Also of interest may be the following gunk from the error logs:
[Wed Jul 12 16:29:11 2006] [error] [client x] Premature end of script
headers: php-cgi.exe, referer: http://x/lbia_dev/
[Wed Jul 12 16:51:08 2006] [error] [client x] Premature end of script
headers: php-cgi.exe, referer: http://x/lbia_dev/
(etc)

Anyone have any thoughts on this?

Ta,
Roland.


MS4W 2.0
MapServer 4.8.3
Chameleon for MS4W 2.4
PgSQL 8.1
etc 1.0


-- 
Please note my new email address. Use other addresses at your peril.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20060712/c8aabf3b/attachment.htm>