Opened 20 years ago

Closed 20 years ago

#558 closed defect (wontfix)

Seg Fault in msReturnQuery() on Fedora

Reported by: dmorissette Owned by: dmorissette
Priority: high Milestone:
Component: MapServer C Library Version: 4.1
Severity: normal Keywords:
Cc: sscott@…

Description

In an email to mapserver-users, Shannon Scott wrote:
-----------

Greetings.

We recently upgraded from RedHat 8.0 to the fedora OS.
Since then we have had trouble with one of our map files.
I searched for the error in the apache log “Premature end of script headers:
mapserv”, but found no solution.

Then I tried the debugger.

I got this:

 

$ gdb mapserv
GNU gdb Red Hat Linux (5.3.90-0.20030710.41rh)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols
found)...Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) run
"QUERY_STRING=map=/var/tomcat4/webapps/ROOT/static/mcht/mltn_query.map&mode=itemquery&qlayer=mltntrim&qitem=id&qstring=([id]=38)"

Starting program: /usr/local/mapserv_fedora/mapserver-4.0.1/mapserv
"QUERY_STRING=map=/var/tomcat4/webapps/ROOT/static/mcht/mltn_query.map&mode=itemquery&qlayer=mltntrim&qitem=id&qstring=([id]=38)"
Program received signal SIGSEGV, Segmentation fault.
0x080566d9 in msReturnQuery ()
(gdb) backtrace
#0  0x080566d9 in msReturnQuery ()
#1  0x08051019 in msReturnTemplateQuery ()
#2  0x0804ec72 in main ()
(gdb)

 

Then I changed to itemnquery and got this:

$ gdb mapserv
GNU gdb Red Hat Linux (5.3.90-0.20030710.41rh)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols
found)...Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) run
"QUERY_STRING=map=/var/tomcat4/webapps/ROOT/static/mcht/mltn_query.map&mode=itemnquery&qlayer=mltntrim&qitem=id&qstring=([id]=38)"

Starting program: /usr/local/mapserv_fedora/mapserver-4.0.1/mapserv
"QUERY_STRING=map=/var/tomcat4/webapps/ROOT/static/mcht/mltn_query.map&mode=itemnquery&qlayer=mltntrim&qitem=id&qstring=([id]=38)"

Content-type: text/html

<!-- MapServer version 4.0.1 OUTPUT=PNG OUTPUT=JPEG OUTPUT=WBMP SUPPORTS=PROJ
SUPPORTS=FREETYPE SUPPORTS=WMS_SERVER INPUT=TIFF INPUT=EPPL7 INPUT=JPEG
INPUT=GDAL INPUT=SHAPEFILE -->

Program received signal SIGSEGV, Segmentation fault.
0x0031c153 in strlen () from /lib/tls/libc.so.6
(gdb) backtrace
#0  0x0031c153 in strlen () from /lib/tls/libc.so.6
#1  0x0035d23a in regexec () from /lib/tls/libc.so.6
#2  0x08055db4 in msReturnPage ()
#3  0x08056489 in msReturnQuery ()
#4  0x08051019 in msReturnTemplateQuery ()
#5  0x0804ec72 in main ()
(gdb)
 

How should I proceed?
Any help or advice is greatly appreciated.
Thank You.

Shannon

Change History (7)

comment:1 by dmorissette, 20 years ago

Cc: sscott@… added

comment:2 by dmorissette, 20 years ago

Cc: warmerdam@… steve.lime@… added
Owner: changed from sdlime to morissette@…
Daniel Morissette wrote:
> Can you try against the latest 4.1 (CVS) source and see if that seg 
> fault happens with that version as well?
> 
> If the crash still happens with V4.1, then try including the 
> --enable-debug option and recompile MapServer.  You will then be able to 
> see exactly where in msReturnQuery() the crash happens (in gdb).  With 
> this information we may be able to figure the source of the problem, if 
> the gdb output doesn't give enough info then you may have to file a bug 
> in bugzilla with a mapfile/dataset that can be used to reproduce the 
> problem.
> 
> Daniel
> 


Shannon Scott wrote:
> Thank You.
> The CVS version could not complte the make:
> 
> gcc -O2  -Wall -DIGNORE_MISSING_DATA  -DUSE_EPPL -DUSE_PROJ
> -DUSE_PROJ_API_H -DUSE_WMS_SVR       -DUSE_JPEG -DUSE_GD_PNG
> -DUSE_GD_JPEG -DUSE_GD_WBMP -DUSE_GD_FT    -DUSE_GDAL
> -I/usr/local/include          -I/usr/local/include      shp2img.o  -L.
> -lmap -lgd -L/usr/local/lib -lgd  -lfreetype -lpng -lz    -lfreetype
> -lpng -lz   -lproj -ljpeg   -L/usr/local/lib -lgdal.1.1        -lm
> -lstdc++   -o shp2img
> /usr/local/lib/libgdal.1.1.so: undefined reference to
> `TIFFMergeFieldInfo'
> collect2: ld returned 1 exit status
> make: *** [shp2img] Error 1
> 
> I installed the gdal with a fresh download today.
> Is there a CVS gdal that I need?  I will try to find one.
> I will also try the nightly build of mapserver and see if that works.
> Thank you for your thoughtful help.
> Your time is greatly appreciated.
> Take Care
> Shannon
> 
>

comment:3 by dmorissette, 20 years ago

Are you sure that you have only one copy of GDAL on your system?  I am able to
build the latest mapserver from CVS with both GDAL 1.1.8 and 1.1.9 without problems.

Frank: do you have any idea why we would get this TIFFMergeFieldInfo error when
linking with GDAL?

comment:4 by fwarmerdam, 20 years ago

If you are getting TIFFMergeFieldInfo missing on Unix it is almost certainly
because you are linking against a libtiff earlier than 3.6.0.  Please upgrade
to libtiff 3.6.1 and try again. If you are already using libtiff 3.6.1 then
review the link options in the Makefile as presumably you are not picking up
your new libtiff at link time. 

comment:5 by dmorissette, 20 years ago

Actually, I see that you have "INPUT=TIFF" in your mapserver options.  Perhaps
you should add --without-tiff in your MapServer configure.  Then remove the
libtiff-devel RPM from your system and let GDAL use its internal TIFF.

comment:6 by sscott@…, 20 years ago

The CVS version of Mapserver does not have the problem.  It works well.
Thank You.
Shannon

comment:7 by dmorissette, 20 years ago

Resolution: wontfix
Status: newclosed
Let's mark this WONTFIX for 4.0 then, since the problem is gone in 4.1
Note: See TracTickets for help on using tickets.