#305 WriteBlob: Assertion `image->blob->type != UndefinedStream' failed.

[drus]

1.3.21
magick/blob.c:4311: WriteBlob: Assertion `image->blob->type != UndefinedStream' failed.

[Bob Friesenhahn]

This is a generic assertion which occurs if WiteBlob is called when the image blob is not opened (e.g. via OpenBlob(), which is internally how files are opened). Taken by itself, the bug report is not helpful.

Are you able to provide more information to us about the command line used, or ABI calling sequence, and possibly input files, which lead up to this? What was the input file format and what was done prior to invoking WriteBlob?

[Bob Friesenhahn]

Information needed to diagnose this issue was not provided.

[drus]

sorry, was away...
call of GM is a part of Wt library, i can collect more info about GM usage.

Disassembler:
32 [1] in ../nptl/sysdeps/unix/sysv/linux/raise.c
0x7ffff6276c90 64 8b 04 25 d4 02 00 00 mov %fs:0x2d4,%eax
0x7ffff6276c98 <+0x0008> 89 c1 mov %eax,%ecx
33 [1] in ../nptl/sysdeps/unix/sysv/linux/raise.c
0x7ffff6276c9a <+0x000a> 64 8b 34 25 d0 02 00 00 mov %fs:0x2d0,%esi
34 [1] in ../nptl/sysdeps/unix/sysv/linux/raise.c
0x7ffff6276ca2 <+0x0012> 85 f6 test %esi,%esi
0x7ffff6276ca4 <+0x0014> 75 32 jne 0x7ffff6276cd8 <__GI_raise+72>
39 [1] in ../nptl/sysdeps/unix/sysv/linux/raise.c
0x7ffff6276ca6 <+0x0016> b8 ba 00 00 00 mov $0xba,%eax
0x7ffff6276cab <+0x001b> 0f 05 syscall
0x7ffff6276cad <+0x001d> 89 c1 mov %eax,%ecx
43 [1] in ../nptl/sysdeps/unix/sysv/linux/raise.c
0x7ffff6276caf <+0x001f> 64 89 04 25 d0 02 00 00 mov %eax,%fs:0x2d0
39 [2] in ../nptl/sysdeps/unix/sysv/linux/raise.c
0x7ffff6276cb7 <+0x0027> 89 c6 mov %eax,%esi
56 [1] in ../nptl/sysdeps/unix/sysv/linux/raise.c
0x7ffff6276cb9 <+0x0029> 48 63 d7 movslq %edi,%rdx
0x7ffff6276cbc <+0x002c> 48 63 f6 movslq %esi,%rsi
0x7ffff6276cbf <+0x002f> 48 63 f9 movslq %ecx,%rdi
0x7ffff6276cc2 <+0x0032> b8 ea 00 00 00 mov $0xea,%eax
0x7ffff6276cc7 <+0x0037> 0f 05 syscall

<<<<<<<<<<======== crash on next line ========>>>>>>>>>>>>>>>
0x7ffff6276cc9 <+0x0039> 48 3d 00 f0 ff ff cmp $0xfffffffffffff000,%rax
0x7ffff6276ccf <+0x003f> 77 19 ja 0x7ffff6276cea <__GI_raise+90>
57 [1] in ../nptl/sysdeps/unix/sysv/linux/raise.c
0x7ffff6276cd1 <+0x0041> f3 c3 repz retq
0x7ffff6276cd3 <+0x0043> 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
53 [1] in ../nptl/sysdeps/unix/sysv/linux/raise.c
0x7ffff6276cd8 <+0x0048> 85 c0 test %eax,%eax
0x7ffff6276cda <+0x004a> 7f dd jg 0x7ffff6276cb9 <__GI_raise+41>

Stack:
0 __GI_raise /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.19.so 56 0x7ffff6276cc9
1 __GI_abort /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.19.so 89 0x7ffff627a0d8
2 __assert_fail_base /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.19.so 92 0x7ffff626fb86
3 __GI___assert_fail /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.19.so 101 0x7ffff626fc32
4 WriteBlob 0x7ffff49fdfce
5 ?? 0x7ffff4af992e
6 png_write_chunk_start 0x7ffff1e7e125
7 png_write_chunk 0x7ffff1e7e2fa
8 ?? 0x7ffff1e7e9bf
9 ?? 0x7ffff1e807f2
10 ?? 0x7ffff1e80c6e
11 ?? 0x7ffff1e810ad
12 png_write_row 0x7ffff1e84c29
13 ?? 0x7ffff4affb17
14 ?? 0x7ffff4b0195b
15 WriteImage 0x7ffff4a3d4f9
16 ImageToBlob 0x7ffff49fc768
17 ?? 0x7ffff79d6e30
18 ??

What need to do?

[Bob Friesenhahn]

You should install debug versions of the libraries. Assuming that this comes from a Linux distribution, check if there are "debug" versions of the libraries available. Then try to reproduce the problem to produce a core dump. The gdb program can be used to obtain a backtrace along with all the function arguments provided.

It looks like there was a request to write the image in PNG format to an in-memory blob (linear chunk of memory) and for some reason the blob was not "open" when the PNG encoder tried to write to it.

[drus]

possibly i found bug.
This section in Wt code use multithreading.

ImageInfo info;
GetImageInfo(&info);

ExceptionInfo exception;
GetExceptionInfo(&exception);

std::size_t size;
void *data = ImageToBlob(&info, impl_->image_, &size, &exception);

Can be ImageToBlob used multithread, without mutex?

[Bob Friesenhahn]

It is intended that ImageToBlob() can be used concurrently without adding a mutex. Currently there are no specific tests in the GraphicsMagick test suite to verify that API functions work properly when executed concurrently. While it may be possible to discover a thread safely issue via testing, it is impossible to prove that code is thread safe via testing. Instead of using testing we verify thread safety via design and analysis. If there is a threading bug in GraphicsMagick, you will need to take an active role to help discover how the problem occurs so it can be fixed.

[drus]

I can do it in September.
Let's postpone this issue.