graphicsmagick-bugs Mailing List for GraphicsMagick
Swiss army knife of image processing
Brought to you by:
bfriesen
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
(11) |
Jun
|
Jul
(10) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
|
Feb
|
Mar
(6) |
Apr
(3) |
May
(2) |
Jun
|
Jul
|
Aug
(9) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
2005 |
Jan
|
Feb
(1) |
Mar
|
Apr
(7) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
2006 |
Jan
(9) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(6) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
2008 |
Jan
(2) |
Feb
|
Mar
(5) |
Apr
(3) |
May
(14) |
Jun
|
Jul
(5) |
Aug
(4) |
Sep
(5) |
Oct
(3) |
Nov
(2) |
Dec
|
2010 |
Jan
|
Feb
(9) |
Mar
(11) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(3) |
Nov
|
Dec
|
2011 |
Jan
(6) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(9) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(4) |
2014 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(8) |
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
(1) |
Nov
(14) |
Dec
(6) |
2016 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(7) |
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(2) |
Dec
(31) |
2019 |
Jan
|
Feb
(13) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
From: Bob F. <bfr...@si...> - 2021-11-16 02:11:40
|
On Mon, 15 Nov 2021, Bob Friesenhahn wrote: > > As some good news, I found one system where your command resulted in an > abort. This means that I should be able to find the cause. The cause has been found. It is fixed by adding one line of code to an error case. The fix is in Mercurial changeset 16565:5ff36992c204 and is in the latest development snapshot. The underlying cause which triggered the issue is that there is no Helvetica font installed on the system. The problem is limited to the CAPTION coder. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt |
From: Bob F. <bfr...@si...> - 2021-11-16 00:48:01
|
On Thu, 11 Nov 2021, Michael Melcher wrote: > Greetings, > > when building GM statically I get the above mentioned error followed by a SIGABRT > > It does not matter whether I use an Ubuntu system as build host and build the dependencies (libpng, libtiff, libjpeg, jasper, webp, lcms2 and freetype) from their current sources or whether I use a Gentoo system as build system with "static-libs" and "pie" as useflags. As soon as I configure with LDFLAGS="-static-pie" CFLAGS="-fPIE" I get the following error: > > The build systems are docker container. Hence the root user. > >> ./gm convert -pointsize 12 -font helvetica -size 100x caption:"test" -transparent white test.png > gm: magick/render.c:1061: DestroyDrawInfo: Assertion `draw_info->signature == MagickSignature' failed. > ./gm convert: abort due to signal 6 (SIGABRT) "Abort"... > Aborted (core dumped) As some good news, I found one system where your command resulted in an abort. This means that I should be able to find the cause. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt |
From: Bob F. <bfr...@si...> - 2021-11-15 16:11:10
|
On Mon, 15 Nov 2021, Michael Melcher wrote: > Hi Bob, > > thanks for your feedback. I have just tried a hg checkout of the code and configure and build it in the same manner as before. The assertion error now occurs on both compiles. > > # LDFLAGS="-static-pie -g" CFLAGS="-fPIE -g" ./configure .... > As well as > # ./configure ... > > With PIE > # utilities/gm convert -pointsize 12 -font helvetica -size 100x caption:"test" -transparent white ../test.png > gm: magick/render.c:1061: DestroyDrawInfo: Assertion `draw_info->signature == MagickSignature' failed. > utilities/gm convert: abort due to signal 6 (SIGABRT) "Abort"... > > Without PIE > # utilities/gm convert -pointsize 12 -font helvetica -size 100x caption:"test" -transparent white ../test.png > gm: magick/render.c:1061: DestroyDrawInfo: Assertion `draw_info->signature == MagickSignature' failed. > utilities/gm convert: abort due to signal 6 (SIGABRT) "Abort"... > Aborted (core dumped) Do you actually have a "helvetica" font on your system? One does not normally have this font on Ubuntu 20.04 systems without installing additional font packages. On my system, the font file used for this is located at "/usr/share/fonts/type1/gsfonts/n019003l.pfb". Since you should have a core file, then using gdb you could do gdb utilities/gm core and then 'bt' to get a backtrace to see where the problem is occuring. It is likely that the problem is occuring due to an error and the error is not handled properly. If you add debug tracing like utilities/gm convert -debug exception,annotate,configure .... (or you could even use '-debug all') then there will be tracing which shows what the program is doing. You can do 'gm convert -list type' to list the fonts that GraphicsMagick thinks are available. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt |
From: Michael M. <mic...@fa...> - 2021-11-15 14:18:35
|
Hi Bob, thanks for your feedback. I have just tried a hg checkout of the code and configure and build it in the same manner as before. The assertion error now occurs on both compiles. # LDFLAGS="-static-pie -g" CFLAGS="-fPIE -g" ./configure .... As well as # ./configure ... With PIE # utilities/gm convert -pointsize 12 -font helvetica -size 100x caption:"test" -transparent white ../test.png gm: magick/render.c:1061: DestroyDrawInfo: Assertion `draw_info->signature == MagickSignature' failed. utilities/gm convert: abort due to signal 6 (SIGABRT) "Abort"... Without PIE # utilities/gm convert -pointsize 12 -font helvetica -size 100x caption:"test" -transparent white ../test.png gm: magick/render.c:1061: DestroyDrawInfo: Assertion `draw_info->signature == MagickSignature' failed. utilities/gm convert: abort due to signal 6 (SIGABRT) "Abort"... Aborted (core dumped) -- Freundliche Grüße Michael Melcher Linux System Administrator IT-Architektur & Support Tel.: 06 21-52 00 78 - 109 - Fax: 06 21-52 00 78 - 20 E-Mail: mic...@fa... Fasihi GmbH - Ludwig-Reichling-Straße 6 - 67059 Ludwigshafen Geschäftsführer Saeid Fasihi, Rolf Lutzer - Firmensitz Ludwigshafen a. Rh. Amtsgericht Ludwigshafen - HRB 60601 Preisträger Großer Preis des Mittelstandes 2014 Innovationspreisträger Rheinland-Pfalz 2011 Ausgezeichnet für innovative Anwendungen und Verfahren der Informations- und Kommunikationstechnologien Besuchen Sie uns auch unter Homepage: https://www.fasihi.net Link WEB inFACTORY: https://www.webinfactory.de Link Großer Preis des Mittelstandes: https://www.fasihi.net/mittelstand Link Innovationspreis: https://www.fasihi.net/innovationspreis -----Ursprüngliche Nachricht----- Von: Bob Friesenhahn <bfr...@si...> Gesendet: Freitag, 12. November 2021 16:10 An: GraphicsMagick bug reporting and discussion <gra...@li...> Betreff: Re: [GM-bugs] static build: DestroyDrawInfo: Assertion `draw_info->signature == MagickSignature' failed On Thu, 11 Nov 2021, Michael Melcher wrote: > Greetings, > > when building GM statically I get the above mentioned error followed > by a SIGABRT > > It does not matter whether I use an Ubuntu system as build host and > build the dependencies (libpng, libtiff, libjpeg, jasper, webp, > lcms2 and freetype) from their current sources or whether I use a > Gentoo system as build system with "static-libs" and "pie" as > useflags. As soon as I configure with LDFLAGS="-static-pie" > CFLAGS="-fPIE" I get the following error: Unfortunately, the 1.3.36 release is rather old. A great many issues have been fixed in the development version I am not familiar with the requirements for static PIE. Perhaps all involved static libraries need to be compiled and linked similarly? Regardless, the type of assertion encountered sounds like something which might have been corrected since the 1.3.36 release. Are you able to try a build using the latest Mercurial or snapshot version to see if the same error is encountered? I tried your command using latest code (but without the PIE options) and it did not throw an assersion. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt _______________________________________________ Graphicsmagick-bugs mailing list Gra...@li... https://lists.sourceforge.net/lists/listinfo/graphicsmagick-bugs |
From: Bob F. <bfr...@si...> - 2021-11-12 15:10:30
|
On Thu, 11 Nov 2021, Michael Melcher wrote: > Greetings, > > when building GM statically I get the above mentioned error followed by a SIGABRT > > It does not matter whether I use an Ubuntu system as build host and > build the dependencies (libpng, libtiff, libjpeg, jasper, webp, > lcms2 and freetype) from their current sources or whether I use a > Gentoo system as build system with "static-libs" and "pie" as > useflags. As soon as I configure with LDFLAGS="-static-pie" > CFLAGS="-fPIE" I get the following error: Unfortunately, the 1.3.36 release is rather old. A great many issues have been fixed in the development version I am not familiar with the requirements for static PIE. Perhaps all involved static libraries need to be compiled and linked similarly? Regardless, the type of assertion encountered sounds like something which might have been corrected since the 1.3.36 release. Are you able to try a build using the latest Mercurial or snapshot version to see if the same error is encountered? I tried your command using latest code (but without the PIE options) and it did not throw an assersion. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt |
From: Michael M. <mic...@fa...> - 2021-11-11 17:01:58
|
Greetings, when building GM statically I get the above mentioned error followed by a SIGABRT It does not matter whether I use an Ubuntu system as build host and build the dependencies (libpng, libtiff, libjpeg, jasper, webp, lcms2 and freetype) from their current sources or whether I use a Gentoo system as build system with "static-libs" and "pie" as useflags. As soon as I configure with LDFLAGS="-static-pie" CFLAGS="-fPIE" I get the following error: The build systems are docker container. Hence the root user. > ./gm convert -pointsize 12 -font helvetica -size 100x caption:"test" -transparent white test.png gm: magick/render.c:1061: DestroyDrawInfo: Assertion `draw_info->signature == MagickSignature' failed. ./gm convert: abort due to signal 6 (SIGABRT) "Abort"... Aborted (core dumped) > ldd ./gm statically linked > ./gm version GraphicsMagick 1.3.36 20201226 Q32 http://www.GraphicsMagick.org/ Copyright (C) 2002-2020 GraphicsMagick Group. Additional copyrights and licenses apply to this software. See http://www.GraphicsMagick.org/www/Copyright.html for details. Feature Support: Native Thread Safe yes Large Files (> 32 bit) yes Large Memory (> 32 bit) yes BZIP no DPS no FlashPix no FreeType no Ghostscript (Library) no JBIG no JPEG-2000 no JPEG yes Little CMS yes Loadable Modules no Solaris mtmalloc no Google perftools tcmalloc no OpenMP no PNG no TIFF no TRIO no Solaris umem no WebP yes WMF no X11 no XML no ZLIB no Host type: x86_64-pc-linux-gnu Configured using the command: ./configure '--prefix=/usr' '--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--l ocalstatedir=/var/lib' '--enable-dependency-tracking' '--disable-silent-rules' '--docdir=/usr/share/doc/graphicsmagick-1.3.36' '--htmldir=/usr/share/doc/graphicsmagick-1.3.36/html' '--with-sy sroot=/' '--libdir=/usr/lib64' '--enable-openmp' '--enable-largefile' '--disable-shared' '--enable-static' '--disable-prof' '--disable-gcov' '--disable-magick-compat' '--with-threads' '--with out-modules' '--with-quantum-depth=32' '--without-frozenpaths' '--with-magick-plus-plus' '--without-perl' '--with-perl-options=INSTALLDIRS=vendor' '--with-bzlib' '--without-dps' '--without-fp x' '--without-jbig' '--with-webp' '--with-jpeg' '--without-jp2' '--with-lcms2' '--with-lzma' '--with-png' '--with-tiff' '--with-ttf' '--without-wmf' '--with-fontpath=/usr/share/fonts' '--with -gs-font-dir=/usr/share/fonts/urw-fonts' '--with-windows-font-dir=/usr/ Final Build Parameters: CC = x86_64-pc-linux-gnu-gcc CFLAGS = -fPIE -g -Wall -pthread CPPFLAGS = -I/usr/include/freetype2 CXX = x86_64-pc-linux-gnu-g++ CXXFLAGS = -pthread LDFLAGS = -static-pie -g LIBS = -lwebp -lwebpmux -llcms2 -ljpeg -lm -lpthread The config.log gives a warning about getpwnam_r: config.log:/root/GraphicsMagick-1.3.36/conftest.c:134: warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking Not sure if that is related or not, but worth mentioning. Building without these LDFLAGS and CFLAGS I end up with a dynamically linked binary that does not run into that issue: bbe804928fbd ~/GraphicsMagick-1.3.36/utilities # ./gm convert -pointsize 12 -font helvetica -size 100x caption:"test" -transparent white test.png bbe804928fbd ~/GraphicsMagick-1.3.36/utilities # ldd ./gm linux-vdso.so.1 (0x00007fff88116000) libwebp.so.7 => /usr/lib64/libwebp.so.7 (0x00007fccc26c8000) libwebpmux.so.3 => /usr/lib64/libwebpmux.so.3 (0x00007fccc26bc000) liblcms2.so.2 => /usr/lib64/liblcms2.so.2 (0x00007fccc2659000) libtiff.so.5 => /usr/lib64/libtiff.so.5 (0x00007fccc25d6000) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fccc250f000) libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00007fccc247d000) libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007fccc2444000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fccc241c000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fccc2409000) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007fccc229d000) libz.so.1 => /lib64/libz.so.1 (0x00007fccc2283000) libzstd.so.1 => /usr/lib64/libzstd.so.1 (0x00007fccc2179000) libm.so.6 => /lib64/libm.so.6 (0x00007fccc2037000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fccc2017000) libgomp.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/libgomp.so.1 (0x00007fccc1fd3000) libc.so.6 => /lib64/libc.so.6 (0x00007fccc1e19000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fccc1e13000) /lib64/ld-linux-x86-64.so.2 (0x00007fccc297c000) bbe804928fbd ~/GraphicsMagick-1.3.36/utilities # ./gm version GraphicsMagick 1.3.36 20201226 Q32 http://www.GraphicsMagick.org/ Copyright (C) 2002-2020 GraphicsMagick Group. Additional copyrights and licenses apply to this software. See http://www.GraphicsMagick.org/www/Copyright.html for details. Feature Support: Native Thread Safe yes Large Files (> 32 bit) yes Large Memory (> 32 bit) yes BZIP yes DPS no FlashPix no FreeType yes Ghostscript (Library) no JBIG no JPEG-2000 no JPEG yes Little CMS yes Loadable Modules no Solaris mtmalloc no Google perftools tcmalloc no OpenMP yes (201511 "4.5") PNG yes TIFF yes TRIO no Solaris umem no WebP yes WMF no X11 no XML yes ZLIB yes Host type: x86_64-pc-linux-gnu Configured using the command: ./configure '--prefix=/usr' '--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--l ocalstatedir=/var/lib' '--enable-dependency-tracking' '--disable-silent-rules' '--docdir=/usr/share/doc/graphicsmagick-1.3.36' '--htmldir=/usr/share/doc/graphicsmagick-1.3.36/html' '--with-sy sroot=/' '--libdir=/usr/lib64' '--enable-openmp' '--enable-largefile' '--disable-shared' '--enable-static' '--disable-prof' '--disable-gcov' '--disable-magick-compat' '--with-threads' '--with out-modules' '--with-quantum-depth=32' '--without-frozenpaths' '--with-magick-plus-plus' '--without-perl' '--with-perl-options=INSTALLDIRS=vendor' '--with-bzlib' '--without-dps' '--without-fp x' '--without-jbig' '--with-webp' '--with-jpeg' '--without-jp2' '--with-lcms2' '--with-lzma' '--with-png' '--with-tiff' '--with-ttf' '--without-wmf' '--with-fontpath=/usr/share/fonts' '--with -gs-font-dir=/usr/share/fonts/urw-fonts' '--with-windows-font-dir=/usr/ Final Build Parameters: CC = x86_64-pc-linux-gnu-gcc CFLAGS = -fopenmp -g -O2 -Wall -pthread CPPFLAGS = -I/usr/include/freetype2 -I/usr/include/libxml2 CXX = x86_64-pc-linux-gnu-g++ CXXFLAGS = -pthread LDFLAGS = LIBS = -lwebp -lwebpmux -llcms2 -ltiff -lfreetype -ljpeg -lpng16 -llzma -lbz2 -lxml2 -lz -lzstd -lm -lpthread Am I missing out on something, or did I find a bug here? -- Freundliche Grüße Michael Melcher Linux System Administrator IT-Architektur & Support Tel.: 06 21-52 00 78 - 109 - Fax: 06 21-52 00 78 - 20 E-Mail: mic...@fa...<mailto:mic...@fa...> Fasihi GmbH - Ludwig-Reichling-Straße 6 - 67059 Ludwigshafen Geschäftsführer Saeid Fasihi, Rolf Lutzer - Firmensitz Ludwigshafen a. Rh. Amtsgericht Ludwigshafen - HRB 60601 Preisträger Großer Preis des Mittelstandes 2014 Innovationspreisträger Rheinland-Pfalz 2011 Ausgezeichnet für innovative Anwendungen und Verfahren der Informations- und Kommunikationstechnologien Besuchen Sie uns auch unter Homepage: https://www.fasihi.net<https://www.fasihi.net/> Link WEB inFACTORY: https://www.webinfactory.de<https://www.webinfactory.de/> Link Großer Preis des Mittelstandes: https://www.fasihi.net/mittelstand Link Innovationspreis: https://www.fasihi.net/innovationspreis |
From: Bob F. <bfr...@si...> - 2019-02-25 18:20:37
|
On Mon, 25 Feb 2019, Hongxu Chen wrote: > Sorry didn't notice the attachment size exceeds the allowed limit. Please > see gist link instead. > https://gist.github.com/HongxuChen/03ec5eb797af72609637fed77be86dfa Feel free to send emails with large attachments you want me to see directly to my email address. I do appreciate the open discussion on this mailing list. >> If the data races are real, they may be more relevant. >> One case is the read/write of "y_start" inside DrawPolygonPrimitive. >> For example, >> at line 5112, there is a write: >> y_start=(long) ceil(bounds.y1-0.5); >> and at line 5123 there is a read: >> for (y=y_start; y <= y_stop; y++) >> >> So the essential is that whether "y_start" (and similarly others) is >> shared. The initial value of y_start is assigned outside of OpenMP loop context and I don't see it being updated within the loop. The only possibility I could see is if OpenMP recursion is enabled (not the default) so that loops can produce subordinate loops. I am not seeing a data race here. What am I missing? Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt |
From: Hongxu C. <lef...@gm...> - 2019-02-25 13:19:41
|
Sorry didn't notice the attachment size exceeds the allowed limit. Please see gist link instead. https://gist.github.com/HongxuChen/03ec5eb797af72609637fed77be86dfa Best Regards, Hongxu On Mon, Feb 25, 2019 at 9:12 PM Hongxu Chen <lef...@gm...> wrote: > Hi Bob, > > Thanks for the update. I think your solution makes sense and > ThreadSanitizer > no longer reports on row_count and quantum_p. > It reports some others however (detailed reports are attached), but* > I'm not * > *quite sure whether they are false alarms*. > If the data races are real, they may be more relevant. > One case is the read/write of "y_start" inside DrawPolygonPrimitive. > For example, > at line 5112, there is a write: > y_start=(long) ceil(bounds.y1-0.5); > and at line 5123 there is a read: > for (y=y_start; y <= y_stop; y++) > > So the essential is that whether "y_start" (and similarly others) is > shared. > > > WARNING: ThreadSanitizer: data race (pid=20260) > Read of size 8 at 0x7fff17ab0258 by thread T3: > #0 .omp_outlined..176 > /home/ubuntu/work/GM/GM-fixed/magick/render.c:5123:14 (gm+0x645f32) > #1 __kmp_invoke_microtask > /home/ubuntu/work/openmp/openmp-4/final/runtime/src/z_Linux_asm.s:1399 > (libomp.so.5+0x7a292) > > Previous write of size 8 at 0x7fff17ab0258 by main thread: > #0 DrawPolygonPrimitive > */home/ubuntu/work/GM/GM-fixed/magick/render.c:5112*:14 (gm+0x641361) > #1 DrawPrimitive /home/ubuntu/work/GM/GM-fixed/magick/render.c:5782:15 > (gm+0x63f513) > #2 DrawImage /home/ubuntu/work/GM/GM-fixed/magick/render.c:4517:13 > (gm+0x6302c5) > #3 ReadMVGImage /home/ubuntu/work/GM/GM-fixed/coders/mvg.c:237:10 > (gm+0x8e7cb6) > #4 ReadImage /home/ubuntu/work/GM/GM-fixed/magick/constitute.c:1607:13 > (gm+0x555242) > #5 ReadSVGImage /home/ubuntu/work/GM/GM-fixed/coders/svg.c:3944:13 > (gm+0x991986) > #6 ReadImage /home/ubuntu/work/GM/GM-fixed/magick/constitute.c:1607:13 > (gm+0x555242) > #7 ConvertImageCommand > /home/ubuntu/work/GM/GM-fixed/magick/command.c:4362:22 (gm+0x4e203a) > #8 MagickCommand > /home/ubuntu/work/GM/GM-fixed/magick/command.c:8886:17 (gm+0x513492) > #9 GMCommandSingle > /home/ubuntu/work/GM/GM-fixed/magick/command.c:17408:10 (gm+0x539161) > #10 GMCommand /home/ubuntu/work/GM/GM-fixed/magick/command.c:17461:16 > (gm+0x538e05) > #11 main /home/ubuntu/work/GM/GM-fixed/utilities/gm.c:61:10 > (gm+0x4c220b) > > Location is stack of main thread. > > Thread T3 (tid=20264, running) created by main thread at: > #0 pthread_create <null> (gm+0x433446) > #1 __kmp_create_worker > /home/ubuntu/work/openmp/openmp-4/final/runtime/src/z_Linux_util.cpp:958:14 > (libomp.so.5+0x6ef74) > #2 DrawPrimitive /home/ubuntu/work/GM/GM-fixed/magick/render.c:5782:15 > (gm+0x63f513) > #3 DrawImage /home/ubuntu/work/GM/GM-fixed/magick/render.c:4517:13 > (gm+0x6302c5) > #4 ReadMVGImage /home/ubuntu/work/GM/GM-fixed/coders/mvg.c:237:10 > (gm+0x8e7cb6) > #5 ReadImage /home/ubuntu/work/GM/GM-fixed/magick/constitute.c:1607:13 > (gm+0x555242) > #6 ReadSVGImage /home/ubuntu/work/GM/GM-fixed/coders/svg.c:3944:13 > (gm+0x991986) > #7 ReadImage /home/ubuntu/work/GM/GM-fixed/magick/constitute.c:1607:13 > (gm+0x555242) > #8 ConvertImageCommand > /home/ubuntu/work/GM/GM-fixed/magick/command.c:4362:22 (gm+0x4e203a) > #9 MagickCommand > /home/ubuntu/work/GM/GM-fixed/magick/command.c:8886:17 (gm+0x513492) > #10 GMCommandSingle > /home/ubuntu/work/GM/GM-fixed/magick/command.c:17408:10 (gm+0x539161) > #11 GMCommand /home/ubuntu/work/GM/GM-fixed/magick/command.c:17461:16 > (gm+0x538e05) > #12 main /home/ubuntu/work/GM/GM-fixed/utilities/gm.c:61:10 > (gm+0x4c220b) > ... > ... > ... > WARNING: ThreadSanitizer: data race (pid=20260) > Read of size 4 at 0x7b0800000170 by thread T3: > #0 AccessThreadViewData > /home/ubuntu/work/GM/GM-fixed/magick/omp_data_view.c:181:3 (gm+0x5d2c0b) > #1 .omp_outlined..176 > /home/ubuntu/work/GM/GM-fixed/magick/render.c:5149:40 (gm+0x6461ed) > #2 __kmp_invoke_microtask > /home/ubuntu/work/openmp/openmp-4/final/runtime/src/z_Linux_asm.s:1399 > (libomp.so.5+0x7a292) > > Previous write of size 8 at 0x7b0800000170 by main thread: > #0 malloc <null> (gm+0x432acb) > #1 MagickMalloc */home/ubuntu/work/GM/GM-fixed/magick/memory.c:173*:10 > (gm+0x5cc2b7) > #2 AllocateThreadViewDataSet > /home/ubuntu/work/GM/GM-fixed/magick/omp_data_view.c:88:12 (gm+0x5d25dd) > #3 DrawPolygonPrimitive > /home/ubuntu/work/GM/GM-fixed/magick/render.c:4909:26 (gm+0x64024e) > #4 DrawPrimitive /home/ubuntu/work/GM/GM-fixed/magick/render.c:5782:15 > (gm+0x63f513) > #5 DrawImage /home/ubuntu/work/GM/GM-fixed/magick/render.c:4517:13 > (gm+0x6302c5) > #6 ReadMVGImage /home/ubuntu/work/GM/GM-fixed/coders/mvg.c:237:10 > (gm+0x8e7cb6) > #7 ReadImage /home/ubuntu/work/GM/GM-fixed/magick/constitute.c:1607:13 > (gm+0x555242) > #8 ReadSVGImage /home/ubuntu/work/GM/GM-fixed/coders/svg.c:3944:13 > (gm+0x991986) > #9 ReadImage /home/ubuntu/work/GM/GM-fixed/magick/constitute.c:1607:13 > (gm+0x555242) > #10 ConvertImageCommand > /home/ubuntu/work/GM/GM-fixed/magick/command.c:4362:22 (gm+0x4e203a) > #11 MagickCommand > /home/ubuntu/work/GM/GM-fixed/magick/command.c:8886:17 (gm+0x513492) > #12 GMCommandSingle > /home/ubuntu/work/GM/GM-fixed/magick/command.c:17408:10 (gm+0x539161) > #13 GMCommand /home/ubuntu/work/GM/GM-fixed/magick/command.c:17461:16 > (gm+0x538e05) > #14 main /home/ubuntu/work/GM/GM-fixed/utilities/gm.c:61:10 > (gm+0x4c220b) > > Location is heap block of size 24 at 0x7b0800000160 allocated by main > thread: > #0 malloc <null> (gm+0x432acb) > #1 MagickMalloc /home/ubuntu/work/GM/GM-fixed/magick/memory.c:173:10 > (gm+0x5cc2b7) > #2 AllocateThreadViewDataSet > /home/ubuntu/work/GM/GM-fixed/magick/omp_data_view.c:88:12 (gm+0x5d25dd) > #3 DrawPolygonPrimitive > /home/ubuntu/work/GM/GM-fixed/magick/render.c:4909:26 (gm+0x64024e) > #4 DrawPrimitive /home/ubuntu/work/GM/GM-fixed/magick/render.c:5782:15 > (gm+0x63f513) > #5 DrawImage /home/ubuntu/work/GM/GM-fixed/magick/render.c:4517:13 > (gm+0x6302c5) > #6 ReadMVGImage /home/ubuntu/work/GM/GM-fixed/coders/mvg.c:237:10 > (gm+0x8e7cb6) > #7 ReadImage /home/ubuntu/work/GM/GM-fixed/magick/constitute.c:1607:13 > (gm+0x555242) > #8 ReadSVGImage /home/ubuntu/work/GM/GM-fixed/coders/svg.c:3944:13 > (gm+0x991986) > #9 ReadImage /home/ubuntu/work/GM/GM-fixed/magick/constitute.c:1607:13 > (gm+0x555242) > #10 ConvertImageCommand > /home/ubuntu/work/GM/GM-fixed/magick/command.c:4362:22 (gm+0x4e203a) > #11 MagickCommand > /home/ubuntu/work/GM/GM-fixed/magick/command.c:8886:17 (gm+0x513492) > #12 GMCommandSingle > /home/ubuntu/work/GM/GM-fixed/magick/command.c:17408:10 (gm+0x539161) > #13 GMCommand /home/ubuntu/work/GM/GM-fixed/magick/command.c:17461:16 > (gm+0x538e05) > #14 main /home/ubuntu/work/GM/GM-fixed/utilities/gm.c:61:10 > (gm+0x4c220b) > > Thread T3 (tid=20264, running) created by main thread at: > #0 pthread_create <null> (gm+0x433446) > #1 __kmp_create_worker > /home/ubuntu/work/openmp/openmp-4/final/runtime/src/z_Linux_util.cpp:958:14 > (libomp.so.5+0x6ef74) > #2 DrawPrimitive /home/ubuntu/work/GM/GM-fixed/magick/render.c:5782:15 > (gm+0x63f513) > #3 DrawImage /home/ubuntu/work/GM/GM-fixed/magick/render.c:4517:13 > (gm+0x6302c5) > #4 ReadMVGImage /home/ubuntu/work/GM/GM-fixed/coders/mvg.c:237:10 > (gm+0x8e7cb6) > #5 ReadImage /home/ubuntu/work/GM/GM-fixed/magick/constitute.c:1607:13 > (gm+0x555242) > #6 ReadSVGImage /home/ubuntu/work/GM/GM-fixed/coders/svg.c:3944:13 > (gm+0x991986) > #7 ReadImage /home/ubuntu/work/GM/GM-fixed/magick/constitute.c:1607:13 > (gm+0x555242) > #8 ConvertImageCommand > /home/ubuntu/work/GM/GM-fixed/magick/command.c:4362:22 (gm+0x4e203a) > #9 MagickCommand > /home/ubuntu/work/GM/GM-fixed/magick/command.c:8886:17 (gm+0x513492) > #10 GMCommandSingle > /home/ubuntu/work/GM/GM-fixed/magick/command.c:17408:10 (gm+0x539161) > #11 GMCommand /home/ubuntu/work/GM/GM-fixed/magick/command.c:17461:16 > (gm+0x538e05) > #12 main /home/ubuntu/work/GM/GM-fixed/utilities/gm.c:61:10 > (gm+0x4c220b) > > SUMMARY: ThreadSanitizer: data race > /home/ubuntu/work/GM/GM-fixed/magick/omp_data_view.c:181:3 in > AccessThreadViewData > ================== > > I will look into the use of OpenMP pragmas later to double check them. > > Best Regards, > Hongxu > > > On Sun, Feb 24, 2019 at 5:01 AM Bob Friesenhahn < > bfr...@si...> wrote: > >> I have made updates which should address most issues related to the >> progress monitor. Please re-run your checks on the latest code. >> >> Thanks, >> >> Bob >> -- >> Bob Friesenhahn >> bfr...@si..., >> http://www.simplesystems.org/users/bfriesen/ >> GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ >> Public Key, >> http://www.simplesystems.org/users/bfriesen/public-key.txt >> >> >> _______________________________________________ >> Graphicsmagick-bugs mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/graphicsmagick-bugs >> > |
From: Bob F. <bfr...@si...> - 2019-02-23 21:01:47
|
I have made updates which should address most issues related to the progress monitor. Please re-run your checks on the latest code. Thanks, Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt |
From: Hongxu C. <lef...@gm...> - 2019-02-12 18:10:00
|
Hi Bob, Yes, I agree that this read/write race is mostly benign since this is only used for monitoring updates. There are other occurrences (e.g., the tarball I attached in a previous mail has some) such as "quantum" which also have similar issues, I can see that this value seems to be passed back and forward with "quantum_p" however I'm not aware of the purpose. It's better to inspect them to see whether there are some potential defects. Still I'd suggest "fixing" the potential data races as I can see the overhead is mostly neglectable and also may be better for maintenance during evolving. If there are indeed unnecessary to polish this, I think it's probably good to write some comments or memo. On Wed, Feb 13, 2019 at 1:38 AM Bob Friesenhahn < bfr...@si...> wrote: > On Wed, 13 Feb 2019, Hongxu Chen wrote: > > > > Yes, that is pass-by-value. > > But the problem is that there might also "(atomic) write row_count" > > between these lines, > > which causes the inconsistency. > > > > atomic write row_count at line:123 > > <write> > > read row_count at line:124 (QuantumTick) > > <write> > > read row_count at line:125 (MagickMonitorFormatted) > > > > Therefore it's still possible that row_count at line:124 and line:125 are > > different. > > Definitely the value can be different when reading a shared integer > value which may be updated at any time by any thread. This would be > true if a lock is held around individual access, but not across the > multiple accesses. The updated value could be sampled and copied to a > variable on the local thread stack (just like 'status' is copied to > 'thread_status' at a point where there is an implicit flush) so it is > consistent while used within the thread and there is no contention. > > QuantumTick() is a macro and refers to this value multiple times. It > is likely that the value used by the macro is in a register, or in L1 > cache, or optimized in interesting ways. If the value changes while > QuantumTick() is using it, it might produce a "tick" outside of its > normal cadence. > > Regardless, this issue appears to be totally benign in terms of > function of the software. It is only there for the progress monitor, > which is usually not active. > > Bob > > > _______________________________________________ > Graphicsmagick-bugs mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/graphicsmagick-bugs > |
From: Bob F. <bfr...@si...> - 2019-02-12 17:38:08
|
On Wed, 13 Feb 2019, Hongxu Chen wrote: > > Yes, that is pass-by-value. > But the problem is that there might also "(atomic) write row_count" > between these lines, > which causes the inconsistency. > > atomic write row_count at line:123 > <write> > read row_count at line:124 (QuantumTick) > <write> > read row_count at line:125 (MagickMonitorFormatted) > > Therefore it's still possible that row_count at line:124 and line:125 are > different. Definitely the value can be different when reading a shared integer value which may be updated at any time by any thread. This would be true if a lock is held around individual access, but not across the multiple accesses. The updated value could be sampled and copied to a variable on the local thread stack (just like 'status' is copied to 'thread_status' at a point where there is an implicit flush) so it is consistent while used within the thread and there is no contention. QuantumTick() is a macro and refers to this value multiple times. It is likely that the value used by the macro is in a register, or in L1 cache, or optimized in interesting ways. If the value changes while QuantumTick() is using it, it might produce a "tick" outside of its normal cadence. Regardless, this issue appears to be totally benign in terms of function of the software. It is only there for the progress monitor, which is usually not active. Bob |
From: Hongxu C. <lef...@gm...> - 2019-02-12 17:16:50
|
On Wed, Feb 13, 2019 at 1:05 AM Bob Friesenhahn < bfr...@si...> wrote: > On Wed, 13 Feb 2019, Hongxu Chen wrote: > > > Hi Bob, > > > > I think TSan warns not because of the atomic increment for row_count, > > but the interleaving between the write of row_count (line 123) and the > read > > of it (line 124). It's possible to have the following interleavings > > where row_count is different. > > Does an 'omp flush' of row_count help? Does Threadsanitizer > understand 'omp atomic' and 'omp flush'? These constructs are using > CPU/hardware features to assure that all threads get the updated > value rather than blocking while one thread updates it and then doing > an implicit flush so that all threads see the change. > Yes, it understands. For example, it tells that " Atomic write" in the report. Atomic write of size 8 at 0x7ffec6b0b118 by thread T1: #0 __tsan_atomic64_fetch_add <null> (gm+0x475e70) #1 .omp_outlined. /home/ubuntu/work/GM/GM-tsan/magick/gradient.c:123:7 (gm+0xae62db) #2 __kmp_invoke_microtask /home/ubuntu/work/openmp/openmp-7/final/runtime/src/z_Linux_asm.S:1325 (libomp.so.5+0x8ed22) > > > Therefore the differences of row_count can lead to different branchings > > even if all the execution traces before entering line 123 are all the > same. > > Additionally, MagickMonitorFormatted also read row_count, which may > finally > > affect the "thread_status=MagickFail" assignment. > > The value of row_count used by MagickMonitorFormatted() is passed by > value so I don't see how it can read a different value of row_count > than when it was originally prepared. > Yes, that is pass-by-value. But the problem is that there might also "(atomic) write row_count" between these lines, which causes the inconsistency. atomic write row_count at line:123 <write> read row_count at line:124 (QuantumTick) <write> read row_count at line:125 (MagickMonitorFormatted) Therefore it's still possible that row_count at line:124 and line:125 are different. > > Bob > > > > _______________________________________________ > Graphicsmagick-bugs mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/graphicsmagick-bugs > |
From: Bob F. <bfr...@si...> - 2019-02-12 17:05:30
|
On Wed, 13 Feb 2019, Hongxu Chen wrote: > Hi Bob, > > I think TSan warns not because of the atomic increment for row_count, > but the interleaving between the write of row_count (line 123) and the read > of it (line 124). It's possible to have the following interleavings > where row_count is different. Does an 'omp flush' of row_count help? Does Threadsanitizer understand 'omp atomic' and 'omp flush'? These constructs are using CPU/hardware features to assure that all threads get the updated value rather than blocking while one thread updates it and then doing an implicit flush so that all threads see the change. > Therefore the differences of row_count can lead to different branchings > even if all the execution traces before entering line 123 are all the same. > Additionally, MagickMonitorFormatted also read row_count, which may finally > affect the "thread_status=MagickFail" assignment. The value of row_count used by MagickMonitorFormatted() is passed by value so I don't see how it can read a different value of row_count than when it was originally prepared. Bob |
From: Hongxu C. <lef...@gm...> - 2019-02-12 16:55:19
|
FYI, here attaches a tarball containing some other TSAN reports. "*.res" are the reports, files without ".res" are the input however the behaviors may be not the same across different runs. Best Regards, Hongxu On Wed, Feb 6, 2019 at 2:45 AM Bob Friesenhahn <bfr...@si...> wrote: > On Wed, 6 Feb 2019, Hongxu Chen wrote: > > WARNING: ThreadSanitizer: data race (pid=29974) > > Atomic write of size 8 at 0x7ffee84393b8 by thread T6: > > #0 __tsan_atomic64_fetch_add <null> (gm+0x476040) > > #1 .omp_outlined. /home/exp/work/gm/GM-tsan/magick/gradient.c:123:7 > > The 'row_count' stack variable is declared to be omp shared and > updated under the apparent protection of a 'pragma omp atomic' so I am > curious if there is an actual problem here. Is there some code change > (e.g. a 'pragma omp flush (row_count)') which makes the reported issue > go away? > > > I'm trying some concurrent detection techniques, so I can try GM versions > > prior to 1.3.31, > > so thanks for this tip! > > It would be interesting to see the difference. > > Ultimately, well-tested patches which solve problems are most useful. > > Bob > -- > Bob Friesenhahn > bfr...@si..., http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ > Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt > > > _______________________________________________ > Graphicsmagick-bugs mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/graphicsmagick-bugs > |
From: Hongxu C. <lef...@gm...> - 2019-02-12 16:13:08
|
Hi Bob, I think TSan warns not because of the atomic increment for row_count, but the interleaving between the write of row_count (line 123) and the read of it (line 124). It's possible to have the following interleavings where row_count is different. T1: row_count++; T2: row_count++; T1: if (QuantumTick(row_count,image->rows)) T2: if (QuantumTick(row_count,image->rows)) and T1: row_count++; T1: if (QuantumTick(row_count,image->rows)) T2: row_count++; T2: if (QuantumTick(row_count,image->rows)) By observing QuantumTick's expansion at studio.h: #define QuantumTick(i,span) \ ((((i) % ((Max(101,span)-1)/100)) == 0) || \ ((magick_int64_t) (i) == ((magick_int64_t) (span)-1))) Therefore the differences of row_count can lead to different branchings even if all the execution traces before entering line 123 are all the same. Additionally, MagickMonitorFormatted also read row_count, which may finally affect the "thread_status=MagickFail" assignment. Best Regards, Hongxu On Wed, Feb 6, 2019 at 2:45 AM Bob Friesenhahn <bfr...@si...> wrote: > On Wed, 6 Feb 2019, Hongxu Chen wrote: > > WARNING: ThreadSanitizer: data race (pid=29974) > > Atomic write of size 8 at 0x7ffee84393b8 by thread T6: > > #0 __tsan_atomic64_fetch_add <null> (gm+0x476040) > > #1 .omp_outlined. /home/exp/work/gm/GM-tsan/magick/gradient.c:123:7 > > The 'row_count' stack variable is declared to be omp shared and > updated under the apparent protection of a 'pragma omp atomic' so I am > curious if there is an actual problem here. Is there some code change > (e.g. a 'pragma omp flush (row_count)') which makes the reported issue > go away? > > > I'm trying some concurrent detection techniques, so I can try GM versions > > prior to 1.3.31, > > so thanks for this tip! > > It would be interesting to see the difference. > > Ultimately, well-tested patches which solve problems are most useful. > > Bob > -- > Bob Friesenhahn > bfr...@si..., http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ > Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt > > > _______________________________________________ > Graphicsmagick-bugs mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/graphicsmagick-bugs > |
From: Bob F. <bfr...@si...> - 2019-02-05 18:45:43
|
On Wed, 6 Feb 2019, Hongxu Chen wrote: > WARNING: ThreadSanitizer: data race (pid=29974) > Atomic write of size 8 at 0x7ffee84393b8 by thread T6: > #0 __tsan_atomic64_fetch_add <null> (gm+0x476040) > #1 .omp_outlined. /home/exp/work/gm/GM-tsan/magick/gradient.c:123:7 The 'row_count' stack variable is declared to be omp shared and updated under the apparent protection of a 'pragma omp atomic' so I am curious if there is an actual problem here. Is there some code change (e.g. a 'pragma omp flush (row_count)') which makes the reported issue go away? > I'm trying some concurrent detection techniques, so I can try GM versions > prior to 1.3.31, > so thanks for this tip! It would be interesting to see the difference. Ultimately, well-tested patches which solve problems are most useful. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt |
From: Hongxu C. <lef...@gm...> - 2019-02-05 18:26:13
|
Hi Bob, Thanks for the reply! I inline some more comments below. On Wed, Feb 6, 2019 at 1:55 AM Bob Friesenhahn <bfr...@si...> wrote: > On Wed, 6 Feb 2019, Hongxu Chen wrote: > > > It is known that threadsanitizer has many false positives when > > detecting concurrent bugs with projects that depend on openmp, and GM is > > one of them. But I saw this commit (https://reviews.llvm.org/D13072), > and > > it seems to solve the problem. > > There is also a blog post about this > > https://xrunhprof.wordpress.com/2018/08/27/tsan-with-openmp. So I > followed > > the advice; and I built openmp with -DLIBOMP_TSAN_SUPPORT=TRUE and GM > with > > threadsanitizer and by running "gm convert", I can see some data races > > reported. My question is: > > 1. Can I rely on this result and think there are some data races? > > 2. Or can I even build openmp with -DLIBOMP_TSAN_SUPPORT=TRUE and > > threadsanitizer > > as well? > > I saw part of your large attachment, which can not possibly be sent on > a mailing list like this. > OK, I will be careful next time. > > The symbols I see warned about (e.g. __kmp_global) are not part of > GraphicsMagick. They appear to be part of the TSAN library > implementation so something is wrong with the testing. The article > you provided a reference to shows that the reports should be about the > code being intentionally tested. > That seems a part of openmp. I built an openmp without TSAN but with -DLIBOMP_TSAN_SUPPORT=TRUE only, there are still some warnings. However the warnings are something like: WARNING: ThreadSanitizer: data race (pid=29974) Atomic write of size 8 at 0x7ffee84393b8 by thread T6: #0 __tsan_atomic64_fetch_add <null> (gm+0x476040) #1 .omp_outlined. /home/exp/work/gm/GM-tsan/magick/gradient.c:123:7 (gm+0xafa24b) #2 __kmp_invoke_microtask /home/exp/work/imagemagick/openmp/BUILD/../runtime/src/z_Linux_asm.s:1399 (libomp.so+0x7a292) Previous read of size 8 at 0x7ffee84393b8 by main thread: #0 .omp_outlined. /home/exp/work/gm/GM-tsan/magick/gradient.c:124:11 (gm+0xafa261) #1 __kmp_invoke_microtask /home/exp/work/imagemagick/openmp/BUILD/../runtime/src/z_Linux_asm.s:1399 (libomp.so+0x7a292) #2 DrawImage /home/exp/work/gm/GM-tsan/magick/render.c:3538:20 (gm+0x624fd1) #3 DrawPatternPath /home/exp/work/gm/GM-tsan/magick/render.c:4610:10 (gm+0x631457) #4 DrawImage /home/exp/work/gm/GM-tsan/magick/render.c:2797:22 (gm+0x61d3a8) #5 ReadMVGImage /home/exp/work/gm/GM-tsan/coders/mvg.c:237:10 (gm+0x8e2ea6) #6 ReadImage /home/exp/work/gm/GM-tsan/magick/constitute.c:1607:13 (gm+0x555462) #7 ReadSVGImage /home/exp/work/gm/GM-tsan/coders/svg.c:3945:13 (gm+0x98ca4b) #8 ReadImage /home/exp/work/gm/GM-tsan/magick/constitute.c:1607:13 (gm+0x555462) #9 ConvertImageCommand /home/exp/work/gm/GM-tsan/magick/command.c:4362:22 (gm+0x4e225a) #10 MagickCommand /home/exp/work/gm/GM-tsan/magick/command.c:8886:17 (gm+0x5136b2) #11 GMCommandSingle /home/exp/work/gm/GM-tsan/magick/command.c:17408:10 (gm+0x539381) #12 GMCommand /home/exp/work/gm/GM-tsan/magick/command.c:17461:16 (gm+0x539025) #13 main /home/exp/work/gm/GM-tsan/utilities/gm.c:61:10 (gm+0x4c242b) Location is stack of main thread. Thread T6 (tid=29981, running) created by main thread at: #0 pthread_create <null> (gm+0x433666) #1 __kmp_create_worker /home/exp/work/imagemagick/openmp/BUILD/../runtime/src/z_Linux_util.cpp:958:14 (libomp.so+0x6ef74) #2 DrawImage /home/exp/work/gm/GM-tsan/magick/render.c:3538:20 (gm+0x624fd1) #3 DrawPatternPath /home/exp/work/gm/GM-tsan/magick/render.c:4610:10 (gm+0x631457) #4 DrawImage /home/exp/work/gm/GM-tsan/magick/render.c:2797:22 (gm+0x61d3a8) #5 ReadMVGImage /home/exp/work/gm/GM-tsan/coders/mvg.c:237:10 (gm+0x8e2ea6) #6 ReadImage /home/exp/work/gm/GM-tsan/magick/constitute.c:1607:13 (gm+0x555462) #7 ReadSVGImage /home/exp/work/gm/GM-tsan/coders/svg.c:3945:13 (gm+0x98ca4b) #8 ReadImage /home/exp/work/gm/GM-tsan/magick/constitute.c:1607:13 (gm+0x555462) #9 ConvertImageCommand /home/exp/work/gm/GM-tsan/magick/command.c:4362:22 (gm+0x4e225a) #10 MagickCommand /home/exp/work/gm/GM-tsan/magick/command.c:8886:17 (gm+0x5136b2) #11 GMCommandSingle /home/exp/work/gm/GM-tsan/magick/command.c:17408:10 (gm+0x539381) #12 GMCommand /home/exp/work/gm/GM-tsan/magick/command.c:17461:16 (gm+0x539025) #13 main /home/exp/work/gm/GM-tsan/utilities/gm.c:61:10 (gm+0x4c242b) SUMMARY: ThreadSanitizer: data race (/home/exp/work/gm/GM-tsan/install/bin/gm+0x476040) in __tsan_atomic64_fetch_add This is suspicious since "omp_outlined" seems to cause the false alarms. I also noticed this: https://stackoverflow.com/questions/33004809/can-i-use-thread-sanitizer-for-openmp-programs And maybe I will try https://github.com/PRUNER/archer instead. > > Recent GraphicsMagick uses 'pragma omp atomic' and 'pragma omp flush' > in pixel_iterator.c rather than using critical sections. I am not > sure how a data-race detector deals with OpenMP 'flush' requests > (synchronize thread cached memory with with shared memory) since they > are not the same as a lock and might look like a data-race. Releases > prior to 1.3.31 used critical sections. > I'm trying some concurrent detection techniques, so I can try GM versions prior to 1.3.31, so thanks for this tip! > > Long ago I used valgrind's helgrind and drd modes to search for data > races. This required building a replacement libgomp based on pthreads > rather than special Linux interfaces. > Yeah, there seems a "-disable-linux-futex" for gcc to build openmp. And I was just wondering whether ` -DLIBOMP_TSAN_SUPPORT=TRUE` is the equivalent (unfortunately, it seems NOT). I guess I will ask the ThreadSanitizer community for some more help. > > There are two things which are normally shared in GM OpenMP loops > other than one mutex lock in pixel_cache.c. These are the error > status (to know when all the threads in the team should try to quit > because one of them reported an error), and the progress callback (to > report progress if a progress monitor is enabled). > > Independent testing and analysis of GraphicsMagick is certainly > valuable, but it is wise to identify specific code which should be > corrected. > > Bob > -- > Bob Friesenhahn > bfr...@si..., http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ > Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt > > > _______________________________________________ > Graphicsmagick-bugs mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/graphicsmagick-bugs > |
From: Bob F. <bfr...@si...> - 2019-02-05 17:55:38
|
On Wed, 6 Feb 2019, Hongxu Chen wrote: > It is known that threadsanitizer has many false positives when > detecting concurrent bugs with projects that depend on openmp, and GM is > one of them. But I saw this commit (https://reviews.llvm.org/D13072), and > it seems to solve the problem. > There is also a blog post about this > https://xrunhprof.wordpress.com/2018/08/27/tsan-with-openmp. So I followed > the advice; and I built openmp with -DLIBOMP_TSAN_SUPPORT=TRUE and GM with > threadsanitizer and by running "gm convert", I can see some data races > reported. My question is: > 1. Can I rely on this result and think there are some data races? > 2. Or can I even build openmp with -DLIBOMP_TSAN_SUPPORT=TRUE and > threadsanitizer > as well? I saw part of your large attachment, which can not possibly be sent on a mailing list like this. The symbols I see warned about (e.g. __kmp_global) are not part of GraphicsMagick. They appear to be part of the TSAN library implementation so something is wrong with the testing. The article you provided a reference to shows that the reports should be about the code being intentionally tested. Recent GraphicsMagick uses 'pragma omp atomic' and 'pragma omp flush' in pixel_iterator.c rather than using critical sections. I am not sure how a data-race detector deals with OpenMP 'flush' requests (synchronize thread cached memory with with shared memory) since they are not the same as a lock and might look like a data-race. Releases prior to 1.3.31 used critical sections. Long ago I used valgrind's helgrind and drd modes to search for data races. This required building a replacement libgomp based on pthreads rather than special Linux interfaces. There are two things which are normally shared in GM OpenMP loops other than one mutex lock in pixel_cache.c. These are the error status (to know when all the threads in the team should try to quit because one of them reported an error), and the progress callback (to report progress if a progress monitor is enabled). Independent testing and analysis of GraphicsMagick is certainly valuable, but it is wise to identify specific code which should be corrected. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt |
From: Hongxu C. <lef...@gm...> - 2019-02-05 16:44:11
|
Hi, It is known that threadsanitizer has many false positives when detecting concurrent bugs with projects that depend on openmp, and GM is one of them. But I saw this commit (https://reviews.llvm.org/D13072), and it seems to solve the problem. There is also a blog post about this https://xrunhprof.wordpress.com/2018/08/27/tsan-with-openmp. So I followed the advice; and I built openmp with -DLIBOMP_TSAN_SUPPORT=TRUE and GM with threadsanitizer and by running "gm convert", I can see some data races reported. My question is: 1. Can I rely on this result and think there are some data races? 2. Or can I even build openmp with -DLIBOMP_TSAN_SUPPORT=TRUE and threadsanitizer as well? Best Regards, Hongxu |
From: Mehdi <001...@gm...> - 2018-12-12 00:58:30
|
A priori, no difference. All the debug info: (gdb) run convert -limit files 1023 -limit memory 5GB -define jpeg:preserve-settings *.JPG essai.pdf Starting program: /usr/local/bin/gm convert -limit files 1023 -limit memory 5GB -define jpeg:preserve-settings *.JPG essai.pdf [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGBUS, Bus error. > ReadJPEGImage (image_info=0x8268c0, > exception=0x7fffffffc3b0) at coders/jpeg.c:1561 > 1561 coders/jpeg.c: Aucun fichier ou dossier de ce type. > (gdb) bt > #0 ReadJPEGImage (image_info=0x8268c0, > exception=0x7fffffffc3b0) at coders/jpeg.c:1561 > #1 0x0000000000430fc9 in ReadImage ( > image_info=image_info@entry=0x81fb70, > exception=exception@entry=0x7fffffffc3b0) > at magick/constitute.c:1607 > #2 0x00000000004162ba in ConvertImageCommand ( > image_info=0x81fb70, argc=<optimized out>, > argv=<optimized out>, metadata=0x0, > exception=0x7fffffffc3b0) > at magick/command.c:4362 > #3 0x000000000040c970 in MagickCommand ( > image_info=image_info@entry=0x81fb70, > argc=argc@entry=291, > argv=argv@entry=0x7fffffffcd30, > metadata=metadata@entry=0x7fffffffc3a8, > exception=exception@entry=0x7fffffffc3b0) > at magick/command.c:8886 > #4 0x000000000040d935 in GMCommandSingle (argc=291, > argc@entry=292, argv=0x7fffffffcd30, > argv@entry=0x7fffffffcd28) > at magick/command.c:17408 > #5 0x000000000042639c in GMCommand (argc=292, > argv=0x7fffffffcd28) at magick/command.c:17461 > #6 0x00007ffff63702e1 in __libc_start_main () > from /lib/x86_64-linux-gnu/libc.so.6 > #7 0x00000000004076da in _start () > (gdb) info locals > indexes = <optimized out> > x = 3584 > q = 0x7ffcee515000 > image = 0x103a050 > error_manager = <error reading variable error_manager (value of type > `ErrorManager' requires 66224 bytes, which is more than max-value-size)> > index = 248 '\370' > y = 2377 > jpeg_pixels = 0x1067590 > "\236\242\250\261\273\304\313Ϩ\250\250\250\250\250\250\250\377\375\365\363\372\377\377\377\342\330ɾ\274\305\321ڬ\256\261\265\272\276\301\302Զ\240\254\314\330¤wxyz|~\177\177\226\254\300\273\232qRD\257\253\244\233\222\211\202~\241\247\255\256\244\222}p\265\252\235\230\245\300\337\364\220\245\305\344\366\370\361龷\254\245\245\254\267\276\210\216\225\225\213yeWllllllll`p\206\226\226\206p`[KIh\221\234\177]EO^jldXOAZ~\227\227~ZA.SupN6<O>NdssbL<PNKFB=:8\020\070`bG6BWdT>..>TdR8-Ksq:" > scanline = { > 0x1067590 > "\236\242\250\261\273\304\313Ϩ\250\250\250\250\250\250\250\377\375\365\363\372\377\377\377\342\330ɾ\274\305\321ڬ\256\261\265\272\276\301\302Զ\240\254\314\330¤wxyz|~\177\177\226\254\300\273\232qRD\257\253\244\233\222\211\202~\241\247\255\256\244\222}p\265\252\235\230\245\300\337\364\220\245\305\344\366\370\361龷\254\245\245\254\267\276\210\216\225\225\213yeWllllllll`p\206\226\226\206p`[KIh\221\234\177]EO^jldXOAZ~\227\227~ZA.SupN6<O>NdssbL<PNKFB=:8\020\070`bG6BWdT>..>TdR8-Ksq:"} > value = <optimized out> > i = <optimized out> > jpeg_error = { > error_exit = 0x5166f0 <JPEGErrorHandler>, > emit_message = 0x5168d0 <JPEGDecodeMessageHandler>, output_message = > 0x7ffff72a4ba0, > format_message = 0x7ffff72a4a90, > reset_error_mgr = 0x7ffff72a4a70, msg_code = 105, > msg_parm = {i = {0, 63, 0, 0, 2, 2, 2, 3}, > s = "\000\000\000\000?", '\000' <repeats 11 times>, > "\002\000\000\000\002\000\000\000\002\000\000\000\003", '\000' <repeats 50 > times>}, trace_level = 0, > num_warnings = 0, > jpeg_message_table = 0x7ffff74e6640 <jpeg_std_message_table>, > last_jpeg_message = 126, > addon_message_table = 0x0, > first_addon_message = 0, last_addon_message = 0} > jpeg_progress = { > progress_monitor = 0x516820 <JPEGDecodeProgressMonitor>, pass_counter = > 2377, pass_limit = 3456, > completed_passes = 0, total_passes = 1} > jpeg_info = {err = 0x7ffffffe8430, mem = 0xf29d50, - > progress = 0x7ffffffe8410, or q <return> to quit--- > client_data = 0x7ffffffe9e00, is_decompressor = 1, > global_state = 205, src = 0x1052a70, > image_width = 4608, image_height = 3456, > num_components = 1, > jpeg_color_space = JCS_GRAYSCALE, > out_color_space = JCS_GRAYSCALE, scale_num = 1, > scale_denom = 1, output_gamma = 1, > buffered_image = 0, raw_data_out = 0, > dct_method = JDCT_ISLOW, do_fancy_upsampling = 1, > do_block_smoothing = 1, quantize_colors = 0, > dither_mode = JDITHER_FS, two_pass_quantize = 1, > desired_number_of_colors = 256, > enable_1pass_quant = 0, enable_external_quant = 0, > enable_2pass_quant = 0, output_width = 4608, > output_height = 3456, out_color_components = 1, > output_components = 1, rec_outbuf_height = 1, > actual_number_of_colors = 0, colormap = 0x0, > output_scanline = 2378, input_scan_number = 1, > input_iMCU_row = 298, output_scan_number = 1, > output_iMCU_row = 298, coef_bits = 0x0, > quant_tbl_ptrs = {0x1041a10, 0x0, 0x0, 0x0}, > dc_huff_tbl_ptrs = {0x1041aa0, 0x1041ce0, 0x0, > 0x0}, ac_huff_tbl_ptrs = {0x1041bc0, 0x1041e00, > 0x0, 0x0}, data_precision = 8, > comp_info = 0x1054ac0, progressive_mode = 0, > arith_code = 0, > arith_dc_L = '\000' <repeats 15 times>, > arith_dc_U = '\001' <repeats 16 times>, > arith_ac_K = '\005' <repeats 16 times>, > restart_interval = 0, saw_JFIF_marker = 1, > JFIF_major_version = 1 '\001', > JFIF_minor_version = 1 '\001', > density_unit = 1 '\001', X_density = 300, > Y_density = 300, saw_Adobe_marker = 0, > Adobe_transform = 0 '\000', CCIR601_sampling = 0, > marker_list = 0x0, max_h_samp_factor = 1, > max_v_samp_factor = 1, min_DCT_scaled_size = 8, > total_iMCU_rows = 432, > sample_range_limit = 0x1054c20 "", > comps_in_scan = 1, cur_comp_info = {0x1054ac0, > 0x0, 0x0, 0x0}, MCUs_per_row = 576, > MCU_rows_in_scan = 432, blocks_in_MCU = 1, > MCU_membership = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, > Ss = 0, Se = 63, Ah = 0, Al = 0, > unread_marker = 0, master = 0x1041980, > main = 0x1055670, coef = 0x1055500, > post = 0x10551e0, inputctl = 0x1041950, > marker = 0x1041840, entropy = 0x1055390, > idct = 0x1055210, upsample = 0x10550e0, > cconvert = 0x10550a0, cquantize = 0x0} > p = 0x1068391 "\370\370\370\370\370\370\370Ҝ" - > status = 1eturn> to continue, or q <return> to quit--- > number_pixels = <optimized out> > __PRETTY_FUNCTION__ = "ReadJPEGImage" > __func__ = "ReadJPEGImage" |
From: Bob F. <bfr...@si...> - 2018-12-10 16:16:09
|
On Sun, 9 Dec 2018, Mehdi wrote: > The size is still a big problem, with "preserve-settings", the size is > between four and fivefold the sum of pictures files. Its number limit is > now between 260 and 280 files, or in term of total size, 111 and 127 Mo. Please see the output of 'gm convert -list resources'. This is the first part of what I see on the system I am using at the moment: % gm convert -list resources Resource Limits (Q16, 64 bits/pixel, 64bit address) ---------------------------------------------------- Disk: Unlimited (MAGICK_LIMIT_DISK) Files: 256 (MAGICK_LIMIT_FILES) Map: 15.6GiB (MAGICK_LIMIT_MAP) Memory: 7.8GiB (MAGICK_LIMIT_MEMORY) Pixels: Unlimited (MAGICK_LIMIT_PIXELS) Threads: 4 (OMP_NUM_THREADS) Width: 256.0MiP (MAGICK_LIMIT_WIDTH) Height: 256.0MiP (MAGICK_LIMIT_HEIGHT Notice that 'files' is limited to 256 which is not terribly far from the problematic range of 260 and 280 files. Perhaps there is a bug related to this. Please try adding -limit files 1023 or set MAGICK_LIMIT_FILES in the environment like export MAGICK_LIMIT_FILES=1023 I think that the Linux default allows 1024 file descriptors per program. It would be useful to know if this changes behavior. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt |
From: Mehdi <001...@gm...> - 2018-12-10 15:45:45
|
> > > (gdb) info locals > indexes = <optimized out> > x = 4097 > q = 0x7fffb43aa004 > image = 0x8b8da0 > error_manager = <error reading variable error_manager (value of type > `ErrorManager' requires 66224 bytes, which is more than max-value-size)> > index = 248 '\370' > y = 542 > jpeg_pixels = 0x8def50 '\370' <repeats 199 times>, <incomplete sequence > \370>... > scanline = {0x8def50 '\370' <repeats 199 times>, <incomplete sequence > \370>...} > value = <optimized out> > i = <optimized out> > jpeg_error = {error_exit = 0x5166f0 <JPEGErrorHandler>, emit_message = > 0x5168d0 <JPEGDecodeMessageHandler>, output_message = 0x7ffff72a4ba0, > format_message = 0x7ffff72a4a90, reset_error_mgr = 0x7ffff72a4a70, > msg_code = 105, msg_parm = {i = {0, 63, 0, 0, 3, 1, 0, 3}, > s = "\000\000\000\000?", '\000' <repeats 11 times>, > "\003\000\000\000\001\000\000\000\000\000\000\000\003", '\000' <repeats 50 > times>}, trace_level = 0, > num_warnings = 0, jpeg_message_table = 0x7ffff74e6640 > <jpeg_std_message_table>, last_jpeg_message = 126, addon_message_table = > 0x0, first_addon_message = 0, > last_addon_message = 0} > ---Type <return> to continue, or q <return> to quit--- > jpeg_progress = {progress_monitor = 0x516820 <JPEGDecodeProgressMonitor>, > pass_counter = 542, pass_limit = 3456, completed_passes = 0, total_passes = > 1} > jpeg_info = {err = 0x7ffffffe8b00, mem = 0x85ab50, progress = > 0x7ffffffe8ae0, client_data = 0x7ffffffea4d0, is_decompressor = 1, > global_state = 205, > src = 0x8da9f0, image_width = 4608, image_height = 3456, num_components > = 1, jpeg_color_space = JCS_GRAYSCALE, out_color_space = JCS_GRAYSCALE, > scale_num = 1, > scale_denom = 1, output_gamma = 1, buffered_image = 0, raw_data_out = 0, > dct_method = JDCT_ISLOW, do_fancy_upsampling = 1, do_block_smoothing = 1, > quantize_colors = 0, dither_mode = JDITHER_FS, two_pass_quantize = 1, > desired_number_of_colors = 256, enable_1pass_quant = 0, > enable_external_quant = 0, > enable_2pass_quant = 0, output_width = 4608, output_height = 3456, > out_color_components = 1, output_components = 1, rec_outbuf_height = 1, > actual_number_of_colors = 0, colormap = 0x0, output_scanline = 543, > input_scan_number = 1, input_iMCU_row = 68, output_scan_number = 1, > output_iMCU_row = 68, > coef_bits = 0x0, quant_tbl_ptrs = {0x8d0c50, 0x0, 0x0, 0x0}, > dc_huff_tbl_ptrs = {0x8d0ce0, 0x8d0f20, 0x0, 0x0}, ac_huff_tbl_ptrs = > {0x8d0e00, 0x8d1040, 0x0, > 0x0}, data_precision = 8, comp_info = 0x8dca40, progressive_mode = 0, > arith_code = 0, arith_dc_L = '\000' <repeats 15 times>, > arith_dc_U = '\001' <repeats 16 times>, arith_ac_K = '\005' <repeats 16 > times>, restart_interval = 0, saw_JFIF_marker = 1, JFIF_major_version = 1 > '\001', > JFIF_minor_version = 1 '\001', density_unit = 1 '\001', X_density = 300, > Y_density = 300, saw_Adobe_marker = 0, Adobe_transform = 0 '\000', > CCIR601_sampling = 0, marker_list = 0x0, max_h_samp_factor = 1, > max_v_samp_factor = 1, min_DCT_scaled_size = 8, total_iMCU_rows = 432, > sample_range_limit = 0x8dcba0 "", comps_in_scan = 1, cur_comp_info = > {0x8dca40, 0x0, 0x0, 0x0}, MCUs_per_row = 576, MCU_rows_in_scan = 432, > blocks_in_MCU = 1, > MCU_membership = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, Ss = 0, Se = 63, Ah = > 0, Al = 0, unread_marker = 0, master = 0x8d0bc0, main = 0x8dd5f0, coef = > 0x8dd480, > post = 0x8dd160, inputctl = 0x8d0b90, marker = 0x8d0a80, entropy = > 0x8dd310, idct = 0x8dd190, upsample = 0x8dd060, cconvert = 0x8dd020, > cquantize = 0x0} > p = 0x8dff51 '\370' <repeats 199 times>, <incomplete sequence \370>... > ---Type <return> to continue, or q <return> to quit--- > status = 1 > number_pixels = <optimized out> > __PRETTY_FUNCTION__ = "ReadJPEGImage" > __func__ = "ReadJPEGImage" I suspect the code responsible of this is also in Imagemagick. Eventhough the message isn't the same and doesn't mention bus error, it would too much of a coincidence. I can't help for IM, since, it won't install again, strangely enough the binaries are nowhere to be found even after apt install imagemagick. |
From: Bob F. <bfr...@si...> - 2018-12-10 14:34:59
|
WikiPedia has a page regarding a Bus error (SIGBUS) at https://en.wikipedia.org/wiki/Bus_error Causes it mensions are non-existent address, unaligned access, and paging errors. I am suspecting that the issue is due to a paging errror. Linux uses lazy memory allocation so malloc() can report success but then a failure happens later when the memory is updated and therefore must be acquired as "real" memory. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt |
From: Bob F. <bfr...@si...> - 2018-12-10 14:28:59
|
And what does info locals say? It is pretty likely that compiler optimization will cause useful values not to be available. The most useful variables to know about in this case are 'x', 'y', 'index' and 'q'. In particular, either the storage for the memory accessed via 'q' is being over-run or the system is not able to provide the memory that it already allocated. Linux uses lazy memory allocation so malloc() can report success but then the system can still run out of memory while the memory is being updated. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt |
From: Mehdi <001...@gm...> - 2018-12-10 14:15:14
|
(gdb) bt #0 0x000000000051a8b2 in ReadJPEGImage (image_info=0x826870, exception=0x7fffffffca80) at coders/jpeg.c:1562 #1 0x0000000000430fc9 in ReadImage (image_info=image_info@entry=0x81fb70, exception=exception@entry=0x7fffffffca80) at magick/constitute.c:1607 #2 0x00000000004162ba in ConvertImageCommand (image_info=0x81fb70, argc=<optimized out>, argv=<optimized out>, metadata=0x0, exception=0x7fffffffca80) at magick/command.c:4362 #3 0x000000000040c970 in MagickCommand (image_info=image_info@entry =0x81fb70, argc=argc@entry=288, argv=argv@entry=0x7fffffffd400, metadata=metadata@entry=0x7fffffffca78, exception=exception@entry=0x7fffffffca80) at magick/command.c:8886 #4 0x000000000040d935 in GMCommandSingle (argc=288, argc@entry=289, argv=0x7fffffffd400, argv@entry=0x7fffffffd3f8) at magick/command.c:17408 #5 0x000000000042639c in GMCommand (argc=289, argv=0x7fffffffd3f8) at magick/command.c:17461 #6 0x00007ffff63702e1 in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #7 0x00000000004076da in _start () |