internal server error on GetMap request

[bartvde@…]

Using Mapserver 4.8.1 this all works fine. But with 4.8.3 Mapserver crashes and
produces an internal server error.

I will attach the shapefile used, the MAP file used for the testcase, and the
symbolset as well.

[bartvde@…]

shapefile used in tgz format

[bartvde@…]

MAP file used

[bartvde@…]

symbols subdirectory used in tgz format

[bartvde@…]

The WMS request used btw is:

http://145.50.148.45:8081/cgi-bin/mapserv483?map=/data/OGC_UMN_services/bugtest.map&service=WMS&version=1.1.1&request=GetMap&SRS=EPSG%3A28992&BBOX=146895.58545416163,459395.5854541616,153104.41454583837,465604.4145458384&width=320&height=320&layers=AAA132&styles=&format=image/png&exceptions=application/vnd.ogc.se_inimage

[bartvde@…]

I have been able to reproduce this on another RHE 3 machine, but not on a
Windows machine.

I also found out the following class is the cause:

     CLASS
       EXPRESSION /5023/
       NAME "loofbos"
       STYLE
         COLOR 146 174 47
         SYMBOL "loofbos"
         OUTLINECOLOR 110 110 110
         SIZE 1
       END
     END

If I comment out SIZE, it does not crash.

Loofbos is a PIXMAP symbol:

SYMBOL
  NAME 'loofbos'
  TYPE pixmap
  IMAGE "/data/OGC_UMN_services/symbols/loofbos.png"
  TRANSPARENT 0
END

[bartvde@…]

It only occurs if size is <= 1.

There have been some changes in mapsymbol.c for version 4.8.3 .......

Adding Steve to the cc as he might know something about this.

[bartvde@…]

This is the output from gdb:

(gdb) set args
"QUERY_STRING=map=/data/OGC_UMN_services/basispakket_topografie.map&service=WMS&version=1.1.1&request=GetMap&SRS=EPSG%3A28992&BBOX=146895.58545416163,459395.5854541616,153104.41454583837,465604.4145458384&width=320&height=320&layers=AAA132&styles=&format=image/png&exceptions=application/vnd.ogc.se_inimage"
(gdb) run
Starting program: /data/src/redhat/BUILD/mapserver-4.8.3/mapserv
"QUERY_STRING=map=/data/OGC_UMN_services/basispakket_topografie.map&service=WMS&version=1.1.1&request=GetMap&SRS=EPSG%3A28992&BBOX=146895.58545416163,459395.5854541616,153104.41454583837,465604.4145458384&width=320&height=320&layers=AAA132&styles=&format=image/png&exceptions=application/vnd.ogc.se_inimage"
Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 19627)]

Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 16384 (LWP 19627)]
0x003d1b5d in gdImageSetPixel () from /usr/lib/libgd.so.2

[sdlime]

Probably mine (changing component) so I'll take a look as soon as I can...

Steve

[bartvde@…]

Steve, any news on this one already?

[sdlime]

Bart: I've not been able to recreate the error on my development machine. I
built a simple test case below. Can you see if it runs on your end? I tried
various sizes and all worked as expected with 4.8.3 and CVS head. 

BTW I did notice that you have to define a dummy color to get PIXMAP fills to
work. I removed that restriction for POLYGON and CIRCLE layers in CVS head...

Steve

MAP
  NAME 'bug1776'
  SIZE 860 590
  EXTENT 0 0 860 590

  IMAGETYPE PNG
  IMAGECOLOR 255 255 255

  SYMBOL
    NAME 'loofbos'
    TYPE pixmap
    IMAGE "symbols/loofbos.png"
    TRANSPARENT 0
  END

  LAYER
    NAME 'test'
    TYPE POLYGON
    STATUS TRUE
    FEATURE
      POINTS 50 50 400 200 400 400 50 50 END
    END
    CLASS
       NAME "loofbos"
       STYLE
         COLOR 255 0 0 # DUMMY COLOR
         SYMBOL 'loofbos'
         SIZE 1
         OUTLINECOLOR 0 0 0
       END
     END
  END
END

[bartvde@…]

Hi Steve,

thanks for looking at this, your testcase also crashes in our environment.

Could this have to do with the GD patch you posted in Feb 2006? We did not apply
that yet.

Anyway, here is some more gdb output:

(gdb) run shp2img -m /data/OGC_UMN_services/bug1776.map
Starting program: /data/src/redhat/BUILD/mapserver-4.8.3/shp2img shp2img -m
/data/OGC_UMN_services/bug1776.map
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 4694)]

Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 16384 (LWP 4694)]
0x00715b5d in gdImageSetPixel () from /usr/lib/libgd.so.2
(gdb) bt
#0  0x00715b5d in gdImageSetPixel () from /usr/lib/libgd.so.2
#1  0x0807a0ae in imageScanline (im=0x9562680, x1=400, x2=400, y=190, c=-5) at
mapgd.c:828
#2  0x0807af75 in imageFilledPolygon (im=0x9562680, p=0xbfff44e0, c=-5,
offsetx=0, offsety=0) at mapgd.c:1122
#3  0x0808064c in msDrawShadeSymbolGD (symbolset=0xb74ec024, img=0x9562680,
p=0xbfff44e0, style=0x9559790, scalefactor=1)
    at mapgd.c:2216
