Access violation with gflLoadBitmapFromHandle() and IStream

Discussions on GFL SDK, the graphic library for reading and writing graphic files

Moderators: XnTriq, xnview

Post Reply
Defenestration
Posts: 47
Joined: Fri Aug 18, 2006 7:08 pm

Access violation with gflLoadBitmapFromHandle() and IStream

Post by Defenestration » Tue Dec 09, 2008 12:12 am

I'm using gflLoadBitmapFromHandle() to load an image from an IStream. A pointer to an IStream object is passed in, along with the GFL callback functions for Read, Seek and Tell being setup in LOAD_PARAMS.

In these GFL callback functions, I use the IStream object pointer to access the Read() and Seek() methods.

Everything works OK unless the load is cancelled mid-way through, which can cause an access violation. If an IStream becomes invalid, the Read() and Seek() methods return a value other than S_OK. When this occurs, I return -1 from the GFL callback functions.

As you can see from the attached screen shot, the heap gets corrupted.

NOTE: the crash doesn't always occur, so it must depend on where in the load operation the abort takes place.

Image

User avatar
dominique
Posts: 72
Joined: Thu Nov 08, 2007 9:22 am

Post by dominique » Tue Dec 09, 2008 7:01 am

Can't see your screenshot
Dom

Defenestration
Posts: 47
Joined: Fri Aug 18, 2006 7:08 pm

Post by Defenestration » Tue Dec 09, 2008 7:01 am

There was a problem with imageshack.us, but it appears to be fixed now.

Defenestration
Posts: 47
Joined: Fri Aug 18, 2006 7:08 pm

Post by Defenestration » Tue Dec 09, 2008 7:09 am

After further testing, it would appear there is also a problem with the WantCancel() callback when using gflLoadBitmap(), as it still returns GFL_NO_ERROR when WantCancel() return TRUE, with a partially formed bitmap (ie. the bit that hasn't loaded is just black), which is not expected behaviour.

Instead, you should create a new error code (eg. GFL_ERROR_CANCELLED) and return immediately from gflLoadBitmap() when WantCancel() returns TRUE. The fact you haven't returned GFL_NO_ERROR means the bitmap can be in a corrupt state (so there's no need to fill out the rest with black, unless this is done when the bitmap is first created anyway at the beginning of the load).

While this doesn't cause a crash, it may be related to the gflLoadBitmapFromHandle() access violation.

Defenestration
Posts: 47
Joined: Fri Aug 18, 2006 7:08 pm

Post by Defenestration » Fri Dec 12, 2008 2:18 pm

Defenestration wrote:The fact you haven't returned GFL_NO_ERROR means the bitmap can be in a corrupt state (so there's no need to fill out the rest with black, unless this is done when the bitmap is first created anyway at the beginning of the load).
Actually, the bitmap should be freed since if the load does not return GFL_NO_ERROR, the user will not be expecting a bitmap (and so will not do a gflFreeBitmap(), resulting in a leak).

Defenestration
Posts: 47
Joined: Fri Aug 18, 2006 7:08 pm

Post by Defenestration » Mon Feb 02, 2009 5:34 pm

Hi Pierre,

I know you're busy with XnView/XnView MP development, but would it be possible to get a fix for these issues ?

User avatar
xnview
Author of XnView
Posts: 32046
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re:

Post by xnview » Thu Jun 04, 2009 6:53 am

Sorry for the delay of my reply...

Do you have always the problem with IStream??
Defenestration wrote:After further testing, it would appear there is also a problem with the WantCancel() callback when using gflLoadBitmap(), as it still returns GFL_NO_ERROR when WantCancel() return TRUE, with a partially formed bitmap (ie. the bit that hasn't loaded is just black), which is not expected behaviour.
If WanCancel returns TRUE, gflLoadBitmap returns GFL_UNKNOWN_ERROR
Pierre.

Defenestration
Posts: 47
Joined: Fri Aug 18, 2006 7:08 pm

Re: Access violation with gflLoadBitmapFromHandle() and IStream

Post by Defenestration » Thu Jun 04, 2009 3:03 pm

xnview wrote:Sorry for the delay of my reply...
No problem. I know you are busy with XnViewMP.
xnview wrote:Do you have always the problem with IStream??
I only get the crash when using an IStream but, as mentioned, the crash doesn't always occur, so it must depend on where in the load operation the abort takes place. During testing, I begin loading a large file and then cancel it during the load operation. Sometimes it crashes, other times it does not.
xnview wrote:
Defenestration wrote:After further testing, it would appear there is also a problem with the WantCancel() callback when using gflLoadBitmap(), as it still returns GFL_NO_ERROR when WantCancel() return TRUE, with a partially formed bitmap (ie. the bit that hasn't loaded is just black), which is not expected behaviour.
If WanCancel returns TRUE, gflLoadBitmap returns GFL_UNKNOWN_ERROR
I haven't looked at the code for a while, but from memory it was definitely returning GFL_NO_ERROR when the WantCancel() callback function returned TRUE. I will double check this though and get back to you.

Let me know if you want me to test a new build, or have a later build which I can test with.

User avatar
xnview
Author of XnView
Posts: 32046
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: Access violation with gflLoadBitmapFromHandle() and IStream

Post by xnview » Thu Jun 04, 2009 4:07 pm

Defenestration wrote: Let me know if you want me to test a new build, or have a later build which I can test with.
Send me your email by PM
Pierre.

Defenestration
Posts: 47
Joined: Fri Aug 18, 2006 7:08 pm

Re: Access violation with gflLoadBitmapFromHandle() and IStream

Post by Defenestration » Thu Jun 04, 2009 4:21 pm

PM sent

Post Reply