When an image is opened from a folder that contains other images, these images' thumbnails get shown at the bottom of the window.
In my case the folder contained a file with the .png extension that was in fact not a valid .png image (just some test file I did experiments with).
There is a check in place if a decoder could succesfully be created. However the same result variable gets then reused.
The following code then wrongfully assumes the failed decoder creation result is the result of a previous call to GetThumbnail and presumably tries to do a fallback thumbnail creation.
However GetThumbnail never got called since the decoder wasn't created. And since the fallback also relies on the decoder, we get a null pointer exception.
This pull request adds a simple check to prevent the crash.
IMHO lifetimes of variables like the decoder and the HRESULT are scoped way too broadly. Tightening the scope of some objects in that function could make it less prone to errors like this. I did not want to mess up the orignal authors coding style too much so I left it at that simple fix.
If there is any interest in that, I could issue another PR with some small changes that I would make.
When an image is opened from a folder that contains other images, these images' thumbnails get shown at the bottom of the window. In my case the folder contained a file with the .png extension that was in fact not a valid .png image (just some test file I did experiments with).
There is a check in place if a decoder could succesfully be created. However the same result variable gets then reused. The following code then wrongfully assumes the failed decoder creation result is the result of a previous call to
GetThumbnailand presumably tries to do a fallback thumbnail creation. HoweverGetThumbnailnever got called since the decoder wasn't created. And since the fallback also relies on the decoder, we get a null pointer exception.This pull request adds a simple check to prevent the crash.
IMHO lifetimes of variables like the decoder and the HRESULT are scoped way too broadly. Tightening the scope of some objects in that function could make it less prone to errors like this. I did not want to mess up the orignal authors coding style too much so I left it at that simple fix. If there is any interest in that, I could issue another PR with some small changes that I would make.