#4  0x08078369 in msDrawShadeSymbol (symbolset=0xb74ec024, image=0x955bff0,
p=0xbfff44e0, style=0x9559790,
    scalefactor=1.4923856930813753e-263) at mapdraw.c:1814
#5  0x08076e62 in msDrawShape (map=0xb74ec008, layer=0xb74b9008,
shape=0xbfff44e0, image=0x955bff0, style=-1)
    at mapdraw.c:1632
#6  0x0807515c in msDrawVectorLayer (map=0xb74ec008, layer=0xb74b9008,
image=0x955bff0) at mapdraw.c:1001
#7  0x08074bc2 in msDrawLayer (map=0xb74ec008, layer=0xb74b9008,
image=0x955bff0) at mapdraw.c:843
#8  0x08074213 in msDrawMap (map=0xb74ec008) at mapdraw.c:504
#9  0x0804fbfc in main (argc=4, argv=0xbfffc434) at shp2img.c:229

[bartvde@…]

Steve, are you testing with 483 or with CVS head?

After applying the GD patch the arithmetic exception now occurs somewhere else
in GD:

Starting program: /data/src/redhat/BUILD/mapserver-4.8.3/shp2img shp2img -m
/data/OGC_UMN_services/bug1776.map
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 8908)]

Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 16384 (LWP 8908)]
0x00b9edda in gdImageTileApply (im=0x9c27680, x=400, y=190) at gd.c:875
875       srcy = y % gdImageSY (im->tile);
(gdb) bt
#0  0x00b9edda in gdImageTileApply (im=0x9c27680, x=400, y=190) at gd.c:875
#1  0x0807a0ae in imageScanline (im=0x9c27680, x1=400, x2=400, y=190, c=-5) at
mapgd.c:828
#2  0x0807af75 in imageFilledPolygon (im=0x9c27680, p=0xbfff2f40, c=-5,
offsetx=0, offsety=0) at mapgd.c:1122
#3  0x0808064c in msDrawShadeSymbolGD (symbolset=0xb74e9024, img=0x9c27680,
p=0xbfff2f40, style=0x9c1e790, scalefactor=1)
    at mapgd.c:2216
#4  0x08078369 in msDrawShadeSymbol (symbolset=0xb74e9024, image=0x9c20ff0,
p=0xbfff2f40, style=0x9c1e790,
    scalefactor=1.6760434867583726e-261) at mapdraw.c:1814
#5  0x08076e62 in msDrawShape (map=0xb74e9008, layer=0xb74b6008,
shape=0xbfff2f40, image=0x9c20ff0, style=-1)
    at mapdraw.c:1632
#6  0x0807515c in msDrawVectorLayer (map=0xb74e9008, layer=0xb74b6008,
image=0x9c20ff0) at mapdraw.c:1001
#7  0x08074bc2 in msDrawLayer (map=0xb74e9008, layer=0xb74b6008,
image=0x9c20ff0) at mapdraw.c:843
#8  0x08074213 in msDrawMap (map=0xb74e9008) at mapdraw.c:504
#9  0x0804fbfc in main (argc=4, argv=0xbfffae94) at shp2img.c:229

[sdlime]

I'm pretty sure I've got that patch applied. I can try installing GD again 
without it and trying again. What version of GD are you using?

I've tested against both CVS head and 4.8.3...

Steve

[bartvde@…]

Hi Steve, we're using latest GD (2.0.33).

[bartvde@…]

I just tried this on a Fedora Core 5 (FC5) system using the latest FGS
(Mapserver 483 version) and get the exact same problem:

[root@localhost bin]# ./shp2img -m bug1776/bug1776.map
Floating point exception

[dmorissette]

"Floating point exception" rungs a bell. I seem to remember that we got this
problem in the past because GDAL was built with OGDI which carries its own copy
of PROJ4.

Guillaume: Does the latest FGS include OGDI? Could this be the problem?

[dmorissette]

See this post about the PROJ4 vs OGDI issue (copied below):

http://lists.maptools.org/pipermail/foss-gis-suite/2005-August/000298.html

I guess the next question for Guillaume is: if OGDI is included into GDAL, did
you built it using --with-proj as Frank suggested in that email?

Copy of the email linked above:

[FGS] fgsdev and missing packages
Guillaume Dallaire gdallaire at dmsolutions.ca
Tue Aug 9 07:58:43 EDT 2005


