Opened 21 years ago

Closed 16 years ago

Last modified 16 years ago

#370 closed defect (wontfix)

libpng conflicts PHP version of libpng causes php/mapscript to crash

Reported by: woodbri@… Owned by: dmorissette
Priority: high Milestone: 5.2 release
Component: MapScript-PHP Version: 4.0
Severity: major Keywords:
Cc: ed@…

Description (last modified by hobu)

I think is really a php mapscript build problem. Anyway here is the scenerio:

We built mapserver, php/mapscript (3.7 may 2nd and 4.0b2) with php 4.3.1 and
4.3.2 and were using gd-2.0.12 and gd-2.0.15 built with gif support on RH8.0
with latest rpm updates also had gdal-1.1.8 and gdal-1.1.9. Everything works
fine when we use mapserv cgi for both gif and png image generation.

The problem came when we switched our mapfiles to generate PNG and all the
mapscript apps broke on the call to $oImg->SaveImage(...) in mapscript.

After rebuilding most of the combinations above, I rebuilt PHP without
--with-pdflib as just adding --without-png didnot clear the problem. So the
following worked:

./configure \
--enable-force-cgi-redirect \
--enable-discard-path \
--with-config-file-path=/etc/httpd/ \
--without-png \
--with-gd=/usr/local \
--with-jpeg-dir \
--with-zlib-dir \
--with-freetype-dir \
--without-ttf \
--with-mysql \
--with-regex=system \
--with-ming \
--enable-dbase \
--enable-dbx

while this did NOT work:

rm -f config.cache
./configure \
--enable-force-cgi-redirect \
--enable-discard-path \
--with-config-file-path=/etc/httpd/ \
--with-png \
--with-gd=/usr/local \
--with-jpeg-dir \
--with-zlib-dir \
--with-freetype-dir \
--without-ttf \
--with-mysql \
--with-regex=system \
--with-pdflib \
--with-ming \
--enable-dbase \
--enable-dbx

Recommended action:

1) someone needs to see if they can reproduct this problem
2) because it is subtle and very difficult to debug, and appropriate fix needs
to be added to ./configure AND/OR better yet the code needs to be changed to
allow this to work in either case.

Commentary:

I'm not sure that this has anything to do with the problem, but reading up on
the libpng it seems that there are two (2) versions of the API that are not
compatible, but apparently have the same entry points. I surmise that libpdf is
causing the new api to be loaded and that the php_mapscript.so is expecting the
old api, so when we call the png entry point from mapscript is crashes, but when
we call the same entry point from CGI mapserv we have loaded the old version of
the libpng since both version are installed on the system.

Change History (9)

comment:1 by dmorissette, 21 years ago

Status: newassigned
Steve, this is really a configuration issue on which MapServer has little
control.  I mean there are several ways to create an incompatible combination of
PHP modules that will interfere with each other and this is not MapServer've
fault, it's more up to the system administrator to prevent these conflicts from
happening by maintaining only a single version of each lib on their server.

Anyway, let's see if we can shed some light on the exact source of this problem
and document it on the wiki to save other users the headaches that this gave you.

ok, so you seem to have concluded that multiple versions of libpng would be
loaded and if that's the case then that could very well explain the crash. 
Could you please send the 'ldd' output for php_mapscript.so, php (Exe) (assuming
PDF is statically built into PHP).  This would allow us to confirm that multiple
libnpg.so are loaded, assuming that the broken libpng that you refer to is not
built into libpdf.so.

comment:2 by dmorissette, 21 years ago

My copy of pdflib-4.0.2 comes with libpng 1.0.8 and according to the PDF
configure script this internal copy of PNG would be used by default.

So you're right, by default you end up with two versions of libpng and this is
bad.  
Can you try rebuilding pdflib using   '--with-pnglib=/usr --with-zlib=/usr'  and
see if that fixes your problem.
 

comment:3 by woodbri@…, 21 years ago

Daniel,

Thank you for looking at this. We have been using the RH8 RPM version of pdflib.
I guess I will have to ditch that and build it from source. I am kind of
surprised that RH doesn't build all their RPMs pointing at common system libs,
instead of package internal libs!

Here are ldd lists from a system that I think is built with this problem. I
think the last listing confirms the libpdf is statically linked with internal
libpng as it does not show it as an external reference. Is this how you read this?

[root@strabo03 root]# ldd /usr/lib/libpng.so
        libz.so.1 => /usr/lib/libz.so.1 (0x4002c000)
        libm.so.6 => /lib/i686/libm.so.6 (0x4003b000)
        libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
[root@strabo03 root]# ldd /usr/lib/libpng12.so
        libz.so.1 => /usr/lib/libz.so.1 (0x4002c000)
        libm.so.6 => /lib/i686/libm.so.6 (0x4003b000)
        libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
