FCGI on Windows with 6.0-beta4 problem

[jmckenna]

• I can reproduce this with only 6.0-beta4 (beta 1 to 3 work fine)
• initially reported on the mailing list:

When calling mapserv.exe using fcgi handler, it draw the map correctly
every OTHER call to mapserver, so once it draws the map, and if I click
again it throws the following error:

msLoadMap(): Unknown Identifier. Parsing error near(): line 3. 

[jmckenna]

• could it be one of the lexer changes in beta4?

[sdlime]

Depends on what's at line 3. The mapfile parsing shouldn't be conditional in any way, at least not CGI vs. Fast CGI. Can the mapfile that generates the error be posted, at least the top portion?

Steve

[jmckenna]

Some notes:

• this error ("msLoadMap(): Unknown Identifier. Parsing error near():") is the same confusing one that is displayed when users try to change variables the wrong way through CGI (i.e. the MapServer 5.0 changes)
• my test FCGI mapfile throws an error on line 6 with beta4 (every other map draw, as reported by the user):

#
# Start of map file
#
#
MAP
NAME "postgis"
STATUS ON
SIZE 400 300
SYMBOLSET "../etc/symbols.txt"
## ESPG:3978 extents:
EXTENT -2200000 -712631 3072800 3840000
UNITS METERS
SHAPEPATH "../data"
IMAGECOLOR 255 255 255
FONTSET "../etc/fonts.txt"

CONFIG "CPL_DEBUG" "ON"
CONFIG "MS_ERRORFILE" "/ms4w/tmp/ms_error.txt"
DEBUG 5

#
# Start of web interface definition
#
WEB
  IMAGEPATH "/ms4w/tmp/ms_tmp/" 
  IMAGEURL "/ms_tmp/"
  TEMPLATE "../htdocs/viewer-template.html"  
END

PROJECTION
  "init=epsg:3978"
END

#
# Start of legend
#
LEGEND
  KEYSIZE 18 12
  LABEL
    TYPE BITMAP
    SIZE MEDIUM
    COLOR 0 0 89
  END
  STATUS ON
  TEMPLATE "../htdocs/html-legend.html"  
END

#
# Start of layer definitions
#


LAYER
  NAME provinces
  TYPE POLYGON
  STATUS DEFAULT
  CONNECTIONTYPE postgis
  CONNECTION "host=127.0.0.1 user=postgres password=postgres port=5432 dbname=gmap"
  DATA "the_geom FROM province USING unique gid using srid=42304"
  PROJECTION
    "init=epsg:3978"
  END
  CLASS
    NAME "Land"
    STYLE
      COLOR 240 240 240
      OUTLINECOLOR 199 199 199
    END
  END
  PROCESSING "CLOSE_CONNECTION=DEFER"
END # layer



END # Map File

[aboudreault]

Things work well on Linux. Could you try to isolate the changeset that causes this bug? Try come back to r11391. Revisions r11392 and r11393 was related to lexer.

[jmckenna]

• I confirm that with r11391 FastCGI works as expected

[jmckenna]

• I confirm that the error occurs with r11392

[aboudreault]

Assefa and I fixed the bug in trunk. Jeff could you also test on your side and close the bug if everything looks good? Thanks.

Fixed and committed in r11480.

[jmckenna]

Another error. To clarify, I'll include my testing steps:

• to start fresh, I extract the 6.0-beta3 binaries
• execute 'mapserv -v'

  MapServer version 6.0.0-beta3 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG OUTPUT=KML SUPPORTS=PROJ S
  UPPORTS=AGG SUPPORTS=CAIRO SUPPORTS=FREETYPE SUPPORTS=ICONV SUPPORTS=FRIBIDI SUPPORTS=WMS_
  SERVER SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER SUPPORTS=WFS_CLIENT SUPPORTS=WCS_SERVER SUP
  PORTS=SOS_SERVER SUPPORTS=FASTCGI SUPPORTS=THREADS SUPPORTS=GEOS INPUT=JPEG INPUT=POSTGIS
  INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE
  

• restart Apache
• in my fastcgi viewer (my same small one that's I bet over 10 years old now) I reload the index page, and click "Initialize"
• map is generated and 'mapserv.exe' process is alive
• zoomin....map is generated and same 'mapserv.exe' process stays alive

• install trunk binaries
• execute 'mapserv -v'

  MapServer version 6.0.0-beta4 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG OUTPUT=KML SUPPORTS=PROJ S
  UPPORTS=AGG SUPPORTS=CAIRO SUPPORTS=FREETYPE SUPPORTS=ICONV SUPPORTS=FRIBIDI SUPPORTS=WMS_
  SERVER SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER SUPPORTS=WFS_CLIENT SUPPORTS=WCS_SERVER SUP
  PORTS=SOS_SERVER SUPPORTS=FASTCGI SUPPORTS=THREADS SUPPORTS=GEOS INPUT=JPEG INPUT=POSTGIS
  INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE
  

• restart Apache (ends the mapserv.exe process)
• reload fastcgi viewer, click "Initialize"
• map is generated. but the 'mapserv.exe' process does not stay alive
• (also, where the small legend image should be, there is an error message: "generateLegendTemplate(): Unable to access file. Error while reading template file.")
• zoomin...an error message is displayed: "loadMap(): Web application error. CGI variable "map" is not set."

[jmckenna]

I should also add:

• those same errors occur for both CGI and FCGI with trunk

Is that the expected behaviour for beta4?

[aboudreault]

I'm confused now... we are not talking about the same bug. I would like to be sure the initial issue is fixed or not with the latest trunk. You current might be another issue...

[jmckenna]

It seems the legend template error is a separate issue...if I comment that part out of my template my FastCGI viewer works as expected. Marking this fastcgi/windows issue as fixed.

[jmckenna]

for the record, the following legend template works with 5.x and upto beta3:

[leg_class_html opt_flag=12]
   <img src='[leg_icon]'> [leg_class_name]<br>
[/leg_class_html]

with trunk, I get the error: "generateLegendTemplate(): Unable to access file. Error while reading template file."

but if I modify the legend template file to the following it works with trunk:

[leg_class_html opt_flag=12]<img src='[leg_icon]'> [leg_class_name][/leg_class_html]

Bizarre!

[dmorissette]

FYI I created ticket #3814 about the template problem.

[worthlutz]

I am reopening this thinking that the problem is the same. Let me know if I should have started another ticket.

I think that I have the same parsing problem with MapScript reading the mapfile with ms_newNewMapObj($mapfile).

PHP Warning: ms_newMapObj(): [Mapserver Error]: loadProjection() Parsing error near ():line 10.......

line 9-11 = PROJECTION

"init=espg:26915"

END

if I include the following lines I get an additional parsing error: lines 5-6 CONFIG "MS_ERRORFILE" "/var/www/tmp/ms_errfile.txt" DEBUG 5

PHP Warning: ms_newMapObj(): [Mapserver Error]: getString(): Parsing error near (/var/www/tmp/ms_errfile.txt):(line 5)....

I'm waited until today to report this because it looked like the same problem and I hoped the fix would be in beta5 which I am using from ubuntuGIS repository.

This was working in beta3. Where should I begin testing? I can compile from trunk if necessary. I'm just not sure where to begin.

[aboudreault]

Let's create another ticket. I don't this this issue is related to this ticket.