Bug 194333 - mod_perl, GD, libpng combination core dumps when doing $img->png
Summary: mod_perl, GD, libpng combination core dumps when doing $img->png
Status: Closed Not Accepted
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Dirk Meyer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-13 15:02 UTC by papowell
Modified: 2014-10-30 05:45 UTC (History)
1 user (show)

See Also:

Attachments
SHAR of graphics/png16, graphics/png16, mods to graphics/gd/Makefile (20.13 KB, text/plain)
2014-10-13 15:02 UTC, papowell 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description papowell 2014-10-13 15:02:48 UTC 
Created attachment 148258 [details]
SHAR of graphics/png16, graphics/png16,  mods to graphics/gd/Makefile

Using: apache24, libpng (libpng15), gd, p5-GD from repository, also when compiled from ports.

When generating graphics using a Perl script from apache, apache core dumps when the perl CGI script runs $img->png,  but only for a small set of graphics. Similar problem reported in 2004 for various Linux distributions. The problem appears to be in the libpng $img->png support.  Note: this only occurs when using mod_perl,  same scripts run stand alone do not core dump.

Solution:  installed libpng16, compiled gd using libpng16,  p5-GD using gd with libpng16.  This passed my admittedly feeble regression tests.

In doing this,  I generated a modified version of graphics/png which installs libpng16.  However, graphics/png also installs files with the same names in the same locations, i.e. /usr/local/include and /usr/local/lib.  The graphics/png script currently creates version specific directories, /usr/local/lib/libpng15 and installs the libpng15 libraries in this location as well.

I have modified the graphics/png and created two new ports - graphics/png15 and graphics/png16.  These have a 'configure' option - COMPAT that when selected will not install files in conflicting locations.  By default, the graphics/png15 has COMPAT disabled and installs the files while graphics/png16 has the COMPAT enabled and will not install the files in conflicating locations.

The graphics/gd port Makefile has been modified and a LIBPNG16 configuration option added.  When this is selected then the libpng16 version of the libraries installed by graphics/libpng16 are forced to be used, otherwise the default libraries installed by graphics/png or graphics/png15 can be used.

Attached is a SHAR file that has the graphics/png15 and graphics/png16 ports.  These can be added to the ports without causing any conflicts with graphics/png until they are used,  and only if you disable the COMPAT option.

Also, there is a patch for graphics/gd which will select the libpng16 libraries if the LIBPNG16 configuration option is used.

Is it possible to add these changes to the ports distribution?
Comment 1 Bugzilla Automation freebsd_committer freebsd_triage 2014-10-13 15:02:48 UTC 
Maintainers CC'd
Comment 2 Dirk Meyer freebsd_committer freebsd_triage 2014-10-15 19:30:47 UTC 
graphics/png16 is still worked on.

there are about 5500 ports depending on png15.

due to the high disorder in the ports infrastructure,
the patches can not applied in time.

once you build gd with new png,
the application can no longer link png15.

Problem: a lot of configure scripts fail with png16
and the application has no longer support for png data.

I am against of editing 5500 ports for renaming the port.

I do not want conflicting versions in the ports.
Comment 3 papowell 2014-10-24 00:03:42 UTC 
Sounds like good reasons not to do this update.
Comment 4 Dirk Meyer freebsd_committer freebsd_triage 2014-10-30 05:45:28 UTC 
update delayed.

gif png and jpeg will be updated in one big sweep.