Activity for Bob Friesenhahn
-
Bob Friesenhahn posted a comment on ticket #556
Was a Ghostscript bug.
-
On Mon, 2 Apr 2018, ioio wrote: I would like to report an issue with eps to jpg (and probably other raster formats) conversion. when a concave path is converted, horizontal lines appear in the result image, please see attachments for an reprocase eps and result jpg. the following parameters were used : gm convert -density 100 -geometry 50% -quality 100 -strip file.eps file.jpg i usualy use much higher density, and the issue still occur and can be seen when zoom in. This does not happen for me. Ghostscript...
-
On Tue, 27 Mar 2018, Tianyu Lang wrote: I am also seeing this error with the latest GM release To make things clear, this issue is already fixed in the development sources and the fix will be in the next release. Sorry for causing a problem. Bob
-
On Tue, 27 Mar 2018, Gregory Guthrie wrote: Trying to do some displays of .svg files, some work fine, others give a font error: Code: Select all gm convert myFile.svg win: gm convert: Unable to read font (n019003l.pfb) [No such file or directory]. gm convert myFile.svg myFile.jpg gm convert: Unable to read font (n019003l.pfb) [No such file or directory]. I had used gm for all of these before (long ago... 2015) and it worked fine. These failures mean that you don't have the Ghostscript fonts installed...
-
Divide-by-zero in ReadMNGImage (coders/png.c)
-
This issue is solved by Mercurial changeset 15496:84040fada1ee. Thank you very much for the report.
-
Improper image header
-
With this new submission, I am able to reproduce the problem so I am re-opening it. The problem is due to characters in the comment string which are screwing up the header parsing.
-
On Thu, 22 Mar 2018, Clark wrote: Sorry.. EPS files seems not to have any dimensions so this works gm convert /root/*.eps -resize 100x500! +adjoin /root/vector_%02d.png A default density of 75 (75 pixels per inch) is normally used. Add the -verbose option to see the options that GraphicsMagick passes to Ghostscript while rendering EPs or PDF. Ghostscript should also use a default density of 75 since that is the default Postscript resolution (to match the original Apple Mac screen). Bob
-
On Sat, 17 Mar 2018, Dave Brondsema wrote: Hi, The GraphicsMagick code repo has been moved to a new server configuration and in my testing is performing much better. Can you confirm if it is working fine for you now? I tested clones using both ssh and http and performance seems back to normal. Thank you very much for getting this working again. Bob (Openpearl and dblatex repos will be moved soon) Thanks, SourceForge.net Support [site-support:#16458] Clone of GraphicsMagick Mercurial repository times...
-
The inability to clone the Mercurial repository continues just as before. We have several requests from users that GraphicsMagick leave SourceForge and move to Github due to SourceForge's apparent inability to host source code any more. This would be a shame since GraphicsMagick has been faithful to SourceForge for 16 years already.
-
On Mon, 26 Feb 2018, Dave Brondsema wrote: Hi, Over the past several days we have been making a variety of improvements to our code repositories' speed and stability. Are you seeing any errors or slowness still? No, the Mercurial transfer still times out early during the 'adding file changes' step: % time hg -v -v clone http://hg.code.sf.net/p/graphicsmagick/code graphicsmagick-code requesting all changes adding changesets adding manifests adding file changes transaction abort! rollback completed...
-
On Mon, 19 Feb 2018, shoeb wrote: Hi, I have a PDF which dimension is 117.5x93.5 inches and need to convert this in PNG format on 300dpi. I converted it with the help of below command gm convert -density 300 input.pdf output.png but it took almost 5mins to convert in PNG and also generated a huge temp file, Due to space problem I have to change the default temp folder path and increase the performance. I read about "MAGICK_TMPDIR" and other options but didn't understand how to use. Also I want to...
-
On Mon, 19 Feb 2018, Kevin Dente wrote: I'm trying to use gm (1.3.28) to extract one page of a multiple page tiff and convert it to PNG. Most of our images work, but there are a bunch that fail with the error "Subimage specification returns no images" for specific pages. An example is attached. Page indexes 0-5 convert fine. 6-9 fail. 10 works. The problem (without looking at your file) would likely be due to the TIFF file having page numbers (an attribute) and they don't match up to the specified...
-
I was able to successfully clone the repository using the ssh protocol. The clone took 4:54:35.50 total time. Almost 5 hours is excessive for a repository checkout!
-
Clone of GraphicsMagick Mercurial repository times out
-
On Tue, 13 Feb 2018, el_cubano wrote: Thanks for the information. I did not think deeply enough on this. I will tweak the package prior to uploading it. At one time, C did not support prototypes, and when prototypes were added it was decided that the default return type should be an 'int' in the absence of a prototype. I think that this means that the language implementation needs to provide support for an integer return value (in a register) even if the function does not provide a return value....
-
On Tue, 13 Feb 2018, el_cubano wrote: The fix (b41e2efce6d3) and the subsequent commit (d30ed06e9b87), which appears to be required as well, changes the return type of InterpolateViewColor(). I am preparing a security update for Debian and I am concerned that this change breaks the ABI. I have started a thread on the debian-lts mailing list here: https://lists.debian.org/debian-lts/2018/02/msg00047.html I would appreciate some upstream feedback. I don't believe that changing a void return to an unsigned...
-
SVG file with width, height in inches is not rendered to the correct output size when DPI is other than 72.
-
SemaphoreInfo assertion failed when dynamic library's ID changed in macOS
-
Requested information was not provided by reporter.
-
Reusing built shipped libraries
-
Could we have a --without-jasper config option?
-
Question was answered.
-
On Sat, 10 Feb 2018, Andrew Janke wrote: When building GraphicsMagick, it looks like it will detect and opportunistically link to the Jasper library. Unlike gslib, webp, ttf, and other libraries, though, there doesn't seem to be a configure option to disable this. Could one be added? This would support the case of building GraphicsMagick on a host that may have Jasper installed, but for use on another host that doesn't have Jasper installed, or to have GM continue to work once Jasper is uninstalled....
-
On Thu, 8 Feb 2018, Baykalov Pyotr wrote: I am sorry for not mentionung. I am using W7 with MinGW w64, my configure command is: ../configure '--host=x86_64-w64-mingw32' '--disable-shared' --prefix=/usr/x86_64-w64-mingw32/sys-root/mingw CXXFLAGS="-flto -ffat-lto-objects -O3" && make I use host option because I am using Cygwin's MinGW. Everything installs and builds fine without errors except that I am not getting the libraries. So you checked /usr/x86_64-w64-mingw32/sys-root/mingw/usr/lib after 'make...
-
On Thu, 8 Feb 2018, Baykalov Pyotr wrote: So there are libraries shipped with GraphicksMagic so I have built it seamlessly. But those built libraries are not installed. How can I use them not just for building GraphicksMagick but for developing for Magick++ API? What operating system and compiler are you using? Bob
-
On Thu, 8 Feb 2018, Matt G wrote: I'm pretty sure you made the change which added ICODIB. The ChangeLog says I did it on 2015-01-04 and now I am beginning to remember. The ChangeLog and Mercurial are my collective memory since I can not remember everything that I did. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
-
Without re-compiling the source code, it is also possible to fix loading of the module by adding an entry to installed modules.mgk file. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
-
On Thu, 8 Feb 2018, Matt G wrote: Using 1.3.28. I try to read a Windows icon file and it fails. The problem appears to be that when an icon is detected its magick is changed from ICO to ICODIB in ReadIconImage (icon.c). GetMagickInfo tries to find a coder to handle ICODIB but one hasn't been loaded yet and the name of the module it's in is IM_MOD_RL_dib.dll, not IM_MOD_RL_icodib.dll, so it can't be found by OpenModule (module.c). The only way I see that this could work would be if a DIB was loaded...
-
On Thu, 8 Feb 2018, Matt G wrote: You're right. I shouldn't have made my statement so broad. I was referring to how the compiler is handling this particular case. When I look at the disassembly for DllMain I see that it pushes 0x104B0 bytes on the stack at the start of the function and pops it at the end. The push isn't conditional. It happens regardless of the values of the parameters. Other compilers or the same compiler with different options may behave differently, but in my case 65K is being...
-
On Wed, 7 Feb 2018, Matt G wrote: All auto variables in a function are put on the stack regardless of their scope since the function doesn't know whether they'll be used or not. It can't predict what code path will be taken. Do you have a reference for the above claim? I agree that variables are put on the stack but the function definitely knows the scope in which they are used and can allocate them from the stack at the point of use. Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/...
-
On Wed, 7 Feb 2018, Matt G wrote: All auto variables in a function are put on the stack regardless of their scope since the function doesn't know whether they'll be used or not. It can't predict what code path will be taken. You might have missed new_path[], which accounts for the other 32K. DllMain doesn't have to be reentrant for DLL_PROCESS_ATTACH since it will only be called once and the process blocks until it returns. Since nothing is being done for DLL_THREAD_ATTACH it is clearly reentrant...
-
On Wed, 7 Feb 2018, Matt G wrote: We're fixing it by making the arrays in question (dll_path, current_path, and new_path) static so that they're not allocated on the stack. Microsoft recommends that you don't call CRT functions in DllMain so we're not allocating the memory dynamically. The only downside I see is that we've added 65K to the parent process's footprint. I should mention that it is possible that thread-safety will be harmed by making these allocations static if the function is expected...
-
On Wed, 7 Feb 2018, Matt G wrote: DllMain (in magick\nt_base.c) declares two large arrays and one smaller array, totalling 65K bytes, as autos so they're allocated on the stack. This is usually OK because the default stack size is 1MB so there's plenty of room for this temporary stack usage. The I am seeing 33k explicitly allocated for the case of DLL_PROCESS_ATTACH and no handling for DLL_THREAD_ATTACH. Is the compiler violating the scope of the allocation request? Otherwise, it does not seem like...
-
On Mon, 5 Feb 2018, Gwan Yeong Kim wrote: I have a question. 1) Do you think this is a security issue? (I want to avoid duplicate analysis.) Yes, this can definitely be classified as a security issue since it results in a heap buffer overflow in the very heart of the software. At a minimum, it can be used to crash the software. The problem is not specific to WPG although a bug in the WPG coder lead to finding it. The problem is related to the specific image dimensions and that "virtual" (outside...
-
This is fixed by Mercurial changeset 15369:bba1e724f6f5 and should be corrected on the website at its next periodic refresh. Thanks for bringing the issue to our attention.
-
dead link 2017 changelog page on GraphicsMagick web site
-
On Sat, 3 Feb 2018, Alex Gaynor wrote: I'm not sure I understand the question, it looks like you landed the patch as-is which works for me! One small thing, it looks like the chmod +x fuzzing/oss-fuzz-build.sh got lost, can you add it back? Done! Bob
-
Wand API patches: has colormap, is gray image, is monochrome image, is opaque image, is palette image
-
Your patches are now applied as Mercurial changeset 15366:0f114d741a18. Please let me know if there are any issues. As usual, thank you very much for your contribution.
-
Your patch was used to create a 'fuzzing' directory in the GraphicsMagick Mercurial repository. I assume that adding to the repository is sufficient.
-
OSS-Fuzz integration
-
Unless further useful information such as a debugger backtrace is provided, I will be closing this issue soon since I have no way to reproduce it.
-
"Improper call to JPEG library in state 201" since 1.3.28
-
This issue is fixed by Mercurial changeset 15361:151c02ab6b8a. Any distribution maintainer providing patches for 1.3.28 should also provide this tiny fix until 1.3.29 is released. Thank you very much for reporting this problem.
-
This problem should be fixed by Mercurial changeset 15355:dfda2c94f25e. Thank you for reporting the problem.
-
Multiple definition of "OpenModule" (etc) when cross-compiling shared
-
I believe that I see a mis-match in the pre-processor conditions used so I should be able to fix this soon. Bob
-
On Sat, 27 Jan 2018, John Warburton wrote: Much appreciate GM. It's something I compile and use regularly. When cross-compiling from Ubuntu to Windows on x86_64-w64-mingw32 target, as of commit "Use a lazy-loader for static modules" 1afb47, some multiple definition errors arise at the stage where libGraphicsMagick-3.dll is linked. They're reproduced below, and concern "DestroyMagickModules", "InitializeMagicModules", "OpenModule" and "OpenModules". The two files where these objects are defined are...
-
"Improper call to JPEG library in state 201" since 1.3.28
-
I am able to reproduce this issue.
-
On Mon, 22 Jan 2018, Matthias Kiefer wrote: Since GraphicsMagick 1.3.28 the attached JPEG can no longer be converted with gm due to the following error message: ~~~ $ gm identify fractal.jpg gm identify: Improper call to JPEG library in state 201 (fractal.jpg). gm identify: Request did not return an image. What libjpeg distribution (e.g. IJG, Turbo) and libjpeg release version are you using? Bob
-
GraphicsMagick 1.3.28 is now available
-
If all goes well, there should be a new release by the end of the month.
-
13 symbols in common with ImageMagick despite --enable-symbol-prefix
-
This problem should be fixed by Mercurial changeset 15333:8a7f74caf607. Please make us aware of additional issues.
-
13 symbols in common with ImageMagick despite --enable-symbol-prefix
-
This problem is fixed by Mercurial changeset 15332:52a91ddb1aa6. Thank you very much for reporting it.
-
Infinite Loop in ReadBMPImage (coders/bmp.c)
-
Infinite Loop in ReadBMPImage (coders/bmp.c)
-
The promotion of certain warnings to errors is removed by Mercurial changeset 15331:8b560f627220. This changeset also adds a rationalization for claimed image dimensions based on image size. Thank you for reporting this issue.
-
Images with libjpeg warnings result in error
-
I have files here which warn "Corrupt JPEG data: premature end of data segment" and then somehow continue on "reading" a 65281x65496 image so they are "successfully processed". Without applying resource limits, this is harmful to the computer. How do you know if the files which reported "Premature end of JPEG file" were "successfully processed" (returned a proper image) vs libjpeg just making something up such as a region of black pixels? It is a problem what libjpeg is not particularly helpful with...
-
gm: heap-buffer-overflow in ReadTIFFImage (src/coders/tiff.c)
-
I will await your response as to if many of the JPEG files which can not be read are due to "Premature end of JPEG file". If this condition is not common/normal in modern times, I would leave the remapping from warning to error in place at this time for truncated files. Bob
-
On Fri, 12 Jan 2018, Matthias Kiefer wrote: I understand the reason for this. However, from my point of view there are a lot of images out there that trigger these warnings but can nevertheless be processed. E.g. I took a random sample from some of our service instances that generate previews from images that people upload. In this sample there have been about 10k images that triggered the warning with the invalid SOS parameters and 2k images that triggered one of the Corrupt JPEG data warnings....
-
On Fri, 12 Jan 2018, Probe Fuzzer wrote: Thanks for your work. It is a 64-bt build with address sanitizer enables (CFLAGS=-fsanitize=address). I have git pull the latest commit of libtiff and libjpeg and place the code in tiff and jpeg folders of graphicmagick source code. After complication, I can still reproduce this issue. Did you complie with address sanitizer enabled (i.e., CFLAGS=-fsanitize=address)? You need to be clear about what is meant by "libjpeg" since there are two major "libjpeg" projects...
-
I am not able to reproduce this issue. What version of libtiff and libjpeg are being used? Is this a 64-bit or 32-bit build? Please post the full output from 'gm -version'. This issue could easily be due to a bug already fixed in libtiff or related to a specific libjpeg distribution/version. I do see libtiff making two security-related corrections to the TIFF parsing. I also see that the file uses old JPEG compression TIFF format.
-
gm: heap-buffer-overflow in ReadTIFFImage (src/coders/tiff.c)
-
On Thu, 11 Jan 2018, Matthias Kiefer wrote: In addition to the warning 'Invalid SOS parameters for sequential JPEG', I also found that a lot of images that result in warnings starting with "Corrupt JPEG data:" are now reported as error but have been successfully been converted before with GraphicsMagick 1.3.26. The cause of these issues is this change: 2017-07-08 Bob Friesenhahn bfriesen@simple.dallas.tx.us * coders/png.c (ReadOneJNGImage): Fix double-frees caused by commit on 2017-07-06. * coders/jpeg.c...
-
On Thu, 11 Jan 2018, Matthias Kiefer wrote: For your reference I attached one of such images taken with a Samsung Galaxy S7 with Android 7. Please attach your sample JPEG in a zip file or some other common archiving mechanism. SourceForge re-writes/optimizes all web file formats (e.g GIF, JPEG, PNG) when the files are uploaded to the tracking system so the file will have lost the original issue since it is not the same file. Bob
-
heap-buffer-overflow bug in ReadWPGImage
-
The heap buffer overflow issue is fixed by Mercurial changeset 15322:b41e2efce6d3. Memory leaks still remain after a problem with the corrupted file has been reported. Thank you very much for reporting this issue.
-
This problem is fixed in Mercurial changeset 15322:b41e2efce6d3. The problem afflicts all GraphicsMagick 1.3.X releases. Thank you for reporting this issue.
-
heap-buffer-overflow in AcquireCacheNexus
-
On Fri, 5 Jan 2018, Gene Ksenzakovic wrote: I am sorry to bother you again. I believe I am making progress but am seeing the following error when attempting a converision now: I believe that this error means that you need to install Ghostscript ('gs'). See if 'which gs' returns anything. Although Ghostscript is "open source" it has been made available under several different licenses. Most recently it has been made under the GNU Affero General Public License. Artifex is in the business of making...
-
On Thu, 4 Jan 2018, Gene Ksenzakovic wrote: Thank you sir. I inherited the server with GM installed already and it appears to have been installed in two seperate locations. The same version. Is the removal relatively straight forward? I think the best path will be to completely remove and install the latest stable version. Thank you again, Gene If you were to configure GraphicsMagick for the same version with the same installation prefix and the same static vs shared vs modules configuration, and...
-
On Wed, 3 Jan 2018, Gene Ksenzakovic wrote: Thought I posted this earlier gm -version provides the following gm -version GraphicsMagick 1.3.21 2015-02-28 Q8 http://www.GraphicsMagick.org/ Copyright (C) 2002-2014 GraphicsMagick Group. Additional copyrights and licenses apply to this software. See http://www.GraphicsMagick.org/www/Copyright.html for details. Is this for the version you are replacing or for your new build? Nothing seems odd about the version output other than it is an old version which...
-
On Wed, 3 Jan 2018, Gene Ksenzakovic wrote: Bob, I have a few minutes to try and explain better. I was asking because I am not sure if I would not be better off uninstalling the program and reninstalling. However I I believe I have added the necesssary packages and have that portion configured. No version changes. The issue that has me confused is the permissions denied error taht is received regarding the delegates.mgk. Any insight into this would be very helpful as I am officially at a loss to...
-
On Wed, 3 Jan 2018, Gene Ksenzakovic wrote: Is it at all possible to reconfigure graphicsmagick after it has been installed? Not sure if this is the right location for this but I have inherited a server with it preintsallled. No, it is necessary to uninstall the prior GraphicsMagick and then configure/build a replacement GraphicsMagick from source code (or select a different variant of the package). Depending on how the prior version was installed, it may be possible/safe to install over the prior...
-
On Wed, 3 Jan 2018, Gene Ksenzakovic wrote: gm mogrify: Unable to access configuration file (delegates.mgk) [Permission denied]. Execute 'which gm' and verify that the 'gm' binary is the one that you installed. What does gm -version say? Bob
-
On Tue, 2 Jan 2018, Vinyl Darkscratch wrote: I see log.mgk in the source code now, it's strange that it wouldn't be included in the install directory... What's even weirder, the Homebrew formula isn't applying any patches to the code. I do see that there are no patches. I also see that the script ends with "make install" and there is just one trivial sanity test of its own design rather than using the built-in test suite. There must be some other script/definition which bundles up the result of "make...
-
On Mon, 1 Jan 2018, Vinyl Darkscratch wrote: For log.mgk, I actually don't see this file anywhere on my system. Perhaps it wasn't included in my particular install? This file is delivered with GraphicsMagick source code in the 'config' subdirectory. It is always installed. It is the first file which is attempted to be read and without the file, there are baked-in defaults. A quick grep of magick/magick_config.h showed no results for SETJMP_IS_THREAD_SAFE (Homebrew builds the formulas on their own...
-
Reporter stopped responding regarding this bug report.
-
Artifacts on image after using gm convert
-
Any more information on this issue? A stack backtrace of a core dump using a debugger would be useful to identify where the problem is occuring. A response to my prior questions is appreciated. At the moment I have nothing to go on so I don't know how to help.
-
heap-buffer-overflow in ReadMNGImage
-
This problem is fixed by Mercurial changeset 15313:1721f1b7e67a. Thank you for reporting this issue.
-
stack-buffer-overflow in WriteWEBPImage
-
This problem is fixed by Mercurial changeset 15311:6dda3c33f35f. The problem is specific to libwebp 0.5.0 or later.
-
I found the cause of the problem. The contribution of support for EXIF and ICC profiles has caused a different structure type to be passed into the progress callback. This means that the progress callback can not work with newer libwebp until a solution is found.
-
This problem is fixed by Mercurial changeset 15310:7b7166f3c47c. Thank you very much for informing us of this issue.
-
null pointer dereference in ReadMNGImage
-
I am encountering difficulties with reproducing this problem. Exactly what version of libwebp is being used? What does 'gm convert -list formats |grep WEBP' report?
-
stack-buffer-overflow in WriteWEBPImage
-
This issue is fixed by Mercurial changeset 15308:0d871e813a4f. Thank you for reporting the problem.
-
heap-buffer-overflow on LocaleNCompare
-
On Tue, 19 Dec 2017, Vinyl Darkscratch wrote: Something I notice is that it seems to crash right after loading png.la and calling RegisterPNGImage then UnregisterPNGImage. That does look suspicious. Your debug log appears so show that files (e.g. log.mgk) are not at expected places. Does only PNG fail and other formats appear to work? What does grep SETJMP_IS_THREAD_SAFE magick/magick_config.h in the build directory show? Did you do 'make check' after doing a compile to make sure that the test suite...
-
heap-buffer-overflow on LocaleNCompare
Oh no! Some styles failed to load. 😵
Please try reloading this page