Bug#586698: graphicsmagick consumes 100% of cpu when creating thumbnails in typo3
Thomas Mayer
Version: 1.1.11-3.2+lenny1
Severity: normal
I inserted several png images in typo3 4.2.5 using typo3 backend.
When I press the "save" button in typo3 backend, several gm processes
consume 100% of the cpus. One process per image.
It seems as if gm scales the images right for the frontend: The resolution
differs from the original resolution. The corresponding page can be found
here:
http://www.slicewise.net/index.php?id=58
But I think typo3 wants to make some thumbnails and this might lead to the
problem.
I can't see any problems in the typo3 test suite, all graphics look great.
I use the current typo3 version from the repository of debian lenny.
-- System Information:
Debian Release: 5.0.4
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.9-023stab051.12-smp (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages graphicsmagick depends on:
ii libbz2-1.0 1.0.5-1 high-quality block-sorting file co
ii libc6 2.7-18lenny4 GNU C Library: Shared libraries
ii libfreetype6 2.3.7-2+lenny1 FreeType 2 font engine, shared lib
ii libgraphicsmagick1 1.1.11-3.2+lenny1 format-independent image processin
ii libice6 2:1.0.4-1 X11 Inter-Client Exchange library
ii libjasper1 1.900.1-5.1+lenny1 The JasPer JPEG-2000 runtime libra
ii libjpeg62 6b-14 The Independent JPEG Group's JPEG
ii liblcms1 1.17.dfsg-1+lenny2 Color management library
ii libpng12-0 1.2.27-2+lenny3 PNG library - runtime
ii libsm6 2:1.0.3-2 X11 Session Management library
ii libtiff4 3.8.2-11.2 Tag Image File Format (TIFF) libra
ii libwmf0.2-7 0.2.8.4-6+lenny1 Windows metafile conversion librar
ii libx11-6 2:1.1.5-2 X11 client-side library
ii libxml2 2.6.32.dfsg-5+lenny1 GNOME XML library
ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime
graphicsmagick recommends no packages.
Versions of packages graphicsmagick suggests:
pn graphicsmagick-dbg <none> (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Daniel Kobras
On Mon, Jun 21, 2010 at 06:08:25PM +0000, Thomas Mayer wrote:
> I inserted several png images in typo3 4.2.5 using typo3 backend.
>
> When I press the "save" button in typo3 backend, several gm processes
> consume 100% of the cpus. One process per image.
Could you please try to get hold of the full command line typo3 is using, and
also make available one of the original images used as input when the problem
occurred? For how long did it hog the CPUs? Right now, it's not clear to me
whether this is a bug in GraphicsMagick, or just typo3 starting a
time-consuming task.
Regards,
Daniel.
Bob Friesenhahn
> Hi!
>
> On Mon, Jun 21, 2010 at 06:08:25PM +0000, Thomas Mayer wrote:
>> I inserted several png images in typo3 4.2.5 using typo3 backend.
>>
>> When I press the "save" button in typo3 backend, several gm processes
>> consume 100% of the cpus. One process per image.
>
> Could you please try to get hold of the full command line typo3 is using, and
> also make available one of the original images used as input when the problem
> occurred? For how long did it hog the CPUs? Right now, it's not clear to me
> whether this is a bug in GraphicsMagick, or just typo3 starting a
> time-consuming task.
Prior to the 1.3.8 (January 21, 2010) or 1.2.10 (January 6, 2010)
GraphicsMagick releases, there was a GraphicsMagick hang which was
noticed under TYPO3:
* Eliminate lockup due to hanging in loop while parsing malformed
sub-image specification (SourceForge issue 2886560).
The problem was triggered by a TYPO3 bug which has been fixed for a
long time now.
It may be that this bug report is for something new, but it is
worthwhile to check that it is not a re-occurance of an already known
scenario.
Bob
--
Bob Friesenhahn
bfri...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/