within the OUTPUTFORMAT directive within the MAP directive in my map file, if
I have a reference to a palette file that does not exist:
FORMATOPTION
"PALETTE=/ext/home/rich/wrk/mapserver/freenavi/zoom0-5.palettefoo"
---
[EMAIL PROTECTED] mapserver-5.0.0-5 12:57:43]$ ls
/ext/home/rich/wrk/mapserver/freenavi/zoom0-5.palettefoo
ls: /ext/home/rich/wrk/mapserver/freenavi/zoom0-5.palettefoo: No such file
or directory
---
this causes mapserv to segfault:
---
[EMAIL PROTECTED] mapserver-5.0.0-5 12:15:34]$ LD_LIBRARY_PATH=/usr/local/lib
REQUEST_METHOD=GET
QUERY_STRING="map=/ext/home/rich/wrk/mapserver/freenavi/zoom0-5.rich.map&mode=map"
/ext/home/rich/wrk/mapserver/mapserver-5.0.0-5/mapserv
Content-type: image/png; mode=24bit
Segmentation fault
---
i am hacking things a bit here to run mapserv directly, bypassing the normal
CGI path, so that i can run this in gdb. if i run this normally through
apache2, i get a 500 error.
this is not the first time that i have had a typo in a filename cause a 500
error. i'm pretty sure i've seen it for something other than the palette
file, but this is the instance that i'm choosing to track down further here.
running via gdb, i can track this down to mapdg.c
at line 3590, the palette format option gets read:
---
int msSaveImageGDCtx( gdImagePtr img, gdIOCtx *ctx, outputFormatObj *format)
/* ... */
const char *palette = msGetOutputFormatOption( format, "PALETTE",
"palette.txt");
gdPImg = msImageCreateWithPaletteGD(img, palette, gdImageSX(img),
gdImageSY(img));
---
and at line 3441, the palette file itself gets read:
---
static gdImagePtr msImageCreateWithPaletteGD( gdImagePtr img24, const char
*palette, int sx, int sy)
{
/* ... */
if(!palette) return NULL;
/* ... */
stream = fopen(palette, "r");
if(!stream) {
msSetError(MS_IOERR, "Error opening palette file %s.",
"msImageCreateWithPaletteGD()", palette);
return NULL;
}
---
looks good enough to me, if the fopen() call fails, then an error should be
returned.
yet when i run it, that's not what happens. i can see the format option
being
read properly:
(gdb) p format
$14 = (outputFormatObj *) 0x81052b8
(gdb) p format->formatoptions[1]
$15 = 0x8105228
"PALETTE=/ext/home/rich/wrk/mapserver/freenavi/zoom0-5.palettefoo"
(gdb) n
(gdb) p palette
$16 = 0x8105230 "/ext/home/rich/wrk/mapserver/freenavi/zoom0-5.palettefoo"
and passed to the routine:
(gdb) step
msImageCreateWithPaletteGD (img24=0x0, palette=0x8105230
"/ext/home/rich/wrk/mapserver/freenavi/zoom0-5.palettefoo", sx=1600,
sy=1200) at mapgd.c:3435
(gdb) p palette
$17 = 0x8105230 "/ext/home/rich/wrk/mapserver/freenavi/zoom0-5.palettefoo"
but what happens is that fopen() does NOT return NULL. it does return a
non-null FILE*, just one that happens to be bogus:
(gdb) p stream
$18 = (FILE *) 0x4b0
(gdb) p *stream
Cannot access memory at address 0x4b0
which then ultimately causes a segfault some time later (within the GD
library
code).
fopen(3) claims that a NULL should be returned on error:
RETURN VALUE
Upon successful completion fopen, fdopen and freopen return a FILE
pointer. Otherwise, NULL is returned and the global variable errno
is
set to indicate the error.
i was a bit stumped at this point, finding it very hard to believe that
there's a bug in fopen.
and if i write a simple test case:
--- begin ---
#include <stdio.h>
#include <stdlib.h>
int
main (int argc, char **argv)
{
const char *palette =
"/ext/home/rich/wrk/mapserver/freenavi/zoom0-5.palettefoo";
FILE *stream=NULL;
stream = fopen(palette, "r");
if(!stream) {
fprintf(stderr, "Error opening palette file %s.\n", palette);
} else {
fprintf(stdout, "Success at opening palette file %s.\n", palette);
fclose(stream);
}
exit (0);
}
--- end ---
when i run it, i properly get an error:
[EMAIL PROTECTED] tmp 13:02:03]$ gcc -o fopen-test fopen-test.c
[EMAIL PROTECTED] tmp 13:02:14]$ ./fopen-test
Error opening palette file
/ext/home/rich/wrk/mapserver/freenavi/zoom0-5.palettefoo.
[EMAIL PROTECTED] tmp 13:02:16]$
this isn't any kind of show stopper for me, since the short answer is to
just
not specify a file that doesn't exist. nevertheless, i thought this might
be
worthwhile to bring to the attention of the developers, to see if you can
replicate this behavior, or if it's just me.
my OS is debian sarge (3.1). some possibly relevant installed packages are:
ii gcc 3.3.5-3
The GNU C compiler
ii libc6 2.3.2.ds1-22sarge6
GNU C Library: Shared libraries and Timezone data
ii libc6-dev 2.3.2.ds1-22sarge6
GNU C Library: Development Libraries and Header Files
ii libc6-i686 2.3.2.ds1-22sarge6
GNU C Library: Shared libraries [i686 optimized]
ii gdal-bin 1.2.6-1
Geospatial Data Abstraction Library - Utility programs
ii libgdal-doc 1.2.6-1
Documentation for the Geospatial Data Abstraction Library
ii libgdal1 1.2.6-1
Geospatial Data Abstraction Library
ii libgdal1-dev 1.2.6-1
Geospatial Data Abstraction Library - Development files
and i compiled mapserver-5.0.0 with locally compiled copies of gd-2.0.35 and
agg-2.5
my mapserver configure line was as follows:
./configure --with-gd=/usr/local --with-postgis --with-png --with-proj
--with-threads --with-agg=/usr/local --with-freetype --without-wms
--without-eppl --enable-debug
--
View this message in context:
http://www.nabble.com/wrong-filename-in-FORMATOPTION-leads-to-mapserv-segfault-tf4945787.html#a14159805
Sent from the Mapserver - User mailing list archive at Nabble.com.
