Byron Posted May 3, 2010 Author Posted May 3, 2010 I've deleted the coredumps but I can recreate one if need be.
Ashoat Posted May 4, 2010 Posted May 4, 2010 I'd rather not debug the coredumps if it's avoidable. Can you reproduce the error? Does it occur without the jpeg being in the same directory?
Byron Posted May 4, 2010 Author Posted May 4, 2010 It's not producing an error_log file just a core_dump and it doesn't matter if the image is in the same directory or another directory.
Ashoat Posted May 4, 2010 Posted May 4, 2010 Is there perhaps a .htaccess in the directory? Can you access the image from outside?
Byron Posted May 4, 2010 Author Posted May 4, 2010 No there's not an htaccess file in that directory the script is in or the directory the image is in. Below is the url of the image and the script. I would post the url of the script but each time somebody clicked onto it it would produce a core file. http://sonny175.heliohost.org/images/Back.jpg <?php $image = new Imagick("../images/Back.jpg"); $image->charcoalImage(1, 2); header("Content-type: image/jpeg"); echo $image; ?>
Byron Posted May 4, 2010 Author Posted May 4, 2010 Not sure if this has anything to do with it but check our php info page where it says "Additional .ini files parsed" and it says none. http://sonny175.heliohost.org/info.php This other server has Imagick and it's showing a imagick file. http://95servers.com/phpinfo.php
Ashoat Posted May 4, 2010 Posted May 4, 2010 I don't think that's it. My understanding is that PECL extensions don't add php.ini directives, so the only thing they could be doing by separating their php.ini is running their extension= directives in a separate file. I thought the problem might be that I built ImageMagick without Perl, but after I fixed the issue preventing the installation with Perl and subsequently installed ImageMagick with Perl support, the issue remains. At this point I've tried the PECL-installed ImageMagick, the latest stable version, the latest beta version, and an old version. All versions are producing these coredumps. Any ideas as to what I should try?
Byron Posted May 4, 2010 Author Posted May 4, 2010 Any ideas as to what I should try? No not at this moment. What usually causes a core dump? After you figure this out can we go back with the newest version? ================================= Although this thread isn't talking about our exact problem, it may give you some ideas on what to check? http://stackoverflow.com/questions/1034628...class-undefined
Byron Posted May 5, 2010 Author Posted May 5, 2010 UPDATE: I've been doing some testing using different functions and found that not all functions cause a core dump. This script with CropImage() doesn't produce a core file. <?php header("Content-type: image/jpeg"); $image = new Imagick("../Banner/Image-Tool.jpg"); $image->cropImage( 20,20, 50,40 ); echo $image; ?> Ths script with charcoalImage() will cause a core file but other than that it still works. <?php header("Content-type: image/jpeg"); $image = new Imagick("../images/Back.jpg"); $image->charcoalImage(1, 2); echo $image; ?> And I believe it was thumbnailimage() that also caused a core file. Does that tell you anything djbob?
Ashoat Posted May 5, 2010 Posted May 5, 2010 Coredumps happen on segfaults. This means that there are bugs in the code. In other words, this is certainly Imagick's fault - the question is how and if we can get around it. The problem you linked to wasn't similar. That person probably just had two versions of PHP. The specific functions aren't that helpful (to me) either. I could theoretically recompile PHP with debug symbols and then run a debugger on the coredump, using the backtrace to either Google the bug or to file a bug report with the Imagick folks (probably the latter). However, I'm not sure this is worth a system recompilation (since cPanel requires recompiling everything just to recompile PHP).
Byron Posted May 5, 2010 Author Posted May 5, 2010 However, I'm not sure this is worth a system recompilation (since cPanel requires recompiling everything just to recompile PHP). What did you do to get Imagick to work when we upgraded php, do you remember? Did we loose something when we got attacked? I'm just wondering if it's something simple that we're missing.
Ashoat Posted May 5, 2010 Posted May 5, 2010 I just had ImageMagick persistently installed, and I would reinstall the imagick PECL extension on every PHP rebuild. It could be that the new ImageMagick has a bug, or that the old one was compiled with an extra library that was used instead of a library that's currently used, and the extra library didn't cause a segfault. But those kind of problems are hard to debug.
Byron Posted May 5, 2010 Author Posted May 5, 2010 So where do we go from here? btw, I think GhostScript is missing also. I don't use it but we had a user using it a few months back.
Ashoat Posted May 5, 2010 Posted May 5, 2010 I really don't know what to do at this point. I would suggest contacting some mailing lists to see if they know what's going on, or if they have any suggestions. Okay, I've installed Ghostscript and recompiled ImageMagick to include it.
Byron Posted May 5, 2010 Author Posted May 5, 2010 See if this thread helps you any djbb. http://www.webhostingtalk.com/showthread.php?t=857053 EDIT: Just incase that thread doesn't give you any ideas, let me get my story straight before I go posting all over the internets. What was our ImageMagick version and Imagick version before we were DDoS'ed (and all was well)? So then you upgraded to ImageMagick Version 6.6.1 and Imagick version 2.3.0 and that gave us core files so you went with Imagick version 2.2.2 and we're still at core files, right? If we don't come up with anything, how hard would it be to go back to what we had?
Recommended Posts