core dump files from PHP using Imagick

I think .. . . and limited control to debug . . . .

[rocknbil]

Question: general course of action, considering the limited tools at my disposal.

Environment: Sever, Apache/2.2.11, PHP, 5.2.9, iMagick, 3.0.0b2, imageMagick, 6.5.9-6.

Problem: Huge core.#### files are being deposited into the directory where an upload script resides. This **only** seems to occur when large image files are uploaded and resized, which occurs without obvious error. Files under 1 MB don't create core dumps.

Understood: A core dump occurs when a program crashes. Since the upload/resize process occurs without error, works fine, assumption one is that the crash comes from some included module or resource being used by PHP.

Limited controls: And here's what bites. Shared hosting, I am able to create SSH keys to debug, but the account has no shell access, which would cost the client more. I am operating as a third party, so can't contact either the client or the host directly, or have the sysadmins tell me what's happening. Basically most of the tools I need are "not available."

Error logs are cheesy only-through-domain-management CP, and they appear to flush daily. I fiddled with it a bit, assume I can't access error logs.

I was able to script up the following commands, where #### is the number in the core extension:

exec("file core.####",$var) or die("cannot execute file");
foreach ($var as $k=>$v) { echo "<br><br>k: $k v: $v<br><br>"; }
exec("gdb httpd core.####",$var) or die("cannot execute gdb");

This outputs

k: 0 v: core.####: ELF 64-bit LSB core file AMD x86-64, version 1 (SYSV), SVR4-style, from 'php'

cannot execute gdb

Which reveals two things: the dump is coming from PHP, and I can't execute gdb, at least, not from PHP. gdb reads the stack trace of core files, which appear to be binary, unreadable by text editors. They are also very large, looking at one now, 156856320. So you can see why I want to get rid of them . . .

Assumption two: since these dumps only occur when larger files are uploaded and resized, such as directly from a digicam, I am assuming it's something to do with either iMagick or more likely imageMagick. OR am I chasing the wrong ghost?

I could post the code I'm using, don't see it as useful, it's basic Imagick resizing.

Any thoughts? I already have "you're hosed." :-P

[coopster]

Error logs are cheesy only-through-domain-management CP, and they appear to flush daily. I fiddled with it a bit, assume I can't access error logs.

A workaround with many cpanel shared hosting environments is to trigger errors. Wrap a little logic around your execution block and if it fails trigger an error using the last error that occurred. Many cpanel shared hosts are set up with the ini settings for

display_errors

and

error_log

:

display_errors = STDOUT 
error_log = error_log

If you have FTP access, navigate to the directory where the script is running and watch for an "error_log" file.

Yes, it seems as though this would be a huge security issue but the hosts that have this set up as such usually have "error_log" inaccessible via the Apache config. Direct navigation attempts to these files results in a 403 Forbidden.

---

PECL shows a newer release candidate for Imagick that you may consider installing to update the current version. The changelog shows some interesting patches [pecl.php.net] that may be your issue ...

[rocknbil]

Right . . . this host **does** generate PHP error logs error_logs in the directory on errors . . . checked that route too. No error logs generated when it creates the core files.

I was referring to the system's error logs, and it makes "a little" bit of sense that only this shared domain's error logs are available via the CP. Why they flush them, I guess it's a matter of efficiency. My hope was that the system would generate an error log entry whereas there's no real PHP error.

Unfortunately, being shared, no access to install any modules. That would have been my first hit, re-install both Imagick and the ImageMagick binaries.