Opened 20 years ago

Closed 20 years ago

Last modified 20 years ago

#601 closed defect (fixed)

SLD parsing fails on Windows

Reported by: assefa Owned by: assefa
Priority: high Milestone: 4.2 release
Component: WMS Server Version: 4.1
Severity: normal Keywords:
Cc: bartvde@…


When we use only one NamedLayer with one Rule, everything works fine. When
we use 2 NamedLayer elements, the original map gets drawn. We also tried
copying the LAYER in the MAP file, so that we did not reference the same
NamedLayer twice. This does not make any difference, the layer is rendered
without any Filter/SLD applied.

The reason we want to use this kind of SLD is to have a selection drawn on
top of another selection, and have the result in one image.

Any info appreciated.

<StyledLayerDescriptor version="1.0.0">
                     <CssParameter name="stroke">#ffff00</CssParameter>
                     <CssParameter name="stroke-width">10.0</CssParameter>
                     <CssParameter name="stroke">#0000ff</CssParameter>
                     <CssParameter name="stroke-width">2.0</CssParameter>

AY :

 I have tried to debug the problem this morning but was not successful. I can 
reproduce this on a windows machine but the the same setting works on a Linux 
setup. What is even worst was that on Windows, the request works when I am in 
the debugger.  I could not really pin point where was the problem but It seems 
that the inital parsing of the XML is the probelm (the XML seems to be valid 
but the parser returns an error).

Attachments (1) (454 bytes ) - added by bartvde@… 20 years ago.
SLD XML document which fails in Mapserver

Download all attachments as: .zip

Change History (21)

comment:1 by bartvde@…, 20 years ago

Cc: bartvde@… added

comment:2 by assefa, 20 years ago


 Can you check if this happens with the latest build from I was 
trying to debug this today and realized that I can't reproduce it any more.

comment:3 by dmorissette, 20 years ago

Any update on this Bart? Can you still reproduce the problem?

comment:4 by bartvde@…, 20 years ago

I just checked and I got the same error with the new binary.

[Wed Apr 14 09:51:48 2004] [error] [client] Wed Apr 14 09:51:48
2004 - : WMS server error. Invalid SLD document

A colleague of mine found out this is caused by the line separator.
If I save the same XML document in Textpad in the UNIX file format, then there
is no problem.

I do get a new error in the Apache error log when using this SLD:
[Wed Apr 14 09:56:09 2004] [error] [client] Wed Apr 14 09:56:09
2004 - msAddImageSymbol(): Unable to access file. Error opening image file

comment:5 by dmorissette, 20 years ago

Cc: warmerdam@… added
Milestone: 4.2 release
Can you please attach the XML document that causes the crash?  ZIP it so that
the linefeeds are not converted when we download it.

BTW, bug 567 also reported an issue with linefeeds in parsing of XML post data
but we didn't have a testcase in that bug, perhaps that's related to the same
parser issue?

by bartvde@…, 20 years ago

Attachment: added

SLD XML document which fails in Mapserver

comment:6 by dmorissette, 20 years ago

Assefa, can you look at this before Friday or should I take it?

comment:7 by assefa, 20 years ago

Owner: changed from mapserverbugs to assefa
Lookin at it.

comment:8 by dmorissette, 20 years ago

Cc: morissette@… added

comment:9 by assefa, 20 years ago

Update on this :

 The error message msAddImageSymbol() is a "normal" error message : It is 
triggered in the sld when for example a line style with a certain width is
 created :

          COLOR 255 255 0
        MAXSIZE 100
        MINSIZE 1
        SIZE 10
        SYMBOL "sld_line_symbol"

 The sld_line_symbol is an inline symbol added by the sld when needed.
 All lines try to use the sld_line_symbol so the first call is to check if this
symbol exists and this check uses the function msGetSymbolIndex that generates
the message. I could change the code to look myself into the array of symbols if
this is a big deal.

 I am still trying to reproduce this xml parsing issue on windows.


comment:10 by dmorissette, 20 years ago

dependson: 612
Status: newassigned
The error message is definitely misleading.  The msGetSymbolIndex() problem has
been raised by Sean before and would be solved if we fixed bug 612.  I'll work
on bug 612 tonight then.

comment:11 by bartvde@…, 20 years ago

Assefa, I have set up a testcase here on our Windows Apache webserver.

SLD with Windows line feeds:

GetMap request associated with 1:

2) SLD with Unix linefeeds:

GetMap request associated with 2:

comment:12 by fwarmerdam, 20 years ago

I have run xmlreformat (a thin wrapper around CPLParseXMLString()) on the
SLD documents and had no problem parsing either one. 

I will try again on win32 to see if that is an issue. 

comment:13 by fwarmerdam, 20 years ago

OK, I haven't reproduced the problem myself, but looking at this code in
mapogcsld.c/msSLDApplySLDURL() I think I see the problem:

            if ((fp = fopen(pszSLDTmpFile, "r")) != NULL)
                int   nBufsize=0;
                fseek(fp, 0, SEEK_END);
                nBufsize = ftell(fp);
                pszSLDbuf = (char*)malloc((nBufsize+1)*sizeof(char));
                fread(pszSLDbuf, 1, nBufsize, fp);
                pszSLDbuf[nBufsize] = '\0';

The file is opened with default file type.  On win32 it will be opened in
text mode.  But ftell() is not reliable on text streams.  I imagine the
nBufsize is wrong (too long or too short) and the resulting buffer
of data is either clipped or includes a bunch of binary junk. 

I would suggest opening the file in binary mode (use a mode of "rb" instead 
of "r").  In binary mode the length calculation should work fine.  The
CPL MiniXML code should have no problem reading linefeeds in unix or
PC format so we don't need the file access to do it for us. 

Assefa ... I'll bounce this back to you to make the change and test it. 

comment:14 by assefa, 20 years ago

Resolution: fixed
Status: assignedclosed
Thanks Frank. That did solve the problem on my case. I am also updating the
mapcontext.c file that would have a similar problem.

Bart, do you need a new windows binaries. If not this fix will be part of the
4.2 release.

 Marking bug as fixed.

comment:15 by dmorissette, 20 years ago

I have committed a fix for bug 612 in which msGetSymbolIndex() was modified to
be able to avoid the call to msAddImageSymbol().  I modified all the mapogcsld.c
code to pass try_addimage_if_notfound=MS_FALSE. I'm sure that was the right
thing to do for most places that called msGetSymbolIndex(), but one or two calls
were not as obvious.  

Assefa, can you please review all calls to msGetSymbolIndex() in mapogcsld.c to
make sure they do the right thing.  Also, could someone please confirm that the
error about msAddImageSymbol() is gone with that new version?

comment:16 by assefa, 20 years ago

mapogcsld.c seems to be correct, test files seems to work properly.

comment:17 by bartvde@…, 20 years ago

4.2 will be fine (we have a workaround by saving the files as Unix).

comment:18 by dmorissette, 20 years ago

I'm not sure to understand your comment Bart.  Are you saying that there are
still problems in 4.2 and that you still need the workaround?

comment:19 by bartvde@…, 20 years ago

Daniel, I was referring to Assefa's question:

"Bart, do you need a new windows binaries. If not this fix will be part of the
4.2 release."

With my answer I meant that I am okay with waiting for the 4.2 release binaries 
and that Assefa does not have to provide a new binary.

comment:20 by dmorissette, 20 years ago

Ah... makes more sense now. sorry for the noise.
Note: See TracTickets for help on using tickets.