ID:               37005
 User updated by:  ceo at l-i-e dot com
 Reported By:      ceo at l-i-e dot com
 Status:           Open
 Bug Type:         GD related
 Operating System: FreeBSD o11.hostbaby.com 5.3-REL
 PHP Version:      5.1.2
 Assigned To:      pajoye
 New Comment:

I was using this file as my test input:
088b1cc1662339d5008fd3d67ec7cf01.jpg

Note that it DOES output the image okay now, or, at least, it "looks"
okay in a browser, but a core dump happens when you try to exit PHP
with EOF (^D).

Sample code:
<?php $image =
imagecreatefromjpeg('088b1cc1662339d5008fd3d67ec7cf01.jpg');?>
<?php imagejpeg($image, 'cvs2.jpg');?>

Using 5.1.2 (not snapshot) on Windows, I got messages similar to what
you see.
C: php -v
PHP 5.1.2 (cli) (built: Jan 11 2006 16:40:00)

This MAY be specific to FreeBSD, then...


Previous Comments:
------------------------------------------------------------------------

[2006-04-07 18:22:52] ceo at l-i-e dot com

Progress.

Using the snapshot and its bundled GD.

I can now create the JPEG from the corrupted file, which is way more
than I expected, honestly.

I can also do imagejpeg($image, 'cvs1.jpg') and get it out.

But, then, as soon as I ^D to get out of the interpreter, it
core-dumped on me...

This was repeatable, twice in a row.

You can find the images, the cvs-generated images, and the core dumps
here:
http://www.acousticdemo.com/info.com/overture/jpeg_crashed/

I dunno if core dumps can be used across machines, but I could maybe
stumble my way through a backtrace thingie, if it would help...

------------------------------------------------------------------------

[2006-04-07 12:41:10] [EMAIL PROTECTED]

If the segfault still occurs using the CVS snapshot, please provide a
script with one or many images to reproduce the segfauls. CURL or any
other things are not GD related and will not be considered in this
bug.

However I tried your images and it is correctly proceeded:
Processing: 7512e7d01fc3894e106ca66db2d36064.jpg

Warning: imagecreatefromstring(): Data is not in a recognized format in
/home/pierre/projects/php/37005/37005.php on line ..



------------------------------------------------------------------------

[2006-04-07 08:34:57] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.1-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.1-win32-latest.zip



------------------------------------------------------------------------

[2006-04-07 05:28:24] ceo at l-i-e dot com

Description:
------------
This *MAY* be the same as the bug fixed by the new GD functions, what
with GD free-ing RAM that PHP had allocated, but I suspect it is
not...

Suppose a user is naive enough to not use CURLOPT_BINARYTRANSFER when
using curl to get an image.

Suppose they then pass that image string into imagecreatefromstring()

Then that user will get a segfault, most of the time.

Though not always.

Granted, this is pretty dumb thing to do, once you understand what
CURLOPT_BINARYTRANSFER is for in the first place.

But, before you grok that, it's a pretty common mistake.

Or, even if you understood it, but somehow mis-coded, or forgot it the
next time you wrote some similar code, you end up with segfaults.

And common mistakes, in an ideal world, should not segfault, but should
produce an E_ERROR (or similar).


Reproduce code:
---------------
The original code was your basic:
[Untested, really, but...]
<?php
  $curl = curl_init();
  curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);
  curl_setopt($curl, CURLOPT_URL,
'http://bugs.php.net/gifs/logo-bug.gif');
  $image_string = curl_exec($curl);
  $image = imagecreatefromstring($image_string);
?>

It may be JPEG only, so you'd need to try different images instead of
the self-referenctial GIF from this page.

However, you may find it easier to just snag this jpeg:
http://acousticdemo.com/info.com/overture/jpeg_crashed/088b1cc1662339d5008fd3d67ec7cf01.jpg
which I saved from the above, and work with it.

If you simply snag that, and do:
<?php imagecreatefromstring($YOURFILE);?>
it will segfault.

I can do it from the command line every time with that file.

Yes, it *IS* a corrupt JPEG, almost for sure.

But I'm hoping it's corrupt in a detectable way, if you know what I
mean, and we can change the 'segfault' behaviour into E_ERROR
behaviour.

Mozilla seems quite content to display a rendering which "looks right"
even for that corrupt image, which gives me hope that it is a
detectable error -- but also makes debugging quite difficult, since you
have an image that "looks right" but that PHP segfaults on, every time.

Here are some more sample (corrupt) images, for your convenience for
testing:
http://acousticdemo.com/info.com/overture/jpeg_crashed/


Expected result:
----------------
I expected E_ERROR for an invalid JPEG.

I don't expect it to "fix" the image the way the browsers do, though.

The scripter should be educated via E_ERROR to fix their code, rather
than have PHP fix it for, say, JPEGs, but then it fails for any custom
proprietary binary data.


Actual result:
--------------
segfault



------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=37005&edit=1

Reply via email to