[mapserver-users] MapServer with RHEL5

[Russell McOrmond]

   Replying to my own message with further information.  I believe the 
problem we had is very different than the problem that Andreas Eichner 
observed.  Our problem becomes a different thing to check for if you 
notice odd core dumps.

   I also have a request for the mapserver developers so that if someone 
else has a similar problem in the future that mapserver will output 
errors that indicate the problem, rather than core dump.

On Sat, 18 Apr 2009, Russell McOrmond wrote:

> I had a problem with GD-2.0.35's configure script not detecting
> iconv correctly (see old thread:
> http://n2.nabble.com/Confirmation-of-status-of-UTF8-support,-and-where-transcoding-to-Latin-1-may-be-happening.-td1973930.html
> The stubs that caused the problem are at
> http://cvs.php.net/viewvc.cgi/gd/libgd/src/gdkanji.c?view=markup#l27 ),
> so I am compiling 2.0.36RC1.   If I load that version of GD instead of
> the 2.0.35 used by the systems people, and otherwise use their binaries
> and libraries, I do not get the core dump.

   This morning I used the little test I wrote in the past to check for the 
broken gd.

#include <stdio.h>
#include </path-to-libiconvs/include/iconv.h>
int main() {
      iconv_t cd;
      cd = iconv_open("UTF-8", "UTF-16");
      printf("iconv_open returns %d\n\n", (int)cd);
      iconv_close(cd);
      return 0;
}

gcc -L/mapserv/lib/ -lgd -liconv -o gdbroke gdbroke.c

   In the above the iconv.h has to be the one from libiconv, and not the 
one that comes with glibc.  It is only when you use the iconv.h from 
libiconv that this gd bug is tweaked.

   If I run the above with the libgd created by our systems folks, I get:

$ ./gdbroke
iconv_open returns -1

If I run against the gd 2.0.36RC1 I compiled, or with <iconv.h> so that I 
use the glibc version of iconv, I get:

$ ./gdbroke
iconv_open returns 146702344

(or some other number that isn't -1)

   I have joined the gd-devel mailing list and have asked when 2.0.36 will 
be released, which has this odd issue already resolved.

> the strings it was trying to compare were NULL.  I'm also wondering if
> it would be worthwhile to have code that in this case would exit
> gracefully with an error message rather than core dumping?

   In mapstring.c the common thing to do when iconv_open() returns -1, or 
any other error, is to do an msSetError() and then return NULL from the 
function.

   The problem appears to be that this return code is not checked, and in 
many cases the value is assumed to be a pointer to a string.  If that NULL 
is then used in a manipulation (say, a strdup()) then the program will 
core dump.  We never get to see the error string as the core dump happens 
before the error string is written to the error log.

   There are a number of ways to resolve this.  One is to always return a 
valid string (such as strdup("") ) from the function and set a global 
error number instead.  That way functions that don't check the error code 
will simply be manipulating a valid empty string, rather than a null.

   The other is to ensure that any call to a mapstring.c string function 
checks the return code for NULL.  I suspect this will be much more work.

   Thanks.

-- 
  Russell McOrmond, Internet Consultant: <http://www.flora.ca/>
  Please help us tell the Canadian Parliament to protect our property
  rights as owners of Information Technology. Sign the petition!
  http://digital-copyright.ca/petition/ict/     http://KillBillC61.ca

  "The government, lobbied by legacy copyright holders and hardware
   manufacturers, can pry control over my camcorder, computer,
   home theatre, or portable media player from my cold dead hands!"