[root@strabo03 root]# ls -l /usr/lib/libpng*
-rw-r--r--    1 root     root       169444 Jan  8  2003 /usr/lib/libpng12.a
lrwxrwxrwx    1 root     root           13 Jun 20 17:31 /usr/lib/libpng12.so ->
libpng12.so.0
lrwxrwxrwx    1 root     root           19 Jan 29 10:10 /usr/lib/libpng12.so.0
-> libpng12.so.0.1.2.2
-rwxr-xr-x    1 root     root       160715 Jan  8  2003 /usr/lib/libpng12.so.0.1.2.2
lrwxrwxrwx    1 root     root           10 Jun 20 17:31 /usr/lib/libpng.a ->
libpng12.a
lrwxrwxrwx    1 root     root           19 Jun 20 17:31 /usr/lib/libpng.so ->
libpng12.so.0.1.2.2
lrwxrwxrwx    1 root     root           18 Jan 29 10:10 /usr/lib/libpng.so.2 ->
libpng.so.2.1.0.13
-rwxr-xr-x    1 root     root       155775 Dec 19  2002 /usr/lib/libpng.so.2.1.0.13
lrwxrwxrwx    1 root     root           19 Jan 29 10:10 /usr/lib/libpng.so.3 ->
libpng12.so.0.1.2.2
lrwxrwxrwx    1 root     root           19 Jan 29 10:10
/usr/lib/libpng.so.3.1.2.2 -> libpng12.so.0.1.2.2
[root@strabo03 root]# ldd /var/www/cgi-bin/php
        libpdf.so.1 => /usr/lib/libpdf.so.1 (0x4001d000)
        libz.so.1 => /usr/lib/libz.so.1 (0x400ad000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x400bb000)
        libming.so => /usr/lib/libming.so (0x400de000)
        libm.so.6 => /lib/i686/libm.so.6 (0x4011b000)
        libgd.so.2 => /usr/local/lib/libgd.so.2 (0x4013d000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x4018d000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x401d7000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x401f5000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x40222000)
        libdl.so.2 => /lib/libdl.so.2 (0x40234000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x40237000)
        libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[root@strabo03 root]# ldd /etc/httpd/php_mods/php_mapscript.so
        libcurl.so.2 => /usr/lib/libcurl.so.2 (0x400b5000)
        libz.so.1 => /usr/lib/libz.so.1 (0x400da000)
        libssl.so.2 => /lib/libssl.so.2 (0x400e8000)
        libcrypto.so.2 => /lib/libcrypto.so.2 (0x40118000)
        libdl.so.2 => /lib/libdl.so.2 (0x401ec000)
        libming.so => /usr/lib/libming.so (0x401ef000)
        libgdal.1.1.so => /usr/local/lib/libgdal.1.1.so (0x4022c000)
        libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40488000)
        libproj.so.0 => /usr/local/lib/libproj.so.0 (0x404d8000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40506000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x40524000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x4056d000)
        libpdf.so.1 => /usr/lib/libpdf.so.1 (0x40590000)
        libgd.so.2 => /usr/local/lib/libgd.so.2 (0x40620000)
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40670000)
        libm.so.6 => /lib/i686/libm.so.6 (0x40722000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40744000)
        libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
[root@strabo03 root]#
[root@strabo03 root]# ls -l /usr/local/lib/libgd.*
-rw-r--r--    1 root     root       802780 Jun 23 12:55 /usr/local/lib/libgd.a
-rwxr-xr-x    1 root     root          750 Jun 23 12:55 /usr/local/lib/libgd.la
lrwxrwxrwx    1 root     root           14 Jun 23 12:55 /usr/local/lib/libgd.so
-> libgd.so.2.0.0
lrwxrwxrwx    1 root     root           14 Jun 23 12:55
/usr/local/lib/libgd.so.2 -> libgd.so.2.0.0
-rwxr-xr-x    1 root     root       545347 Jun 23 12:55
/usr/local/lib/libgd.so.2.0.0
[root@strabo03 root]# ldd /usr/local/lib/libgd.so.2.0.0
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40059000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x40078000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x400c1000)
        libz.so.1 => /usr/lib/libz.so.1 (0x400e4000)
        libm.so.6 => /lib/i686/libm.so.6 (0x400f2000)
        libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
[root@strabo03 root]#
[root@strabo03 root]# ls -l /usr/lib/libpdf.*
-rw-r--r--    1 root     root       773970 Jun  7  2001 /usr/lib/libpdf.a
-rw-r--r--    1 root     root          641 Jun  7  2001 /usr/lib/libpdf.la
lrwxrwxrwx    1 root     root           15 Jun 20 16:15 /usr/lib/libpdf.so ->
libpdf.so.1.1.1
lrwxrwxrwx    1 root     root           15 Jun 20 16:15 /usr/lib/libpdf.so.1 ->
libpdf.so.1.1.1
-rwxr-xr-x    1 root     root       663046 Jun  7  2001
/usr/lib/libpdf.so.1.1.1[root@strabo03 root]# ldd /usr/lib/libpdf.so.1.1.1
        libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
[root@strabo03 root]#

comment:4 by dmorissette, 21 years ago

> I think the last listing confirms the libpdf is statically linked with internal
> libpng as it does not show it as an external reference. Is this how you read
> this?

Yes, that's also the way I read this too.

What surprises me is that we never had problems using pdflib inside the mapserv
CGI.  We've probably just been lucky with the order in which symbols are loaded
in this case I guess.

comment:5 by hobu, 17 years ago

Description: modified (diff)

Is this one dead?

comment:6 by woodbri, 17 years ago

I don't use this configuration any more, so I will leave this up to Daniel. This is pretty well documented, so Daniel might want to see if anyone on his team can reproduce it. There have been a lot of Linux changes since this was filed and I don't even have access to a RH Linux any more. Other than that it is probably safe to close as "over come by events"

comment:7 by dmorissette, 17 years ago

Milestone: 5.2 release

comment:8 by dmorissette, 16 years ago

Resolution: wontfix
Status: assignedclosed

Closing WONTFIX since there have been no other reports of the issue, so while it may still exist this is a very low priority. For anyone encountering this, a simple workaround is to build pdflib without the builtin copy of libpng.

comment:9 by woodbri, 16 years ago

Thank you Daniel, this seems to be well documented in the bug so I'm ok with this resolution.

Note: See TracTickets for help on using tickets.