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!"
_______________________________________________
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users
