|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2006-04-07 05:28 UTC] 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 PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Wed Nov 05 12:00:01 2025 UTC |
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...Sorry, but it is confusing. Give this snippet: $image = imagecreatefromjpeg('088b1cc1662339d5008fd3d67ec7cf01.jpg'); imagejpeg($image); Did you try it on freebsd using the PHP sources and not the BSD ports? The backtrace has nothing to do with GD or the image functions. Please confirm that you use the PHP sources and the bundled GD and not the BSD ports.