Re: Reading PNG Blob images causes access violation on png.c

On Tue, 30 Oct 2018, Antti Luoma wrote:
>
> Currently we have 2 problems:
>
> 1) MagickReadImageBlob() function crashes (access violation 0xFF) in png.c
> when it is trying to call setjmp: *if (setjmp(png_jmpbuf(ping))).*
>
> top of stack looks like this:
>
> Symbol name: __intrinsic_setjmp
> Symbol name: ReadOnePNGImage
> Symbol name: ReadPNGImage
> Symbol name: ReadImage
> Symbol name: BlobToImage
> Symbol name: MagickReadImageBlob
>
> I have been trying to figure out why this access violation happens but I
> don't fully understand this. I can comment out the setjmp call and it seems
> to work but the we loose the error handling.

Does does the situation change if you don't register your own memory 
handling routines?

GraphicsMagick provides its own memory allocators for libpng to use. 
This means that if you provide a memory allocator for GraphicsMagick 
to use that this same memory allocator is then used for libpng. 
Regardless, GraphicsMagick is providing its own memory allocators for 
libpng to use, and particularly so that any memory used by libpng has 
been cleared to zero in advance.

> 2) UnLockSemaphoreInfo() functions are not called after crashes (in other
> picture formats as well)  which causes lock to remain if we don't
> call DestroyMagick() to release whole library which is not good thing to do
> on a multi threaded server very often. Is there a possibility to create
> locks per wand and release them in case of error as well? Or is there other
> possibilities?
>
> Any help would be nice.

I am no Windows expert, but I will offer whatever help that I can.

It would be very useful to identify the specific exceptions which are 
leading to locked semaphores.  Identifying the semaphore which remains 
locked would be very useful.  If the code remains blocked on a 
semaphore than that must be the one which is still locked.

The PNG and JPEG coders respond to the define SETJMP_IS_THREAD_SAFE, 
which does not appear to be set by default in the Windows build. 
When this is defined to 1, the PNG and JPEG coders will execute 
threads concurrently without using semapores to assure that only one 
setjmp() is active at a time.  The PNG coder is very complex and it is 
possible that it leaks a semaphore when it throws an exception (just 
as it might leak memory).

Try to enable 'exception' logging so that any exceptions which are 
thrown are logged.   By default these go to the Windows application 
log.  The source file and line should be included in the log message 
and this will help determine the error recovery path which would have 
been used.

Bob
-- 
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/