Fork stalls when Blur() follows Resize()

[lsm]

I've written a much longer script that forks off part of a photography workflow. It runs fine without forking. But with it, the child process stalls. I've stripped it down to what may be the crux of it.

Remarkably, if you comment out either the resize or the blur operation, it works fine. As is, it stalls at the blur operation. Any idea why?

Code: Select all

#! /opt/perl/bin/perl -w

use strict;
use Image::Magick;

my $image = Image::Magick->new;
$image->Read("/tmp/image.tif");
$image->Resize(geometry=>"400x200",filter=>'Blackman');
$image->Display();
if (my $pid = fork ) {
  waitpid(0, 1);
}
elsif ($pid == 0) {
  $image->Blur(geometry=>"0x0.8");
  $image->Display();
  exit;
}

I'm including my configuration below.

Code: Select all

Host system type: x86_64-unknown-linux-gnu
Build system type: x86_64-unknown-linux-gnu

                  Option                        Value
-------------------------------------------------------------------------------
Shared libraries  --enable-shared=yes		yes
Static libraries  --enable-static=yes		yes
Module support    --with-modules=yes		yes
GNU ld            --with-gnu-ld=yes		yes
Quantum depth     --with-quantum-depth=16	16
High Dynamic Range Imagery
                  --enable-hdri=yes		yes

Delegate Configuration:
BZLIB             --with-bzlib=yes		yes
DJVU              --with-djvu=no		no
DPS               --with-dps=yes		no
FlashPIX          --with-fpx=yes		no
FontConfig        --with-fontconfig=yes		yes
FreeType          --with-freetype=yes		yes
GhostPCL          None				pcl6 (unknown)
GhostXPS          None				gxps (unknown)
Ghostscript       None				gs (8.61)
result_ghostscript_font_dir='none'
Ghostscript fonts --with-gs-font-dir=default	
Ghostscript lib   --with-gslib=yes		yes
Graphviz          --with-gvc=yes		yes
JBIG              --with-jbig=yes		no
JPEG v1           --with-jpeg=yes		yes
JPEG-2000         --with-jp2=yes		yes
LCMS              --with-lcms=yes		yes
LQR               --with-lqr=yes		no
Magick++          --with-magick-plus-plus=yes	yes
OpenEXR           --with-openexr=yes		yes
PERL              --with-perl=no		no
PNG               --with-png=yes		yes
RSVG              --with-rsvg=yes		yes
TIFF              --with-tiff=yes		yes
result_windows_font_dir='none'
Windows fonts     --with-windows-font-dir=	
WMF               --with-wmf=yes		yes
X11               --with-x=yes			yes
XML               --with-xml=yes		yes
ZLIB              --with-zlib=yes		yes

X11 Configuration:
      X_CFLAGS        = 
      X_PRE_LIBS      = -lSM -lICE
      X_LIBS          = 
      X_EXTRA_LIBS    = 

Options used to compile and link:
  PREFIX          = /opt
  EXEC-PREFIX     = /opt
  VERSION         = 6.4.1
  CC              = gcc
  CFLAGS          = -g -O2 -Wall -W -pthread -fopenmp
  MAGICK_CFLAGS   = -g -O2 -Wall -W -pthread -fopenmp
  CPPFLAGS        = -I/opt/include/ImageMagick
  PCFLAGS         = -fopenmp
  DEFS            = -DHAVE_CONFIG_H
  LDFLAGS         = -fopenmp -lfreetype -lz
  MAGICK_LDFLAGS  = -L/opt/lib -fopenmp -lfreetype -lz
  LIBS            = -lMagickCore -llcms -ltiff -lfreetype -ljpeg -lfontconfig -lXext -lSM -lICE -lX11 -lXt -lbz2 -lz -lm -lgomp -lpthread 
  CXX             = g++
  CXXFLAGS        = -g -O2 -Wall -W -pthread

[magick]

You can invoke different image processing methods on different image objects in the parent and child but not the same image object. Its an easy fix, we need to use cache views as explained here: http://www.imagemagick.org/script/archi ... .php#cache. However it may be some time before we have all the image methods converted.

[lsm]

You can invoke different image processing methods on different image objects in the parent and child but not the same image object. Its an easy fix, we need to use cache views as explained here: http://www.imagemagick.org/script/archi ... .php#cache. However it may be some time before we have all the image methods converted.

But the child process still stalls if you apply these methods to different objects. Remove either method operation, or the forking, and the code is fine.

Try this amended code, which creates a new object in the child:

Code: Select all

#! /opt/perl/bin/perl -w

use strict;
use Image::Magick;

my $image = Image::Magick->new;
$image->Read("/tmp/image.tif");
$image->Resize(geometry=>"400x200",filter=>'Blackman');
$image->Display();
if (my $pid = fork ) {
  waitpid(0, 1);
}
elsif ($pid == 0) {
  my $picture = Image::Magick->new;
  $picture->Read("/tmp/image.tif");
  $picture->Blur(geometry=>"0x0.8");
  $picture->Display();
  exit;
}

Is this application of methods -- to different objects in separate forking contexts -- somehow corrupting the module?

[magick]

The display() method does block so the first image must be killed before the second will display. We will investigate. Other methods seem to work fine (e.g. write()).