mapserv segfaults

John C Cartwright John.C.Cartwright at NOAA.GOV
Thu Feb 10 15:57:58 EST 2005


Hi Sean,

Don't really know why it's picking up the libtiff from the ArcSDE
directory, but after various permutations of reording the
LD_LIBRARY_PATH, recompiling GDAL and Mapserver, and even linking the
libtiff in ArcSDE to the one in /usr/lib, I finally gave up and removed
SDE support from the mapserver compilation. Then recompiled GDAL,
Mapserver. Now recieve a similar error, but using the /usr/lib/libtiff.

 =================================================================================
(gdb) run
Starting program: /extra/contrib/apache/cgi-bin/mapserv-debug
[Thread debugging using libthread_db enabled]
[New Thread -1218611840 (LWP 9218)]
[Thu Feb 10 13:48:55 2005].454729 msWMSLoadGetMapParams(): enabling
non-square pixels.[Thu Feb 10 13:48:55 2005].457953 msDrawMap(): kicking
into non-square pixel preserving mode.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1218611840 (LWP 9218)]
0x008150d1 in realloc () from /lib/tls/libc.so.6
(gdb) where
#0  0x008150d1 in realloc () from /lib/tls/libc.so.6
#1  0x004be2ca in _TIFFrealloc () from /usr/lib/libtiff.so.3
#2  0x010d5a4b in TIFFMergeFieldInfo () from
/extra/contrib/gdal-1.2.5/lib/libgdal.so.1
#3  0x01108d38 in _XTIFFLocalDefaultDirectory () from
/extra/contrib/gdal-1.2.5/lib/libgdal.so.1
#4  0x01108d5d in _XTIFFDefaultDirectory () from
/extra/contrib/gdal-1.2.5/lib/libgdal.so.1
#5  0x004a4ba8 in TIFFDefaultDirectory () from /usr/lib/libtiff.so.3
#6  0x004a57a8 in TIFFReadDirectory () from /usr/lib/libtiff.so.3
#7  0x004b9ee4 in TIFFClientOpen () from /usr/lib/libtiff.so.3
#8  0x004be1db in TIFFFdOpen () from /usr/lib/libtiff.so.3
#9  0x004be260 in TIFFOpen () from /usr/lib/libtiff.so.3
#10 0x01108de8 in XTIFFOpen () from
/extra/contrib/gdal-1.2.5/lib/libgdal.so.1
#11 0x01058d10 in GTiffDataset::Open () from
/extra/contrib/gdal-1.2.5/lib/libgdal.so.1
#12 0x0110f1d5 in GDALOpen () from
/extra/contrib/gdal-1.2.5/lib/libgdal.so.1
#13 0x08078f85 in msDrawRasterLayerLow (map=0xb75a1008, layer=0x992c2e8,
image=0x9a9bf48) at mapraster.c:1450
#14 0x0808a139 in msDrawRasterLayer (map=0xb75a1008, layer=0x8d7538,
image=0x0) at mapdraw.c:1145
#15 0x080891ef in msDrawLayer (map=0xb75a1008, layer=0x992c2e8,
image=0x9a9bf48) at mapdraw.c:781
#16 0x080888e3 in msDrawMap (map=0xb75a1008) at mapdraw.c:446
#17 0x080cb2f8 in msWMSGetMap (map=0xb75a1008, nVersion=65793,
names=0x9914578, values=0x991e1c0, numentries=7)
     at mapwms.c:2156
#18 0x080ccd66 in msWMSDispatch (map=0xb75a1008, req=0x9914558) at
mapwms.c:2920
#19 0x0809e682 in msOWSDispatch (map=0xb75a1008, request=0x9914558) at
mapows.c:245
#20 0x080512a1 in main (argc=0, argv=0xbfff8c24) at mapserv.c:1165

 ================================================================================

Any ideas on what I should try next? I specified
--with-libtiff=internal --with-geotiff=internal in the GDAL config.  If
I specify a --with-tiff=DIR in the mapserver config, is that library
used or the one in the GDAL config?

Thanks!

-- john


Sean Gillies wrote:
> John,
>
> Did you link GDAL against the esri/sdeexe90/lib/libtiff.so?  Or is the
> dynamic linker picking it up by accident?  As far as I know, for best
> results you need to use GDAL's internal libtiff.  At any rate, looks
> like this is not a MapServer bug at all, but a bad match between GDAL
> and tibtiff.
>
> Sean
>



More information about the mapserver-users mailing list