I'm replying to an older message in the hope that there is an update, and possibly more people running RHEL5 at this point. There has been a related problem with some machines at work and I'm trying to determine if there is a pattern, and hopefully a patch to the right component can be made.
I'm not in the group that manages our production systems, so don't have all the details for those systems. When the systems people compile everything (mapserver, gdal, iconv, gd, etc, etc) on RHEL4 it works fine. That set of binaries and libraries can even be loaded onto a RHEL5 machine and run. (LD_LIBRARY_PATH and PATH set to have those libs and binaries load first). If they use the identical versions and build scripts on RHEL5, we get a core dump doing a number of different things. This includes a simple GetMap where there is an expression in the mapfile (comment out the expression and we don't get a core dump). In our environment the systems people are running RHEL5, but I am using CentOS5 on my desktop. If I load the binaries compiled by the systems people I get the same core dump. If I compile everything myself on CentOS5, I do not get the core dump. There is one observation which might be a red herring, or might be useful. 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. Is it possible that there is something in the code for expressions that would cause a core dump if iconv_open() returned -1, or iconv() returning 0? I haven't read through the mapserver code yet to determine how expressions are implemented, and what the code would do if any of 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? Is there something in RHEL5 vs RHEL4 that might be interacting strangely in some other way with gd, unrelated to that iconv_open() stub? Note: The systems people may not be comfortable using a release candidate of GD even though it has been well tested since 2007-11-28. I'm wanting to see if anyone else has observed any similar problems, and may already know the solution. I suspect they are doing something different with how they compile GD-2.0.35 given the iconv problem I observed would have disabled the ability to access Unicode strings in our ArcSDE managed database. That said, I don't know for certain whether Unicode strings were ever tested with the core dumping binaries. Eichner, Andreas - SID-NLKM wrote: > Hi guys, > > we're using MapServer 5.2 with RedHat Enterprise Linux 5, Update 3. The > necessary packages (like gdal) are inserted from Fedora Core 6. That > works but the packages are somewhat outdated. So I tried to use those > from the EPEL channel instead but without success. After compiling MS it > segfaults because of the same problem discussed earlier on the list with > a conflict between librx headers and libraries (the segfault can be > avoided adding some bytes to sizeof(regex_t) in ms_regcomp() but with > the effect of ms_regexec() returning wrong results). > The servers are fed by a satellite server and have no direct access to a > separate repo. So does anyone use MS with RHEL5 and has a nice solution > for that? My personal solution would be to use Debian as on my test > server (where I never had problems compiling and using MS) but that's > not an option for the productive systems here :( > > Regards, > Andreas Eichner -- 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://www.digital-copyright.ca/petition/ict/ "The government, lobbied by legacy copyright holders and hardware manufacturers, can pry 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