#29349 [Com]: imagecreatefromstring segfaults (fix included)

From: Date: Mon, 26 Jul 2004 14:16:08 +0000
Subject: #29349 [Com]: imagecreatefromstring segfaults (fix included)
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-63559@lists.php.net to get a copy of this message
ID: 29349 Comment by: adconrad at debian dot org Reported By: k at ailis dot de Status: Bogus Bug Type: GD related Operating System: Linux PHP Version: 4CVS-2004-07-23 (stable) New Comment: I'm not entirely sure which planet you're from, but a double-free bug from incorrect usage of a library is not a "bogus" bug. Distributions link to external libraries because symbol clashes in shared application space is BAD (and your internal library doesn't use versioned symbols) and because security updates to a dozen statically compiled packages is much more of a pain in the ass than security updates to an individual library. If you don't want distributions to package your stuff, get a consensus from your contributors and slap a more restructive license on it. If you do want it being used widely, get rid of your NIH attitude and realise that YOU bundled libgd, they didn't "steal" it from you and "break" it. It's your bundled version that you broke to work around a bug in PHP, rather than fixing the PHP bug. That's not sane. Previous Comments: ------------------------------------------------------------------------ [2004-07-25 21:42:11] k at ailis dot de Then why are you not modifying your configure system so it checks to have at least GD 2.0.21 if the external GD lib is used? If you are argumenting that everyone should use the bundled GD lib anyway then you don't need to bother with those poor users which are not having at least GD 2.0.21. But if you don't want to "exclude" users of older GD libraries and you think it's ok that these users are not able to use some PHP functions without segfaults then you can do some conditional compiling. In that way you can help users by saying "Update to GD 2.0.21 or better and recompile PHP OR use the bundled GD" instead of insisting only on the usage of the bundled one. But slowly the impression comes to me that you don't want users to use the external GD. You are already no longer giving support for the usage of the external one (At least nothing else then the silly "use the bundled GD library" response which does not respect the fact that the user may have reasons to use the external library). So maybe you should be consequential and remove compilation support for the external GD completely. Then you have no longer to deal with bug reports like this... ------------------------------------------------------------------------ [2004-07-25 21:10:18] iliaa@php.net The patch relies on a function only available in later versions of GD, which not everyone has. The bundled GD has no problem what so over and should be used. ------------------------------------------------------------------------ [2004-07-25 20:54:32] k at ailis dot de Narf... This is NOT a bug in the GD library. The function you are using is freeing memory because this function is MEANT to do exactly this because this function normally deals with data which was allocated by GD itself. But you are passing data to this function which was allocated by YOU. Boutell has already dealt with this problem and has created new functions which exactly suit your needs: The gdImageCreateFrom*Ptr functions and also the gdNewDynamicCtxEx function. RTFM: * The new gdNewDynamicCtxEx function was added to support the easy implementation of the above functions and to correct a design problem which made life unpleasant for those passing in memory not originally allocated by gd to the gdNewDynamicCtx function by providing a way to specify that gd should never free or reallocate a particular block of memory. The gdNewDynamicCtx function and its relatives, although still exported for ABI compatibility, are now deprecated except for internal use, in favor of [45]gdImageCreateFromPngPtr and its relatives. So please stop putting your head in the sand and apply Adam Conrad's patch or move to the new gdImageCreateFrom*Ptr functions. ------------------------------------------------------------------------ [2004-07-25 19:28:39] iliaa@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. This is a bug in the GD library, we recommend to always use the bundled GD library, which as you've indicated does not have this problem. ------------------------------------------------------------------------ [2004-07-25 15:21:35] adconrad at debian dot org As of the next upload to the Debian archive, we will be using the following patch, which seems to clear up every php4-gd segfault bug we've had reported: --- php4-4.3.8/ext/gd/gd.c.orig 2004-07-24 06:00:25.000000000 -0600 +++ php4-4.3.8/ext/gd/gd.c 2004-07-24 06:10:38.000000000 -0600 @@ -1242,7 +1242,7 @@ #ifdef HAVE_GD_WBMP else { gdIOCtx *io_ctx; - io_ctx = gdNewDynamicCtx (8, data); + io_ctx = gdNewDynamicCtxEx (8, data, 0); if (io_ctx) { if (getmbi((int(*)(void*))gdGetC, io_ctx) == 0 && skipheader((int(*)(void*))gdGetC, io_ctx) == 0 ) { #if HAVE_LIBGD204 @@ -1274,7 +1274,7 @@ gdImagePtr im; gdIOCtx *io_ctx; - io_ctx = gdNewDynamicCtx (Z_STRLEN_PP(data), Z_STRVAL_PP(data)); + io_ctx = gdNewDynamicCtxEx (Z_STRLEN_PP(data), Z_STRVAL_PP(data), 0); if (!io_ctx) { return NULL; @@ -1428,7 +1428,7 @@ goto out_err; } - io_ctx = gdNewDynamicCtx(buff_size, buff); + io_ctx = gdNewDynamicCtxEx(buff_size, buff, 0); if(!io_ctx) { php_error_docref(NULL TSRMLS_CC, E_WARNING,"Cannot allocate GD IO context"); goto out_err; ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/29349 -- Edit this bug report at http://bugs.php.net/?id=29349&edit=1

« previous php.bugs (#63559) next »