msyyin / mapfile.c

[Steve Lime]

This is probably an artifact of the string parsing. I don't think we should be closing files in
the load functions, rather just msLoadMap (or in the lexer when INCLUDEd files are popped
off the stack. I think it should be safe to remove the fclose block in the END case.

Steve
 

>>> On 6/28/2007 at 2:00 PM, in message <46840533.4030402 at pobox.com>, Frank
Warmerdam <warmerdam at POBOX.COM> wrote:
> Steve,
> 
> I was doing a bit of mapscript work today and found that things were
> crashing.  I tracked it down to fclose() being called on msyyin.  Digging
> a bit deeper it seems that the END processing in mapfile.c is closing
> msyyin but this code in msLoadMap() was also trying to close it.
> 
>    if(loadMapInternal(map) != MS_SUCCESS) {
>      msFreeMap(map);
>      msReleaseLock( TLOCK_PARSER );
>      fclose(msyyin);
>      return NULL;
>    }
> 
> In normal use I think it might not have been a serious error, but in
> my case a failed attempt to open a symbol file meant that msyyin was
> set to NULL.  Anyways, I've applied the following patch which I think
> is safe, and helped my case:
> 
>    http://trac.osgeo.org/mapserver/changeset/6243 
> 
> But it seems possible there are other aspects of the same problem that
> aren't addressed.  I presume this is related to the parse-from-string
> refactoring done recently?
> 
> Best regards,