After upgrading to current dev version I have this error when uploading new images:

Fatal error: Maximum execution time of 30 seconds exceeded in /.../includes/image.inc on line 246

With 1.3 the error was about the same. 1.0 is working fine on other sites on the same server. PHP 5.1.6

What could it be?

Comments

drewish’s picture

Version: 5.x-1.x-dev » 5.x-1.3

it's running out of time resizing images. you might want to try either using the imagemagick.inc toolkit or extending the script timelimit. also you shouldn't be running the 1.3 release, it's really buggy upgrade to the -dev until 1.4 is released.

drewish’s picture

Status: Active » Fixed
soupp’s picture

Status: Fixed » Active

Thanks drewish, but 1.3 gives the same error but on line 285. Image is just about 650x300px jpg (~150kb). Other Drupal install on the same server does the same job in a second... but with image.module 1.0 or 1.1. What could be the clue then?

drewish’s picture

Status: Active » Fixed

like i said, don't use the 1.3 release. use the -dev release until 1.4 comes out. if you can replicate the problem on the latest -dev release re-open this issue.

soupp’s picture

Version: 5.x-1.3 » 5.x-1.x-dev
Status: Fixed » Active

We haven't been completely attentive to each other ;)

So the error is still there in current -dev version!

History: 1.1 (no errors) -> upgrade to 1.3 (error on line 285) -> upgrade to today's -dev (error on line 246).

Unfortunately I didn't make a dump before upgrades (so I can't replicate upgrade 1.1 -> dev) but db upgrades should not make any difference here. I would not say that the server config is any special (quite average and otherwise stable shared host, no imagemagick though). If you need more server info I can send a link or html (php_info(), PM only).

drewish’s picture

sorry if i'm a bit terse and quick to close an issue but there's a lot of bugs in 1.3 that have been fixed in -dev and i don't have time to try to sort out which is which. so if issues can't be replicated in the -dev release i'm not going to deal with them right now. i apologize for not making that clear in my first post when i told you to upgrade.

image.inc:246 is:

imageCopyResampled($res, $im, 0, 0, 0, 0, $width, $height, $info['width'], $info['height']);

so it's very clearly dieing in the middle of the generation of a derivative image.

image.inc:285 doesn't make much sense as it's:

return FALSE;

which shouldn't take any time... and indicates that your server doesn't support GD... so i'm going to disregard that for now.

do you get any messages indicating that the derivative images are being rebuilt?

soupp’s picture

Moving on: just upgraded to 1.4 and the result now is say 5 mins of waiting (that was max to hit stop button with browser) and nothing happens. No result / error messages. But there is a temp file created in tmp dir. If I stop the browser and reload node/add/image I see the message:
-----------
The selected file /home/.../httpdocs/files/tmp/tmp_iiknJz could not be copied.
You must upload an image.
-----------

All paths/permissions are setup fine in Drupal and on server. Might it be PHP (5.1.6) / GD / other PHP extension issue?

drewish’s picture

have you tried creating images with the image_import.module? does that work? could you try the imagemagick toolkit?

soupp’s picture

sorry forgot to add: "do you get any messages indicating that the derivative images are being rebuilt?" - there were nothing like that.

soupp’s picture

Just tried an image_import. The result: images are added but no thumbs. Full images instead of thumbs. Looks quite cool / designish (cropped by css block model) :) but really not what it should be.

So what I think the issue here is on stage of creating derivatives of an image.

And Drupal sees no imagemagick installed unfortunately. But it is on server as far as I know.

drewish’s picture

by drupal doesn't see imagemagick, do you mean that it doesn't list the toolkit or it can't find the convert binary? to install the toolkit you need to copy the image.imagemagick.inc toolkit into the /includes directory. if it can't find the binary then you should ask your ISP where' it's located.

drewish’s picture

it sound like http://drupal.org/node/158334 might be part of the problem

soupp’s picture

