wms raster rquest crash!

[Dylan Keon]

If you compiled MapServer using --with-gdal, make sure you also used
--without-tiff.  That is a common problem.  Also, you may want to
compile GDAL using --with-libtiff=internal and --with-geotiff=internal,
if you didn't try that already.

--Dylan


On 09/15/2004 11:18 AM, Ed McNierney wrote:
> Haiayan  -
>
> Well that's some new information!  You didn't mention that this image
> was working in MapServer before you had trouble.
>
> Are you certainly that you rebuilt MapServer with a current and complete
> set of supporting libraries, particularly the current versions of
> libtiff and libgeotiff?
>
>         - Ed
>
> Ed McNierney
> President and Chief Mapmaker
> TopoZone.com / Maps a la carte, Inc.
> 73 Princeton Street, Suite 305
> North Chelmsford, MA  01863
> ed at topozone.com
> (978) 251-4242
>
> -----Original Message-----
> From: UMN MapServer Users List [mailto:MAPSERVER-USERS at LISTS.UMN.EDU] On
> Behalf Of Haiyan Liu
> Sent: Wednesday, September 15, 2004 2:00 PM
> To: MAPSERVER-USERS at LISTS.UMN.EDU
> Subject: Re: [UMN_MAPSERVER-USERS] wms raster rquest crash!
>
> Hi Frank and Ed, thank you for your responses.
> We are currently using GDAL 1.1.9.0, released 2003/06/27.
>
> Up till I posted this problem, our Admin has helped us try all the
> latest gdal versions in no vail. We do have successfully set up the the
> same wms on the same box and another box before. But since we recompiled
> everying of mapserver from the latest releases, we encountered the
> current problem. And now even we tried switching back to some earlier
> releases, it was still not working(well, it really should).
>
> Not sure whether or not data could be causing this the problem because
> we used the same data before. Here is the file anyways.
>
>         www.firstbasesolutions.com/tmp_download
>
> Sincerely,
>
> Haiyan
>
> On Wed, 2004-09-15 at 10:15, Frank Warmerdam wrote:
>
>>Haiyan Liu wrote:
>>  >>From this list, we noticed some postings on this problem. As some
>>folks
>>
>>>suggested that SegFault problem could be traced to mapserver's
>>>shp2img, so we tried shp2img and did get that segfault crash. When
>>>we tried using gdb to 'debug' the shp2img util with the same
>>>mapfile, we found it crashed on tif_read, here is the message before
>
>
>>>it died,
>>>
>>>####################################################################
>>>######
>>>(gdb) run -m /var/www/html/zoom2it_mapserver/map_file/test_wms.map
>>>Starting program: /root/build/mapserver-4.0.1/shp2img
>>>-m/var/www/html/zoom2it_mapserver/map_file/test_wms.map
>>>(no debugging symbols found)...
>>>(no debugging symbols found)...
>>>(no debugging symbols found)...
>>>(no debugging symbols found)...
>>>(no debugging symbols found)...[Thread debugging using
>>>libthread_dbenabled] [New Thread -1084655424 (LWP 5180)] Program
>>>received signal SIGSEGV, Segmentation fault.
>>>[Switching to Thread -1084655424 (LWP 5180)]0x00a036ad in
>>>TIFFFillStrip (tif=0x8863628, strip=1) at tif_read.c:252252
>>>bytecount = td->td_stripbytecount[strip];
>>>####################################################################
>>>######
>>>
>>>I hope i have explained my problem clearly. Any help/hint will be
>>>greatly appreciated! By the way, almost all mapserver versions above
>
>
>>>4.0.1 have been triedwith the same configs as below and failed
>
> exactly the same way.
>
>>Haiyan,
>>
>>When reporting crashes within gdb it is also helpful to do a "where"
>>command so we can see the whole call stack.
>>
>>This seems like it might be a bug in GDAL.  I would encourage you to
>>report it in the MapServer Bugzilla and ensure it is assigned to me.
>>You will need to provide a dataset (ideally a smallish raster file
>>that also demonstrates the problem). Also, ensure you provide details
>>on the version of GDAL you are using.
>>
>>Best regards,
>
> --
> First Base Solutions Inc.
> 145 Renfrew Drive
> Suite 160
> Markham ON  L3R 9R6
>
> T. 905.477.3600
> F. 905.477.3882