Page 1 of 1

6.3.5-8: libgomp crash on Redhat 9

Posted: 2007-09-25T04:08:29-07:00
by fkarger
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

Re: 6.3.5-8: libgomp crash on Redhat 9

Posted: 2007-09-25T06:48:04-07:00
by magick
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.

Re: 6.3.5-8: libgomp crash on Redhat 9

Posted: 2007-09-25T17:02:33-07:00
by fkarger
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

Re: 6.3.5-8: libgomp crash on Redhat 9

Posted: 2007-09-25T17:23:53-07:00
by magick
How can we reproduce the problem? We downloaded the latest JMagick against the latest ImageMagick and `make test' ran without complaint (Fedora Core 7).

Re: 6.3.5-8: libgomp crash on Redhat 9

Posted: 2007-10-02T10:46:19-07:00
by fkarger
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

Re: 6.3.5-8: libgomp crash on Redhat 9

Posted: 2007-10-02T11:38:06-07:00
by magick
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).

Re: 6.3.5-8: libgomp crash on Redhat 9

Posted: 2011-03-31T08:32:49-07:00
by rday
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