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

Hi,

1) I haven't tried this actually very much without our memory handling.
First when I today tried I got system abort() call from Magick as Magick
signature was 0, which was strange ( I had few questionable code lines also
so maybe that has something to do with it.). But after using the default
memory allocations I was actually able to read PNG blob without access
violation. This is really good news as I have tried quite many things
already but not this it seems. I should also note that reading jpg/bmb/tiff
pictures works with our memory routines.

Now I am wondering what in our memory routines is causing this access
violation. Only thing which makes me wonder most is the fact that we use
our session pointer as a context variable. We store this variable in
ThreadLocalStorage and retrieve it from there (TlsGetValue()) before memory
allocation as usually memory is pre-allocated and we just mark it as
reserved. This is my guess that what could go wrong here but I don't know
if I have understood setjmp/longjmp enough.

2) When reading png images the semaphore that was not released was the
png.c own static one. There was other places as well but I have to get back
on this later and be more specific.

 I also tried to define SETJMP_IS_THREAD_SAFE some day but I got some
concurrency errors but those could also be related to the setjmp issue so I
will have continue to work on this and I will report if there are issues
that should checked. I have configured logging for stdout.

We use checks/guards for our own semaphores so that if exception happens in
some client session we check are all the semaphores released for this
session (with a session id) and try to release those so that we don't cause
permanent locks for shared resources.

Thank you very much.

-antti


My assumtion was that GM will set its own memory alloc functions to libpng
as well.

ti 30. lokak. 2018 klo 15.25 Bob Friesenhahn ([email protected])
kirjoitti:

> 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/
>
>
> _______________________________________________
> Graphicsmagick-help mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/graphicsmagick-help
>

_______________________________________________
Graphicsmagick-help mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/graphicsmagick-help