Docker容器上的ImageMagick生成格式错误的PNG图像答案

【问题标题】：ImageMagick on Docker container generated malformed PNG imageDocker容器上的ImageMagick生成格式错误的PNG图像
【发布时间】：2018-08-07 19:00:48
【问题描述】：

我将在这里尝试非常具体，所以这可能会很长。

目标：尝试在 Docker 容器中将 SVG 文件转换为 PNG

问题：ImageMagick 在容器中生成格式错误的 PNG 图像，而在普通机器上则正常

SVG 文件：https://jsfiddle.net/ochaws/qezxnwfo/3/

Dockerfile：

FROM ubuntu:bionic
RUN apt-get update 
ADD . /home
CMD /bin/bash

命令：$ convert mychart.svg mychart.png

主机上的结果 PNG：

容器上的结果 PNG：

不仅图像的 3/4 完全混乱，而且矩形没有填充，线条也被重新绘制。我不知道 imagemagick 是如何转换它的。

我尝试过的事情：

我。检查二进制文件差异 比较主机和容器 (ldd|md5sum) 之间的 imagemagick 及其依赖项的二进制文件，以获得可能触发可能错误的二进制文件之间的差异：

在容器上：

root@73075bf64797:/var/www/html# ldd /usr/bin/convert | grep -Eo '/(usr|lib)/.*\s' | xargs md5sum | sort
015730545ba1a5ff1e0f500ffbb651d5  /usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.3
0a2ec219b7d2050e4c0916d1dee14853  /lib/x86_64-linux-gnu/librt.so.1
24492a17e8dd9a9e853cd1cfdf5fc0a3  /usr/lib/x86_64-linux-gnu/libMagickWand-6.Q16.so.3
27ce2618cfd426b2f8eefa6536e0824c  /usr/lib/x86_64-linux-gnu/libltdl.so.7
2b7d964ae89f9782df099985e73c707b  /lib/x86_64-linux-gnu/libpcre.so.3
3b053e7e77c4a5857607de25806a6e90  /usr/lib/x86_64-linux-gnu/libfftw3.so.3
4c659326fdbac8a684298ccba999cc5c  /lib/x86_64-linux-gnu/libm.so.6
50390b2ae8aaa73c47745040f54e602f  /lib/x86_64-linux-gnu/libc.so.6
65fd13ef7996608743284fc1210113f1  /lib/x86_64-linux-gnu/libz.so.1
6809901459f3a5ca2c38add3190b539c  /lib/x86_64-linux-gnu/libbsd.so.0
724ac03acbf82b09cb490b03e1714f76  /usr/lib/x86_64-linux-gnu/libxcb.so.1
7444e02ab2de54f5503acd626c99d4b0  /lib/x86_64-linux-gnu/libgcc_s.so.1
79381074c86ff3a86f4fd442892a99b3  /usr/lib/x86_64-linux-gnu/libfreetype.so.6
a01caee197b17c9586543a876bf6fd0a  /lib/x86_64-linux-gnu/libdl.so.2
a1282326e753a31f0810161768948999  /usr/lib/x86_64-linux-gnu/libX11.so.6
a4566a3af75553930d970377533deb14  /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
a5300acb8e2e5c04a078fa0f6949f18a  /usr/lib/x86_64-linux-gnu/libfontconfig.so.1
ae99268b6d518fb9b24c234ccfa6f791  /lib/x86_64-linux-gnu/libpthread.so.0
b34ed25caf9e14f71b7b41af34f1890f  /usr/lib/x86_64-linux-gnu/libpng16.so.16
b4cbe573b069bfd23039332e6cc113b7  /usr/lib/x86_64-linux-gnu/libgomp.so.1
b62a4e6888012062c60c41dea847f565  /lib/x86_64-linux-gnu/libexpat.so.1
b880122a03e775f6f5c548167e7bf179  /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
ba7877e10828c3985c6246381569e58c  /lib/x86_64-linux-gnu/libbz2.so.1.0
c265ba007d786e5086e209e6260839ce  /usr/lib/x86_64-linux-gnu/libXau.so.6
c599b6af9146a6730ce1a35f63d0233f  /usr/lib/x86_64-linux-gnu/libXext.so.6
cacf55a898630c666e17233bbcd174f5  /usr/lib/x86_64-linux-gnu/liblqr-1.so.0
df13a9c0be51bcb5ba09787c6594e264  /usr/lib/x86_64-linux-gnu/liblcms2.so.2

在主机上：

