[wp-trac] [WordPress Trac] #58202: php-fpm7.4: time limit exceeded `Operation canceled' @ fatal/cache.c/GetImagePixelCache/1868.

WordPress Trac noreply at wordpress.org
Sun Jul 2 20:57:30 UTC 2023


#58202: php-fpm7.4: time limit exceeded `Operation canceled' @
fatal/cache.c/GetImagePixelCache/1868.
--------------------------+-----------------------
 Reporter:  dsar          |       Owner:  antpb
     Type:  defect (bug)  |      Status:  assigned
 Priority:  normal        |   Milestone:  6.2.3
Component:  Media         |     Version:  6.2
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+-----------------------

Comment (by soulseekah):

 @matt_fw is right.

 Consider this simple example that can be reproduced using the built-in PHP
 server. This would act as an FPM child process, handling requests without
 terminating.

 We need two files:

 crop.php, this is a simulation of running crop via the WordPress Image
 Editor API, which calls `setResourceLimit` and resets the timer.

 {{{#!php
 <?php
 Imagick::setResourceLimit(IMagick::RESOURCETYPE_TIME, 3);

 $imagick = new \Imagick('test.jpg');
 $imagick->resizeImage(500, 400, imagick::FILTER_UNDEFINED, 1, false);
 }}}


 blur.php, this is a simulation of a WordPress plugin that calls IMagick
 APIs directly without resetting the resource limit (does not call
 `setResourceLimit`).

 {{{#!php
 <?php
 $imagick = new \Imagick('test.jpg');
 $imagick->blurImage(5, 3);
 }}}

 Hit crop first. Wait for four seconds. Then hit blur. You'll trigger the
 error, because blur didn't reset the timer. Hit crop to reset the timer,
 hit blur immediately after several times until you see the message again.

 This means that using crop/resize in the Image Editor API even once will
 continue to trigger errors for all other operations that don't reset the
 limit. The default limit is 9.2233720368548E+18 seconds. Calling
 crop/resize will put to 80% of `max_execution_time` and keep it there for
 all subsequent requests until the process is restarted.

 The patch has another edge case, wherein cropping/resizing multiple images
 over a lengthy period of time via the Editor API will actually keep on
 resetting the timer, which completely defeats the purpose of aborting
 early.

 One solution would be to call `set_imagick_time_limit()` on all WordPress
 requests but only once per request, and regardless of the context as to
 constantly reset the internal ImageMagick timer.

 Another solution would be to revert the patch as @azaozz suggests, as the
 implementation is flawed (resets per operation) and breaks things for all
 subsequent requests.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/58202#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list