Hm... good point about uppercase (http://drupal.org/node/158334). It is uppercase (IMG_ZZZ.jpg). But there are no deviates created (only original files in files/images). OK. Selected images to rebuild thumbs. After hit submit there is a message:
---------------
Rebuilding IMG_7808's resized images.
Rebuilding IMG_8436's resized images.
Rebuilding IMG_7802's resized images.
Rebuilding IMG_8409's resized images.
Rebuilding IMG_7801's resized images.
Rebuilding IMG_8247's resized images.
Rebuilding IMG_7800's resized images.
Rebuilding IMG_7810's resized images.
Rebuilding IMG_8450's resized images.
Rebuilding IMG_7798's resized images.
Rebuilding IMG_7794's resized images.
The update has been performed.
---------------
AND then (all of a sudden) repeating:
---------------
warning: Illegal offset type in isset or empty in /home/.../httpdocs/modules/taxonomy/taxonomy.module on line 1150.
warning: Illegal offset type in /home/.../httpdocs/modules/taxonomy/taxonomy.module on line 1151.
---------------

The resize was good this time. But what's taxonomy doing here? (it's freetagging)

soupp’s picture

Update: not very obvious but it worked: if you hit preview first then the thumbs (and noge) are generated perfectly. Then you can submit.

Got imagemagic working but the result is the same as with GD: when hit submit it takes forever and nothing is created (node/thumb), when mass importing nodes are created but no thumbs (full images).

ricmadeira’s picture

Hmmm... I also keep getting those stupid taxonomy errors when I update thumbnails here and there. I also have two freetagging fields for each image... hmmm... might we have stumbled on another bug?

drewish’s picture

i just tested it with a freetagging vocabulary and it worked fine for me, both specifying terms and leaving it blank.

what version of PHP are you guys using?

soupp’s picture

php 5.1.6 on the troubled box

ricmadeira’s picture

PHP 5.2.3 for me. I'm also using pathauto & acidfree.

I just did a "Rebuild image thumbnails" @ /admin/content/node on a few images one at a time. For each one of them I get all these errors after the "Rebuilding xxxx's resized images." and "The update has been performed" messages:

warning: Illegal offset type in isset or empty in /home/abreoj/public_html/modules/taxonomy/taxonomy.module on line 1171. 
warning: Illegal offset type in /home/abreoj/public_html/modules/taxonomy/taxonomy.module on line 1172. 
warning: Illegal offset type in /home/abreoj/public_html/modules/taxonomy/taxonomy.module on line 1175. 
: Object of class stdClass could not be converted to string in /home/abreoj/public_html/modules/pathauto/pathauto_node.inc on line 223. 
warning: Illegal offset type in isset or empty in /home/abreoj/public_html/modules/taxonomy/taxonomy.module on line 1171. 
warning: Illegal offset type in /home/abreoj/public_html/modules/taxonomy/taxonomy.module on line 1172. 
warning: Illegal offset type in /home/abreoj/public_html/modules/taxonomy/taxonomy.module on line 1175. 

The only time when I don't see any of these errors is when the image is not classified into any of my taxonomies at all. I have two freetagging categories and a non-freetag third category for each image (all three are of optional use); plus, I think acidfree does it magic using a taxonomy too... at least I get these same errors when I rebuild images that do not belong in any of my taxonomies but belong to an acidfree album.

I had these errors before, with regular Drupal 5.1, but a week ago I updated my Drupal to a 5.1-dev version, so my current line numbers for the taxonomy.module errors might be slightly off from your sites. My taxonomy.module is version 1.330.2.7 2007/06/17 02:00:51.

Here's the place in taxonomy.module where the errors occur:

/**
 * Return the term object matching a term ID.
 *
 * @param $tid
 *   A term's ID
 *
 * @return Object
 *   A term object. Results are statically cached.
 */
function taxonomy_get_term($tid) {
  static $terms = array();

  if (!isset($terms[$tid])) {
    $terms[$tid] = db_fetch_object(db_query('SELECT * FROM {term_data} WHERE tid = %d', $tid));
  }

  return $terms[$tid];
}

Line 1171 is line with the if and !isset.

mr.cake’s picture

I had the same problem with uppercase filenames and solved it by using lowercase filenames. but the bug seems to come from pathauto. deactivating it also worked for me.

drewish’s picture

mr.cake, you might want to try out the -dev release.

jimbotron’s picture

Hi Guys,

Perhaps the following may help someone else:

I had a similar problem which was rectified by going to the latest dev release. I also had an issue where the permissions of the images were incorrect and had to be modified by hand. This latest release also increases speed dramatically.

Redhat Enterprise Linux 5
Apache 2.2.3
PHP 5.1.3

Thank you for the improvements.

Hetta’s picture

Status: Active » Fixed
Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.