[0|0] /home $ ldd /usr/bin/convert | grep -Eo '/(usr|lib)/.*\s' | xargs md5sum | sort
015730545ba1a5ff1e0f500ffbb651d5  /usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.3
0a2ec219b7d2050e4c0916d1dee14853  /lib/x86_64-linux-gnu/librt.so.1
24492a17e8dd9a9e853cd1cfdf5fc0a3  /usr/lib/x86_64-linux-gnu/libMagickWand-6.Q16.so.3
27ce2618cfd426b2f8eefa6536e0824c  /usr/lib/x86_64-linux-gnu/libltdl.so.7
2b7d964ae89f9782df099985e73c707b  /lib/x86_64-linux-gnu/libpcre.so.3
3b053e7e77c4a5857607de25806a6e90  /usr/lib/x86_64-linux-gnu/libfftw3.so.3
4c659326fdbac8a684298ccba999cc5c  /lib/x86_64-linux-gnu/libm.so.6
50390b2ae8aaa73c47745040f54e602f  /lib/x86_64-linux-gnu/libc.so.6
65fd13ef7996608743284fc1210113f1  /lib/x86_64-linux-gnu/libz.so.1
6809901459f3a5ca2c38add3190b539c  /lib/x86_64-linux-gnu/libbsd.so.0
724ac03acbf82b09cb490b03e1714f76  /usr/lib/x86_64-linux-gnu/libxcb.so.1
7444e02ab2de54f5503acd626c99d4b0  /lib/x86_64-linux-gnu/libgcc_s.so.1
79381074c86ff3a86f4fd442892a99b3  /usr/lib/x86_64-linux-gnu/libfreetype.so.6
a01caee197b17c9586543a876bf6fd0a  /lib/x86_64-linux-gnu/libdl.so.2
a1282326e753a31f0810161768948999  /usr/lib/x86_64-linux-gnu/libX11.so.6
a4566a3af75553930d970377533deb14  /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
a5300acb8e2e5c04a078fa0f6949f18a  /usr/lib/x86_64-linux-gnu/libfontconfig.so.1
ae99268b6d518fb9b24c234ccfa6f791  /lib/x86_64-linux-gnu/libpthread.so.0
b34ed25caf9e14f71b7b41af34f1890f  /usr/lib/x86_64-linux-gnu/libpng16.so.16
b4cbe573b069bfd23039332e6cc113b7  /usr/lib/x86_64-linux-gnu/libgomp.so.1
b62a4e6888012062c60c41dea847f565  /lib/x86_64-linux-gnu/libexpat.so.1
b880122a03e775f6f5c548167e7bf179  /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
ba7877e10828c3985c6246381569e58c  /lib/x86_64-linux-gnu/libbz2.so.1.0
c265ba007d786e5086e209e6260839ce  /usr/lib/x86_64-linux-gnu/libXau.so.6
c599b6af9146a6730ce1a35f63d0233f  /usr/lib/x86_64-linux-gnu/libXext.so.6
cacf55a898630c666e17233bbcd174f5  /usr/lib/x86_64-linux-gnu/liblqr-1.so.0
df13a9c0be51bcb5ba09787c6594e264  /usr/lib/x86_64-linux-gnu/liblcms2.so.2

结论：二进制文件在主机和容器中完全相同，所以我想我可以推出。

二。使用 valgrind 检查两种环境中的内存行为：

在容器上：

