Legacy ImageMagick Discussions Archive

Hi ImageMagick-Team,

I tried some multithreaded conversions using JMagick 6.2.6-0 and ImageMagick 6.3.5-8 and observed problems with Redhat 9 and a libgomp compiled with gcc-4.2.1.
There is no problem if I am converting single-threaded.
But if there is more than one thread I always and immediately get the following problem (a hs_err_pid.log from
the JVM):

# An unexpected error has been detected by Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x87b29f3f, pid=32677, tid=278546
#
# Java VM: Java HotSpot(TM) Server VM (1.6.0_02-b05 mixed mode)
# Problematic frame:
# C [libgomp.so.1+0x4f3f]
#

C [libgomp.so.1+0x4f3f]
C [libgomp.so.1+0x45e5] GOMP_parallel_start+0x95
C [libMagick.so.10+0xdd853]
C [libMagick.so.10+0xdef63] ResizeImage+0x3a3
C [libMagick.so.10+0xdf3c5] ZoomImage+0x85
C [libJMagick.so+0xf747] Java_magick_MagickImage_zoomImage+0x8b
j magick.MagickImage.zoomImage(II)Lmagick/MagickImage;+0

I tried the same version with Fedora Core 6 and had no problems.
I investigated further and found out that on Redhat 9 HAVE_TLS (TLS==Thread Local Storage) in libgomp.h is not activated which influences wether libgomp is using pthreads or not.
On Fedora Core 6 HAVE_TLS is activated...

If you investigate further you will see that under the Redhat 9 conditions in
gcc-4.2.1/libgomp/parallel.c there is a code fragment

/* If this is a nested region, and nested regions are disabled, force
this team to use only one thread. */
if (gomp_thread()->ts.team && !gomp_nest_var)
return 1;

and here gomp_thread() seems to return NULL under multithreading which causes the crash.

Next I deacticated HAVE_TLS under Fedora Core 6 and recompiled libgomp.
The result is that I have the same behaviour as with Redhat 9...

So HAVE_TLS seems to be critical for ImageMagick in connection with OpenMP and
multithreading.

The problem is that I cant easily get rid of that Redhat 9-System.
Do you have a solution for that problem ?

E.g. should I recompile libgomp in some way?
Or could disable-openmp or similar help ?

Best Regards,

Frank

It seems OpenMP is not quite ready for prime-time, at least on some systems. To fix the problem we disable OpenMP by default with the ImageMagick-6.3.5-10 release. Download it and install or add --disable-openmp to your configure script command line and rebuild your version of ImageMagick.

Hi,

I now tried the same with --disable-openmp and get the following effects:

There seems to be a starting problem because either I get an early crash or
it runs completely stable for a long time.

The output for the early chrashes follows:
- java: magick/blob.c:3541: WriteBlob: Assertion `image->blob->type != UndefinedStream' failed. (most frequent)

- *** glibc detected *** /usr/java/j2sdk/jre/bin/java: double free or corruption (fasttop): 0x00002aaaf4283ce0 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3b1986f504]
/lib64/libc.so.6[0x3b19871cd1]
/lib64/libc.so.6(realloc+0x124)[0x3b19872da4]
/lib64/libc.so.6[0x3b1982aa44]
/lib64/libc.so.6[0x3b1982b572]
/lib64/libdl.so.2(dlerror+0x15d)[0x3b19c013dd]
/usr/local/lib/libMagick.so.10[0x2aaad8068ec7]
/usr/local/lib/libMagick.so.10[0x2aaad8066a1a]
/usr/local/lib/libMagick.so.10[0x2aaad806874f]
/usr/local/lib/libMagick.so.10(lt_dlopen+0x1d)[0x2aaad8068bad]
/usr/local/lib/libMagick.so.10(OpenModule+0x159)[0x2aaad7fde519]
/usr/local/lib/libMagick.so.10(GetMagickInfo+0x171)[0x2aaad7fdb3d1]
/usr/local/lib/libMagick.so.10(SetImageInfo+0x37c)[0x2aaad7fce45c]
/usr/local/lib/libMagick.so.10(ReadImage+0xae)[0x2aaad7f703de]

(only once)

Is it possible to initialize ImageMagick in some way to prevent this
early chrash?

Best Regards,

Frank

How can we reproduce the problem? We downloaded the latest JMagick against the latest ImageMagick and `make test' ran without complaint (Fedora Core 7).