On Thu, 2005-08-04 at 15:52 -0400, Frank Warmerdam wrote:
> On 8/4/05, Guillaume Dallaire <gdallaire at dmsolutions.ca> wrote:
> > If I remember well, I had a "strange" issue with OGDI + GDAL : I got
> > "Floating point exception" when running mapserver with GDAL built
> > against the --with-ogdi= option.
> > 
> > I guess I should retry to build GDAL with OGDI support and see if it
> > works now. (I think I got this issue with GDAL 1.2.5)
> 
> Guillaume,
> 
> This sounds like what often happens if you have an old version
> of PROJ from within the ogdi tree getting built in.  You need to take
> particular care to use --with-proj when configuring OGDI or else
> it will build in a copy of PROJ that conflicts with modern ones. 

I tested a new GDAL FGS build (1.2.6) with OGDI (3.1.4) support and I
got no "Floating point exception" error. PROJ version is 4.4.8.

I uploaded this new build (fgs-gdal-base-1.2.6-linux-i386.tar.gz) on
maptools.org

To update a FGS runtime, run:

$ fgs install gdal-base:1.2.6 http://www.maptools.org/dl/fgs/modules

or 

$ fgs force-install gdal-base:1.2.6
http://www.maptools.org/dl/fgs/modules

is you already have GDAL 1.2.6.

Guillaume

[bartvde@…]

After a long search this is a duplicate of bug 1735 which has been fixed by
Daniel just after the 4.8.3 release.

We have applied that patch and now all is okay.

*** This bug has been marked as a duplicate of 1735 ***

[bartvde@…]

Steve, Daniel,

we are still running into FP exceptions here. It seems to depend on the PIXMAP
symbol. I'll attach a symbol which fails when using a SIZE of exactly 1. We are
using Mapserver 4.8.4.

[bart@hades OGC_UMN_services]$ shp2img -m bug1776.map -o test.png
Floating point exception

This is the test MAP file which fails with shp2img:

MAP
  NAME 'bug1776'
  SIZE 860 590
  EXTENT 0 0 860 590

  IMAGETYPE PNG
  IMAGECOLOR 255 255 255

  SYMBOL
    NAME 'loofbos'
    TYPE pixmap
    IMAGE "symbols/populieren.png"
    TRANSPARENT 0
  END

  LAYER
    NAME 'test'
    TYPE POLYGON
    STATUS TRUE
    FEATURE
      POINTS 50 50 400 200 400 400 50 50 END
    END
    CLASS
       NAME "loofbos"
       STYLE
         COLOR 255 0 0 # DUMMY COLOR
         SYMBOL 'loofbos'
         SIZE 1
         OUTLINECOLOR 0 0 0
       END
     END
  END
END

[bartvde@…]

Btw the symbol is already present in the symbols attachment.

[sdlime]

Reopening I guess...

Steve

[bartvde@…]

populieren.png is a pixmap symbol which has a height:width ratio of
approximately 2:1.

Apparently when using SIZE 1, the height is set to 1 by Mapserver, and the width
is approximately 0.5 which then becomes 0 somehow .... hence the exception.

We'll try and investigate some more.

[bartvde@…]

Hi Steve,

apparently something goes wrong with floating points less than 1 being changed
into integer (since createBrush uses an integer), so the integer has a value of
0 in our test case. Are you able to look into this and see if this can be
reproduced?

We could patch the problem using the following:

in mapgd.c:

static gdImagePtr createBrush(gdImagePtr img, int width, int height, styleObj
*style, int *fgcolor, int *bgcolor)
{
  gdImagePtr brush;

  /* quick fix */
  if (width == 0) width = 1;
  if (height == 0) height = 1;

  ....
}

createBrush is called from msDrawShadeSymbolGD:

    if(d == 1) { /* use symbol->img "as is", no scaling, this should be the most
common case */
      gdImageSetTile(img, symbol->img);
    } else {
      tile = createBrush(img, d*symbol->sizex, d*symbol->sizey, style, &tile_fc,
&tile_bc);
      gdImageCopyResampled(tile, symbol->img, 0, 0, 0, 0, tile->sx, tile->sy,
symbol->img->sx, symbol->img->sy);
      gdImageSetTile(img, tile);
    }

[bartvde@…]

Setting target to 4.10

[sdlime]

Bart, can you do me a favor and try something. I want to make sure this isn't a
rounding issue. If possible. Edit map.h and remove all the MS_NINT crap except
for the last version- the somewhat readable C macro. Recompile and try it.

I want to see if that might be the issue before spending a bunch of time
tracking it down.

Steve

[bartvde@…]

Hi Steve,

I tried that, but I still get the floating point exception.

I only kept this one:
#  define MS_NINT(x)      ((x) >= 0.0 ? ((long) ((x)+.5)) : ((long) ((x)-.5)))

and deleted the others.

Bart

[sdlime]

Argh... This will be a beta2 fix then.

Steve

[sdlime]

I applied Bart's suggested fix to createBrush. That will guard against
inappropriate width and height values being passed in. 

We should be rounding. Right now it's a double => int conversion which is how .5
becomes 0. That said, on  Linux the rounding problems we saw elsewhere would
continue to be an issue since the assembler rounding or lrint code round to
nearest even integer (.5 becomes 0).

Steve

[hobu]

Can this bug be closed now?