root@b0b319995ed0:/home# valgrind --leak-check=full convert blue_charts.svg blue_charts.png
==1390== Memcheck, a memory error detector
==1390== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1390== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==1390== Command: convert blue_charts.svg blue_charts.png
==1390== 
==1390== 
==1390== HEAP SUMMARY:
==1390==     in use at exit: 191,228 bytes in 2,905 blocks
==1390==   total heap usage: 359,830 allocs, 356,925 frees, 146,363,268 bytes allocated
==1390== 
==1390== 288 (256 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record 85 of 129
==1390==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1390==    by 0x628E8ED: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.10.1)
==1390==    by 0x628F096: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.10.1)
==1390==    by 0x6290377: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.10.1)
==1390==    by 0x62959C3: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.10.1)
==1390==    by 0x8011DE7: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.6.7)
==1390==    by 0x8012BBB: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.6.7)
==1390==    by 0x8010802: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.6.7)
==1390==    by 0x80114C4: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.6.7)
==1390==    by 0x801508C: XML_ParseBuffer (in /lib/x86_64-linux-gnu/libexpat.so.1.6.7)
==1390==    by 0x6294B42: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.10.1)
==1390==    by 0x6294F75: FcConfigParseAndLoad (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.10.1)
==1390== 
==1390== 912 bytes in 3 blocks are possibly lost in loss record 100 of 129
==1390==    at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1390==    by 0x40134A6: allocate_dtv (dl-tls.c:286)
==1390==    by 0x40134A6: _dl_allocate_tls (dl-tls.c:530)
==1390==    by 0x7ADA227: allocate_stack (allocatestack.c:627)
==1390==    by 0x7ADA227: pthread_create@@GLIBC_2.2.5 (pthread_create.c:644)
==1390==    by 0x76A1209: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==1390==    by 0x76980DD: GOMP_parallel (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==1390==    by 0x4F5A1D0: SetImageOpacity (in /usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.3.0.0)
==1390==    by 0x4E98930: SetImageAlphaChannel (in /usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.3.0.0)
==1390==    by 0x4EFAD4D: ??? (in /usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.3.0.0)
==1390==    by 0x4F0465B: DrawPrimitive (in /usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.3.0.0)
==1390==    by 0x4F0674C: DrawImage (in /usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.3.0.0)
==1390==    by 0xDA1636F: ???
==1390==    by 0x4EC098E: ReadImage (in /usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.3.0.0)
==1390== 
==1390== LEAK SUMMARY:
==1390==    definitely lost: 256 bytes in 1 blocks
==1390==    indirectly lost: 32 bytes in 1 blocks
==1390==      possibly lost: 912 bytes in 3 blocks
==1390==    still reachable: 190,028 bytes in 2,900 blocks
==1390==         suppressed: 0 bytes in 0 blocks
==1390== Reachable blocks (those to which a pointer was found) are not shown.
==1390== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==1390== 
==1390== For counts of detected and suppressed errors, rerun with: -v
==1390== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

在主机上：

[0|0] /home $ valgrind --leak-check=full convert blue_charts.svg blue_charts_local.png 
==17898== Memcheck, a memory error detector
==17898== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==17898== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==17898== Command: convert blue_charts.svg blue_charts_local.png
==17898== 
==17898== 
==17898== HEAP SUMMARY:
==17898==     in use at exit: 98,349 bytes in 23 blocks
==17898==   total heap usage: 4,253 allocs, 4,230 frees, 6,204,037 bytes allocated
==17898== 
==17898== LEAK SUMMARY:
==17898==    definitely lost: 0 bytes in 0 blocks
==17898==    indirectly lost: 0 bytes in 0 blocks
==17898==      possibly lost: 0 bytes in 0 blocks
==17898==    still reachable: 98,349 bytes in 23 blocks
==17898==         suppressed: 0 bytes in 0 blocks
==17898== Reachable blocks (those to which a pointer was found) are not shown.
==17898== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==17898== 
==17898== For counts of detected and suppressed errors, rerun with: -v
==17898== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

结论：与主机（6,204,037 字节）相比，容器上的 imagemagick 占用了大量内存（146,363,268 字节）。此外，在容器上运行时，libfontconfig 和 libMagickCore-6.Q16 存在一些内存泄漏，而且我不知道它们在哪里（不能在 Docker 中运行 GDB 或 strace），而且我不太有动力去下去这条路，因为相同的二进制文件表现得很奇怪，因为容器是唯一的区别。

对于大文本，我很抱歉，但我没有选项来调试它。有什么帮助吗？

【问题讨论】：

你检查两台机器上是否安装了相同的字体？
Imagemagick 可以使用自己的内部 SVG 渲染器 (MSVG/XML) 或 RSVG 委托或 Inkscape（以提高质量和准确性）。一种可能性是您仅在 Docker 上使用 MSVG，但在您的单独系统外部使用其他渲染器之一。检查您的系统和 Docker 上安装了哪些委托。 convert -list format 应该向您显示 SVG 返回行上正在使用的渲染器。
SVG 文件中还有很多错误/问题。无法解析的剪辑路径、样式冲突（例如style="fill: gray;" fill="none"）、缺少必需的属性等。 SVG 是如何生成的？
抱歉耽搁了，我会在今天晚些时候回复每个人
@fmw42，这是 'convert -list format | 的输出grep -i svg': MSVG SVG rw+ ImageMagick 自己的 SVG 内部渲染器 SVG SVG rw+ Scalable Vector Graphics (XML 2.9.4) SVGZ SVG rw+ Compressed Scalable Vector Graphics (XML 2.9.4) 两种环境...

标签： linux docker memory memory-leaks imagemagick

【解决方案1】：

我也有同样的问题。使用 Docker 时图像格式错误，因为容器尚未安装 Inkscape。显然 Imagemagic 使用 Inkscape 来转换路径上的 SVG。

所以将以下行添加到Dockerfile 解决问题：

RUN apt-get update && apt-get -y install inkscape

Imagemagic 论坛上有more information。

【讨论】：