INCLUDE is only parsed in the first mapfile

[johan.vandewauw@…]

When I use a script where different mapfiles are parsed, it seems like the
INCLUDE directive is not followed in the second mapfile and therefore it
generates an error.

The following script, with two valid mapfiles with include directives generates
the following error:
Script:
<?php
dl("php_mapscript.so");
$map1 = ms_newMapObj("/home/johan/rwanda/start.map");
$map2 = ms_newMapObj("/home/johan/rwanda/start3.map");
?>
Error:
Warning: [MapServer Error]: msLoadMap(): in /home/johan/public_html/test.php on
line 5

Warning: Failed to open map file /home/johan/rwanda/start3.map in
/home/johan/public_html/test.php on line 5

Some information on my mapscript version:
MapServer version 4.10.0 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG OUTPUT=WBMP
OUTPUT=SVG SUPPORTS=PROJ SUPPORTS=FREETYPE SUPPORTS=WMS_SERVER INPUT=EPPL7
INPUT=JPEG INPUT=POSTGIS INPUT=SHAPEFILE
PHP MapScript Version 	($Revision: 1.260 $ $Date: 2006/09/06 16:42:36 $)

-------------
The script also fails when using the cvs-version (same error):
MapServer version 4.99 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG OUTPUT=WBMP OUTPUT=SVG
SUPPORTS=PROJ SUPPORTS=FREETYPE SUPPORTS=WMS_SERVER INPUT=EPPL7 INPUT=JPEG
INPUT=POSTGIS INPUT=SHAPEFILE

[dmorissette]

This is probably not specific to PHP. Adding Steve to CC.

[sdlime]

That's a test case that I never tried. I'm not sure why it wouldn't work but I 
imagine there is some state information that needs to be reset between runs of 
the tokenizer. Switching component to the main C library...

Steve

[dmorissette]

Steve,

I was able to reproduce this with 5.0-beta2 and stepped through it in the debugger. It turns out that the issue seems to be caused by include_stack_ptr being left to a value of -1 after we hit EOF on the first mapfile.

Then the second parse starts with include_stack_ptr=-1 and never returns an "unexpected EOF" error.

The following patch seems to fix the issue, but I'm not sure if that's the best way to go. I think forcing include_stack_ptr=0 in some initialization code might be better so that in case of errors during parsing of an included file we still start up clean, but I didn't look for or find the right location to do it. I'll leave that to you.

--- maplexer.l  (revision 6436)
+++ maplexer.l  (working copy)
@@ -521,9 +521,10 @@
 <INITIAL>\n                                     { msyylineno++; }

 <INITIAL><<EOF>>                                {
-                                                  if( --include_stack_ptr < 0 )
+                                                  if( --include_stack_ptr < 0 ) {
+                                                    include_stack_ptr = 0;
                                                     return(EOF); /* end of main file */
-                                                  else {
+                                                  } else {
                                                     fclose(YY_CURRENT_BUFFER->yy_input_file);
                                                     msyy_delete_buffer( YY_CURRENT_BUFFER );
                                                     msyy_switch_to_buffer(include_stack[include_stack_ptr]);

[dmorissette]

Sorry, typo in the comment above. I meant:

"Then the second parse starts with include_stack_ptr=-1 and returns an "unexpected EOF" error."

[sdlime]

For a second I thought you had applied the patch, but I see haven't. A test I did here didn't show the issue, but I was using Perl MapScript. I think you're right though, better to initialize so I updated the lexer initialization code for file and string parsing to set the include_stack_ptr to 0. Can you guys confirm this fixes the issue?

For the record, my test script (everything expands correctly when saved):

#!/usr/bin/perl 

use mapscript;

$map1 = new mapscript::mapObj('test1.map') or die "Map 1: ". mapscript::msGetErrorString("\n");
$map2 = new mapscript::mapObj('test2.map') or die "Map 2: ". mapscript::msGetErrorString("\n");

print $map1->{name} ."\n";
print $map2->{name} ."\n";

$map1->save('test1.saved.map');
$map2->save('test2.saved.map');

[sdlime]

Marking as fixed for 5.0. Any reason to backport to 4.10? If so, we can reopen...

Steve

[dmorissette]

I have verified that the issue is gone with the fix in r6587.