Hi,

I created a test program for the multithread problems.
You can download it from
http://www.peperoni.de/thomas/JMagickTest.tgz

Best regards,

Frank

We're using ImageMagick 6.2.6-0 with OpenMP disabled, JMagick 6.2.6, and Java 1.5.0_12 under 32-bit Centos. So far your test cases (we're running all three) has been running for 15 minutes or more without complaint (no crashes).

I have the same problem but under windows. I'm running (on windows xp, intel t9900 dual core) 4 concurrent thread that invoke convert , jdk 1.5 , immagick 6.6.9.1 but the VM crash :

#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000bf726, pid=7620, tid=2032
#
# JRE version: 6.0_17-b04
# Java VM: Java HotSpot(TM) Client VM (14.3-b01 mixed mode, sharing windows-x86 )
# Problematic frame:
# C 0x000bf726
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

--------------- T H R E A D ---------------

Current thread (0x03279400): JavaThread "Thread-24" [_thread_in_native, id=2032, stack(0x03940000,0x03990000)]

siginfo: ExceptionCode=0xc0000005, reading address 0x03997000

Registers:
EAX=0x03b00000, EBX=0x00000000, ECX=0x00030000, EDX=0x03990000
ESP=0x0398e97c, EBP=0x0398e9a8, ESI=0x03997000, EDI=0x03b07000
EIP=0x000bf726, EFLAGS=0x00010206

Top of Stack: (sp=0x0398e97c)
0x0398e97c: 0398f16c 0398f16c 0398e9a8 0398e99c
0x0398e98c: 00000000 03990000 00037000 03b00000
0x0398e99c: 0398f16c 0398f16c 00000000 0398e9c4
0x0398e9ac: 000bf8bf 03b00000 03990000 00037000
0x0398e9bc: 00037000 03b00000 0398e9d8 000c06ed
0x0398e9cc: 03990000 000370e8 0398e9a8 0398ea10
0x0398e9dc: 000c0837 00001338 001605b0 00000018
0x0398e9ec: 00000000 00000000 00000000 00000000

Instructions: (pc=0x000bf726)
0x000bf716: 7f 04 33 c0 eb 0f 60 8b 75 0c 8b 7d 08 8b 4d 10
0x000bf726: f3 a4 61 33 c0 5f 5e 5b 5d c3 55 8b ec 83 ec 10


Stack: [0x03940000,0x03990000], sp=0x0398e97c, free space=314k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C 0x000bf726
C 0x000bf8bf
C 0x000c06ed
C 0x000c0837
C [kernel32.dll+0x19fdc]
C [kernel32.dll+0x1d63f]
C [kernel32.dll+0x2397]
C [java.dll+0x8020]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j java.lang.ProcessImpl.create(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;ZLjava/io/FileDescriptor;Ljava/io/FileDescriptor;Ljava/io/FileDescriptor;)J+0
j java.lang.ProcessImpl.<init>([Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Z)V+244
j java.lang.ProcessImpl.start([Ljava/lang/String;Ljava/util/Map;Ljava/lang/String;Z)Ljava/lang/Process;+15
j java.lang.ProcessBuilder.start()Ljava/lang/Process;+112
j org.im4java.process.ProcessStarter.startProcess(Ljava/util/LinkedList;)Ljava/lang/Process;+75
j org.im4java.process.ProcessStarter.run(Ljava/util/LinkedList;)I+9
j org.im4java.core.ImageCommand.run(Lorg/im4java/core/Operation;[Ljava/lang/Object;)V+37