[mapserver-users] mapserver.log (was Re: malformed PNGs)

Wed Aug 14 20:48:44 PDT 2002

1. That's not a perl/mapscript specific feature. It'll work with the CGI version. The feature was added specifically for development/debugging reasons and wasn't documented. Guess it should be, but as pointed out in question 2 it tends to cause more problems for general users than in solves. BTW Do folks know about using environment variable names for mapfile names? Probably not, but it works lovely. Guess we need to add that in the docs someplace.

2. Good point, but at the time (and currently) it meant something to me. That code is relatively ancient, actually predates public distribution. 3.7 already notes the filename and I've changed the error message to be even more non-cryptic this evening. But hey, at least you actually get an error message instead of a core dump.

3. Blame SWIG, it wrote the Perl module. Re-SWIGing with a newer version of SWIG than in used with the distributions might help. Contact me off list if you'd like to try that.

4. Dunno. SWIG tends to lag behind versions Perl just a bit. If the Perl developers left the low level C interface the same then there should be no problem. I don't think I'd go there unless you had a real compelling reason to do so.

5. The problem with mod_perl is not so much MapScript as it is SWIG. Modules produced with version 1.1x of SWIG are incompatible with mod_perl. Changes to SWIG in the 1.3x series are supposed to have fixed those issues. I've not tried it myself though.

BTW Version 3.7 will be released with MapScript being compiled against the more recent versions of SWIG. 

Hope this helps.

Steve

3.

Stephen Lime
Data & Applications Manager

Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155
651-297-2937
>>> Puneet Kishor <pkishor at geoanalytics.com> 08/14/02 20:19 PM >>>
Thanks Lowell, Steve, and Steve.

That is now clear. Which brings me to a few random issues --

1. if Lowell hadn't told me about $ENV{MS_ERRORFILE}, how could I have 
found that out? I think I have peered into all the Perl/Mapscript docs 
there are but didn't see this. Maybe I missed it, but maybe it isn't 
there, or is not obvious. In which case, we (I myself) need to do 
Perl/Mapscript a service and really make a nice Perl how-to. I frankly 
love Perl over all other scripting stuff, but find PHP stuff to be 
generally better documented. For example, it was not obvious trying to 
figure out the changes from 3.5->3.6.1. The mapquakes.pl script is 
great, but it is hardly adequate. I have finally got my Perl/Mapscript 
application behaving and will be releasing it a la gMap (I am planning 
to call it pMap for the heck of it! so don't be taking away the name 
from me!!), but we really need more.

2. SDL says (and so did SW) --

> The error in your log files is completely benign and can be safely 
> ignored. It just says that
> there is no spatial index associated with a particular shapefile, which 
> is perfectly legal...

well, then why doesn't the error say just that? I mean, instead of

	Tue Aug 13 23:10:51 2002 - msSearchDiskTree(): Unable to access file.
	Tue Aug 13 23:10:51 2002 - msSearchDiskTree(): Unable to access file.

it could just as well have been

	Tue Aug 13 23:10:51 2002 - msSearchDiskTree(): no spatial index 
associated with hydro.shp
	Tue Aug 13 23:10:51 2002 - msSearchDiskTree(): no spatial index 
associated with roads.shp

is there a good reason why error messages have to be cryptic? That is 
one great turn-off I had with ESRI software -- I mean, anytime any of 
their products version 1.x onward croaked, it said there was a "Fatal 
error, segmentation fault". I couldn't even pick my nose with that info!

3. I am getting a boatload of errors in my Apache error_log like so

[Wed Aug 14 08:44:07 2002] index.pl:    (in cleanup) Not a HASH 
reference at /Library/Perl/darwin/mapscript.pm line 2415 during global 
destruction.
[Wed Aug 14 08:44:07 2002] index.pl:    (in cleanup) Not a HASH 
reference at /Library/Perl/darwin/mapscript.pm line 1144 during global 
destruction.
[Wed Aug 14 08:44:07 2002] index.pl: Use of uninitialized value in 
exists at /Library/Perl/darwin/mapscript.pm line 2417 during global 
destruction.

Things seem to be working, so are the above also benign, so to say? I am 
not using mod_perl any more... this with Perl 5.6.1 with Apache 1.3.26 
on OS X. However, I have had the same error on Win2k, Perl 5.6.1, Apache 
2.0.39.

4. What is the compatibility of Perl/Mapscript with Perl 5.8.0? If it is 
not, I won't even worry about upgrading Perl, but would like to know.

5. Not too long ago we narrowed a bunch of errors to mod_perl use 
(methinks they were like those mentioned above in #3) that actually 
crashed the program, in that, the map didn't draw (the dreaded "Internal 
Server Error has occurred..."). What is the future possibility of 
Perl/Mapscript co-existing with mod_perl?

I know these are many questions, and I don't mean to sound over-eager. 
My main interest is in better (best possible) debugging, so answers to 
#2 and #3 would be very satisfying. As the great Lowell.Filak wrote on 
Wednesday, August 14, 2002, at 06:17  AM,: "Error messages are a 
terrible thing not to have."

pk/

>
> Steve
>
>>>> Puneet Kishor <pkishor at GeoAnalytics.com> 08/13/02 11:23PM >>>
> slowly slowly we progress...
>
> I am finally able to get mapserver.log to generate. I added the $ENV
> line immediately after the shebang line, and chown-ed the tmp directory
> to nobody. Works!
>
> ok. so I am now watching the log file with
>
> 	tail -f ...
>
> and I see the following...
>
> 	Tue Aug 13 23:10:51 2002 - msSearchDiskTree(): Unable to access file.
> 	Tue Aug 13 23:10:51 2002 - msSearchDiskTree(): Unable to access file.
> 	Tue Aug 13 23:11:46 2002 - msSearchDiskTree(): Unable to access file.
> 	Tue Aug 13 23:11:46 2002 - msSearchDiskTree(): Unable to access file.
>
> the problem is, I can't figure out what is causing the above error. My
> map file is fairly complicated, and as far as I can see, everything is
> being drawn the way I want it. So, what is it that is inaccessible? Is
> there a way the log can append (or prefix) the line number in the source
> that caused the error? Is there a way to determine where it is failing?
>
> Tia as always.
>
> pk/
>
>
> On Tuesday, August 13, 2002, at 11:58  AM, Lowell.Filak wrote:
>
>> The LOG is for logging requests whereas the ERRORFILE is for logging
>> errors. Does the user that the webserver is running as have permission
>> to
>> write to /var/www/html/bims/tmp/mapserver.log or alternately
>> /var/www/html/bims/tmp/error.log? There should at least be a log file
>> with
>> a record of the request.
>> Lowell
>>
>> On Tue, 13 Aug 2002, Puneet Kishor wrote:
>>
>>> well, I already had a line in my map file like so...
>>>
>>>  	LOG "/var/www/html/bims/tmp/mapserver.log"
>>>
>>> I added
>>>
>>> 	$ENV{MS_ERRORFILE} = "/var/www/html/bims/tmp/mapserver.log"
>>>
>>> to my perl script. I don't get any log files written out. Do I have to
>> set
>>> this ENV variable in the Apache conf file? or at the shell prompt
>> using
>>> setenv?
>>>
>>> Tia,
>>>
>>> pk/
>>>
>