assert related to magick_info element deletion

Questions and postings pertaining to the development of ImageMagick, feature enhancements, and ImageMagick internals. ImageMagick source code and algorithms are discussed here. Usage questions which are too arcane for the normal user list should also be posted here.
Post Reply
MsMagicUser
Posts: 1
Joined: 2014-05-01T13:54:51-07:00
Authentication code: 6789

assert related to magick_info element deletion

Post by MsMagicUser »

I am debugging a crash (a magick assert actually) that I am experiencing in my application that uses ImageMagick, version 6.2.3. My application is multithreaded and I get an assert in the following context:
Thread 1 (Thread 0x7fa047dd2700 (LWP 24840)):
#0 0x00007fa2704d28a5 in raise () from /lib64/libc.so.6
#1 0x00007fa2704d4085 in abort () from /lib64/libc.so.6
#2 0x00007fa2704cba1e in __assert_fail_base () from /lib64/libc.so.6
#3 0x00007fa2704cbae0 in __assert_fail () from /lib64/libc.so.6
#4 0x00007fa2790f2cd0 in GetMagickThreadSupport (magick_info=0x7fa1e032d960) at magick/magick.c:763
#5 0x00007fa27908e5c6 in ReadImage (image_info=0x7fa09d690460, exception=0x7fa047dd15c0) at magick/constitute.c:444
#6 0x00007fa279062b67 in BlobToImage (image_info=0x7fa09f8265f0, blob=0x7fa0651a6310, length=101376, exception=0x7fa047dd15c0) at magick/blob.c:351
#7 0x00007fa27962d1d0 in Magick::Image::read (this=0x7fa047dd16f0, blob_=Unhandled dwarf expression opcode 0xf3) at Magick++/lib/Image.cpp:1365
#8 0x00007fa137133d52 in gst_videopro_chain (pad=Unhandled dwarf expression opcode 0xf3) at vanvideoprocess.cpp:481
#9 0x00007fa27f96c793 in gst_pad_chain_unchecked (pad=Unhandled dwarf expression opcode 0xf3) at gstpad.c:3646
#10 gst_pad_push (pad=Unhandled dwarf expression opcode 0xf3) at gstpad.c:3818
#11 0x00007fa16ca9ea5a in gst_base_transform_chain (pad=Unhandled dwarf expression opcode 0xf3) at gstbasetransform.c:1656
#12 0x00007fa27f96c793 in gst_pad_chain_unchecked (pad=Unhandled dwarf expression opcode 0xf3) at gstpad.c:3646
#13 gst_pad_push (pad=Unhandled dwarf expression opcode 0xf3) at gstpad.c:3818
#14 0x00007fa16ca9ea5a in gst_base_transform_chain (pad=Unhandled dwarf expression opcode 0xf3) at gstbasetransform.c:1656
#15 0x00007fa27f96c793 in gst_pad_chain_unchecked (pad=Unhandled dwarf expression opcode 0xf3) at gstpad.c:3646
#16 gst_pad_push (pad=Unhandled dwarf expression opcode 0xf3) at gstpad.c:3818
#17 0x00007fa1542c131b in gst_ffmpegdec_frame (ffmpegdec=0x7fa1798370f0, data=Unhandled dwarf expression opcode 0xf3) at gstffmpegdec.c:2264
#18 0x00007fa1542c3d9e in gst_ffmpegdec_chain (pad=Unhandled dwarf expression opcode 0xf3) at gstffmpegdec.c:2610
#19 0x00007fa27f96c793 in gst_pad_chain_unchecked (pad=Unhandled dwarf expression opcode 0xf3) at gstpad.c:3646
#20 gst_pad_push (pad=Unhandled dwarf expression opcode 0xf3) at gstpad.c:3818
#21 0x00007fa154d91c72 in gst_qtdemux_loop_state_movie (pad=0x7fa17927acf0) at qtdemux.c:1943
#22 gst_qtdemux_loop (pad=0x7fa17927acf0) at qtdemux.c:1978
#23 0x00007fa27f986687 in gst_task_func (task=0x7fa1cc1042a0, tclass=Unhandled dwarf expression opcode 0xf3) at gsttask.c:192
#24 0x00007fa273c53e62 in g_thread_pool_thread_proxy (data=Unhandled dwarf expression opcode 0xf3) at gthreadpool.c:265
#25 0x00007fa273c51994 in g_thread_create_proxy (data=0x7fa0d0393df0) at gthread.c:635
#26 0x00007fa271fe8851 in start_thread () from /lib64/libpthread.so.0
#27 0x00007fa27058890d in clone () from /lib64/libc.so.6
I have debugged this and I believe that the bug is related to the fact that the splayTree behind the 'magick_info' nodes has an element removed. Then; subsequently, another thread makes an access to that removed element, and we get to the assert! I have traced; using gdb all of the additions and deletions of the elements in this magick_info splay tree and I have confirmed that the element representing 'RGB' get added, then it get removed and then my application crashes. The stack below shows the context in which the element is removed from the splay tree:
Breakpoint 3, RemoveNodeFromSplayTree (splay_info=0x7fff280378d0, key=Unhandled dwarf expression opcode 0xf3) at magick/splay-tree.c:961
961 in magick/splay-tree.c
#0 RemoveNodeFromSplayTree (splay_info=0x7fff280378d0, key=Unhandled dwarf expression opcode 0xf3) at magick/splay-tree.c:961
#1 0x00007ffebd5a0380 in UnregisterRGBImage () at coders/rgb.c:645
#2 0x00007ffff12f2772 in UnregisterModule (module_info=0x7fff1435a9e0, exception=0x7ffec9fe6340) at magick/module.c:1401
#3 0x00007ffff12f284b in DestroyModuleNode (module_info=0x7fff1435a9e0) at magick/module.c:860
#4 0x00007ffff135cb74 in AddValueToSplayTree (splay_info=0x7fff28053a60, key=0x7ffeec0dd970, value=0x7ffeec0432c0) at magick/splay-tree.c:175
#5 0x00007ffff12f360e in RegisterModule (module=Unhandled dwarf expression opcode 0xf3) at magick/module.c:1212
#6 OpenModule (module=Unhandled dwarf expression opcode 0xf3) at magick/module.c:1076
#7 0x00007ffff12f1770 in GetMagickInfo (name=0x7ffec9feb4b0 "RGBA", exception=0x7ffec9feb470) at magick/magick.c:502
#8 0x00007ffff12f19ce in IsMagickConflict (magick=0x7ffec9feb4b0 "RGBA") at magick/magick.c:1079
#9 0x00007ffff136ba05 in GetPathComponent (path=Unhandled dwarf expression opcode 0xf3) at magick/utility.c:859
#10 0x00007ffff12e8a27 in SetImageInfo (image_info=0x7ffeec0a3600, rectify=MagickFalse, exception=0x7ffec9ff35c0) at magick/image.c:2710
#11 0x00007ffff1260bc5 in BlobToImage (image_info=0x7ffeec099900, blob=0x7ffeec0c3cb0, length=101376, exception=0x7ffec9ff35c0) at magick/blob.c:335
#12 0x00007ffff182b1d0 in Magick::Image::read (this=0x7ffec9ff36f0, blob_=Unhandled dwarf expression opcode 0xf3) at Magick++/lib/Image.cpp:1365
#13 0x00007fff080a5d52 in gst_videopro_chain (pad=Unhandled dwarf expression opcode 0xf3) at vanvideoprocess.cpp:481
#14 0x00007ffff7b6a793 in gst_pad_chain_unchecked (pad=Unhandled dwarf expression opcode 0xf3) at gstpad.c:3646
#15 gst_pad_push (pad=Unhandled dwarf expression opcode 0xf3) at gstpad.c:3818
#16 0x00007fff704eaa5a in gst_base_transform_chain (pad=Unhandled dwarf expression opcode 0xf3) at gstbasetransform.c:1656
#17 0x00007ffff7b6a793 in gst_pad_chain_unchecked (pad=Unhandled dwarf expression opcode 0xf3) at gstpad.c:3646
#18 gst_pad_push (pad=Unhandled dwarf expression opcode 0xf3) at gstpad.c:3818
#19 0x00007fff704eaa5a in gst_base_transform_chain (pad=Unhandled dwarf expression opcode 0xf3) at gstbasetransform.c:1656
#20 0x00007ffff7b6a793 in gst_pad_chain_unchecked (pad=Unhandled dwarf expression opcode 0xf3) at gstpad.c:3646
#21 gst_pad_push (pad=Unhandled dwarf expression opcode 0xf3) at gstpad.c:3818
#22 0x00007fff32ef031b in gst_ffmpegdec_frame (ffmpegdec=0x7ffed0046010, data=Unhandled dwarf expression opcode 0xf3) at gstffmpegdec.c:2264
#23 0x00007fff32ef2d9e in gst_ffmpegdec_chain (pad=Unhandled dwarf expression opcode 0xf3) at gstffmpegdec.c:2610
#24 0x00007ffff7b6a793 in gst_pad_chain_unchecked (pad=Unhandled dwarf expression opcode 0xf3) at gstpad.c:3646
#25 gst_pad_push (pad=Unhandled dwarf expression opcode 0xf3) at gstpad.c:3818
#26 0x00007fff338bfc72 in gst_qtdemux_loop_state_movie (pad=0x7fff4403b2e0) at qtdemux.c:1943
#27 gst_qtdemux_loop (pad=0x7fff4403b2e0) at qtdemux.c:1978
#28 0x00007ffff7b84687 in gst_task_func (task=0x7ffed0169840, tclass=Unhandled dwarf expression opcode 0xf3) at gsttask.c:192
I have some questions regarding this.

1: Is it normal that an element gets removed?
2: If so, then how does the library deal with the fact that another thread ~may~ be accessing that element?

I have looked at the changelog as well as performed a few searches in the bug forum. I haven't found anything indicating that others have experienced this same issue. I would appreciate any insight that anyone could provide.

Thank you in Advance,
Mark S
User avatar
magick
Site Admin
Posts: 11064
Joined: 2003-05-31T11:32:55-07:00

Re: assert related to magick_info element deletion

Post by magick »

Upgrade! In the recent release we spent a fair amount of time rewriting sections of ImageMagick to help protect against threading issues. If you can reproduce your problem with ImageMagick 6.8.9-0, let us know and we will investigate further.
Post Reply