Fatal error: Maximum execution time of 30 seconds exceeded

Rain

Just uploaded a bunch of images (~7000 images in ~250 albums) through ftp and as I went to the Zenphoto installation, I started getting this error while the galleries loaded on the index page:

`Fatal error: Maximum execution time of 30 seconds exceeded in /***/galleries/zp-core/exif/exif.php on line 723`

It loads some of the album thumbnails, and then in the place of one (random) thumbnail presents that error.

The error also happens when viewing the "Edit" tab in the admin backend. Also randomly.

(I have removed the code that pulls EXIF data from all pages of the theme.)

I'm totally baffled. Any help please?

sbillard

There is an image which is not being processed correctly by zenphoto. Either because the image is corrupt or because there is a bug in the zenphoto EXIF handling. Since you have not said your zenphoto version/release first try the nightly build. If there is still a problem, identify the image where the processing stopped, create a ticket, and attach that image to the ticket.

southdreamz

If you don't want use EXIF data then comment out! Yesterday i have uploaded more than ~50,000 images in ~1200 albums without any problem and i have enabled static cache plugin & commented EXIF functions.

Rain

I don't use EXIF data and have removed them from the templates. But I have a stinkin' feeling that's not enough as Zenphoto still tries to get the data from each image?

I'm going through all my images today -- it turns out there's plenty of corrupted ones indeed that apparently did not download properly.

Rain

Removing all the corrupt images fixes the issue indeed. Which brings up a question though -- is it possible to implement some kind of a 'fix' so a single corrupt image wouldn't potentially screw up the displaying of the entire gallery?

sbillard

Yes, probably. currently zenphoto does not do any error trapping. I've not done that in PHP, so it will take some research.

claymen

Was there any movement on this? It's a pretty critical bug IMO to allow it to break an entire gallery simply because of one bad image. What about at least allowing the EXIF reading to be completely turned off without the need to hack away at the source.

sbillard

PHP version 5 and greater allow for trapping of errors. EXIF handling has been enhanced so that if you have PHP 5 or greater it will trap out the errors. Sorry, PHP version 4 does not provide any help.

spencersokol

Running Zenphoto version 1.2.4 [3716] (Official Build) with PHP version: 5.2.8 and MySQL version: 5.0.67, I noticed this problem will still occur on images with no EXIF header. I had a number of photos that I had scanned and uploaded that naturally had no EXIF info which was causing this error. I found a utility to mass write blank EXIF records and it solved the issue. Additional error handling may be needed.

sbillard

There have been a number of improvements in EXIF processing in the 1.2.5 releases.

omatzyo

I'm running the latest build (1.2.6 [4335]) with:
# PHP version: 5.2.6-3ubuntu4.2
# Graphics support: PHP GD library 2.0 or higher
# PHP memory limit: 160M (Note: Your server might allocate less!)
# MySQL version: 5.0.75

I have come across multiple photographs which are not corrupt, but do cause the script to hang. Even adding just one will cause it to lock. I have other photographs from the same camera taken on the same day with the same settings that do not cause this issue. From looking at the EXIF data between one working and one non-working photograph, I see no differences. The camera causing this is an Olympus u1030SW,S1030SW. (Also, I have tried setting the max time for script execution to 500, this did not help.)

`
Fatal error: Maximum execution time of 60 seconds exceeded in /var/www/zenphoto/zp-core/exif/exif.php on line 164
`
Is there anything I can to do avoid this issue, short of searching for problem photos one-by-one? Is this a known issue? Thank you!

sbillard

I would assume that this error is preventing the image from being loaded, so you should have no thumb, etc. for the images that have the problem. Most likely problem is that some construct in the EXIF data has caused the processing loop to get lost and examine the file byte by byte. There is code that attempts to detect this and abort, but maybe there are multiple instances so the detection fails.

If you have some PHP skills, you could insturment the exif.php script to record the image it is working on when it begins and ends processing. When there is an image with a begin processing and no end processing then you have your cuplpret.

omatzyo

I have located several files which do this. I only need an album with 1 of these files in it and the entirety of the application freezes, then the thumbnail for that album delivers the error (after the script times out). Oddly, some pictures from the same camera/date/batch work and some do not. Like I said though, having only one of these 'rouge' photos in the folder locks the main page.

Are you saying that I should exclude these pictures? Isn't there any way to alter the exif.php? I'm not really experienced with dealing with exif data, but I'd be happy to help in any way I can.

omatzyo

I've changed the exif.php function as follows and now it works, even displaying the correct exif information correctly; however, I'm not confident in what this has accomplished. I do not know what information is being lost in other pictures. Could you elucidate what this function is doing exactly? I arbitrarily chose to end it after 50 cycles...

`
function intel2Moto($intel) {
static $cache = array();
if (isset($cache[$intel])) {
return $cache[$intel];
}

$len = strlen($intel);
$cache[$intel] = '';
for($i = 0; $i <= $len; $i += 2) {
$cache[$intel] .= substr($intel, $len-$i, 2);
if($i==100) {
break;
}
}
return $cache[$intel];
}
`

sbillard

It handles the way numbers are stored. There are two strategies that computers use to tore numbers that are more than 8 bits long. They can store them most significant byte first or most significant byte last.

This function itself cannot be the problem. It is mearly copying the cata out a and converting it from `intel` form to `motorola` form. (I don't right now remember which is MSB first and which is LSB first.)

There is probably no loss by changing from 100 to 50. That check is to prevent the loop from going on forever. I would guess that if things are wrong at 50 they will still be wrong at 100. But without knowing actually what data is corrupt, we will not know if something is being lost. Just best guess is that your change is safe.

omatzyo

I think you misunderstood what my change was. I added the break all together. This was not there before, and according to the error, this is the function that was timing out. My question was weather this break is acceptable, and cuts out any important data? I chose 100 arbitrarily...

sbillard

I did misunderstand, but I think my answer is the same. Probably just prevents the infinite loop when the data is bad. But I really don't know what kind of data might be there. Just not likely something Zenphoto would be using given how long it seems.

snazawa

I was getting the fatal error message as well. Since I did not want to try to track down which photos might be causing the issue, I used @omatzyo's modified function above and all seems to work fine. Thanks for the workaround and I too would encourage some kind of better Exif error handling.

acrylian

I actually think that fix is in the nightly build already.