Segmentation Faults on RH9

[Umberto Nicoletti]

On Thu, 2005-01-20 at 17:42 -0600, Colin McGuigan wrote:
> So I'm compiling Mapserver 4.4.1 with the following configure:
>
> ./configure --with-gd --without-tiff --without-pdf --without-geos
> --with-freetype --with-proj --with-gdal --with-postgis
> --with-php=/usr/local/install/php-4.3.10
> --with-php-regex-dir=/usr/local/install/php-4.3.10 --enable-debug
>
> gd, proj, gdal, postgis, and php are all compiled on the machine (all in
> /usr/local/lib with the exception of php).  There are no duplicated
> libraries between /usr/lib and /usr/local/lib.  PHP is compiled as a
> DSO, which according to HISTORY.TXT, now works.
>
> Configuring, making, and installing all seem to go fine, but it doesn't
> actually run.  The mapserv CGI never works; sometimes, it segfaults, and
> sometimes it displays gibberish text.
>
> Here's an example of the segfault from gdb.  The querystring is from the
> Itasca demo:
>
> [cmcguigan at localhost cgi-bin]# gdb mapserv
> GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
> 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"...
> (gdb) run
> "QUERY_STRING=layer=lakespy2&layer=dlgstln2&zoomsize=2&map=%2Fvar%2Fwww%2Fhtml%2Fworkshop%2Fitasca.map&program=%2Fcgi-bin%2Fmapserv&root=workshop&map_web_imagepath=%2Fvar%2Fwww%2Fhtml%2Fworkshop%2Ftmp%2F&map_web_imageurl=%2Fworkshop%2Ftmp%2F&map_web_template=itasca_basic.html"
> Starting program: /var/www/cgi-bin/mapserv
> "QUERY_STRING=layer=lakespy2&layer=dlgstln2&zoomsize=2&map=%2Fvar%2Fwww%2Fhtml%2Fworkshop%2Fitasca.map&program=%2Fcgi-bin%2Fmapserv&root=workshop&map_web_imagepath=%2Fvar%2Fwww%2Fhtml%2Fworkshop%2Ftmp%2F&map_web_imageurl=%2Fworkshop%2Ftmp%2F&map_web_template=itasca_basic.html"[New
> Thread 1082405184 (LWP 25579)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1082405184 (LWP 25579)]
> loadMapInternal (filename=0x80dc130 "/var/www/html/workshop/itasca.map",
>      new_mappath=0x0) at mapfile.c:4173
> 4173      msyyin = fopen(filename, "r");
> (gdb) backtrace
> #0  loadMapInternal (filename=0x80dc130 "/var/www/html/workshop/itasca.map",
>      new_mappath=0x0) at mapfile.c:4173

For some reason mappath is null and this causes the segfault. Why it is
that I do not know. Try to use fewer configure options and then run the
gdb again. If the problem goes away try adding more options, until you
find the culprit.
I would start with only --enable-debug;

> #1  0x0804cb78 in loadMap () at mapserv.c:248
> #2  0x0804f3b5 in main (argc=135120568, argv=0xbfffe154) at mapserv.c:1146
> #3  0x42015704 in __libc_start_main () from /lib/tls/libc.so.6
>
> After different compiles, it has different segfaults.  The other one I
> see often is in libc.regexec, but I don't have the trace handy.
>
> After some compiles, though, it doesn't segfault.  Instead, it'll
> display text like this: "NTSET "%s" : Unable to access file. ojection()
> " which sure seems to indicate some sort of memory problem.
>
> PHP Mapscript segfaults, as well.
>
> [cmcguigan at localhost bin]# gdb php
> GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
> 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"...
> (gdb) run /var/www/html/workshop/recipes/hello.phtml
> Starting program: /usr/bin/php /var/www/html/workshop/recipes/hello.phtml
> [New Thread 1078600352 (LWP 25600)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1078600352 (LWP 25600)]
> 0x406c09c0 in _init () from /usr/lib/php4/php_mapscript.so
> (gdb) backtrace
> #0  0x406c09c0 in _init () from /usr/lib/php4/php_mapscript.so
> #1  0x406d86f4 in mapObj_new (filename=0x40747a3d "", new_path=0x0)
>      at mapscript_i.c:100

here new_path is NULL, as above.

Regards,
Umberto

> #2  0x406c6e77 in php3_ms_map_new (ht=1081340215, return_value=0x822dc3c,
>      this_ptr=0x0, return_value_used=1) at php_mapscript.c:1726
> #3  0x0815ffd6 in execute (op_array=0x821ca0c)
>      at /usr/local/install/php-4.3.10/Zend/zend_execute.c:1642
> #4  0x08151e0f in zend_execute_scripts (type=8, retval=0x0, file_count=3)
>      at /usr/local/install/php-4.3.10/Zend/zend.c:900
> #5  0x0812af2f in php_execute_script (primary_file=0xbfffe590)
>      at /usr/local/install/php-4.3.10/main/main.c:1736
> #6  0x0816c1df in main (argc=2, argv=0xbfffe614)
>      at /usr/local/install/php-4.3.10/sapi/cli/php_cli.c:822
> #7  0x42015704 in __libc_start_main () from /lib/tls/libc.so.6
> (gdb)
>
> Anyways.  Has anyone seen anything like this before, and is there
> anything I can do?
>
> --Colin McGuigan
--
Umberto Nicoletti <unicoletti at prometeo.it>
Prometeo SRL