png_write_end may trigger a write error which sets off longjmp - which
then goes ahead and tries to free `misc.data` again. move the
png_write_end call before `quit` label to avoid this.
to reproduce, build scrot and imlib2 with ASan and then try to save a
screenshot to /dev/full (`scrot -o /dev/full`).
Input data is not necessarily nul-terminated.
Simplify frame rate parsing in the process.
Use of sscanf() should also be eliminated when compiling with debug -
some other day.
Based on patch by NRK.
ffmpeg has added multiple color space types that start with "420",
"422", and "444" (e.g. "420p16").
We cannot parse them as 8-bit color. Let's fail earier.
Use queried drawable depth, not the context one.
Fixes grabbing of bitmaps (now using intended colormap) in the
usual 24 bit depth case.
May fix other issues as well(?).
Broken by 3ab9498777 (in v1.11.0).
Patch by Omar Polo:
while upgrading the OpenBSD package I've come across a weird issue.
Due to the order of the flags, the heif module was loading the system'
version of Imlib2_loader.h (in /usr/local/include) instead of the one
from the tarball. This caused failure since the previous version
(1.11.0) didn't had IMLIB_LOADER_INEX.
Tested:
Before:
```
$ IMLIB2_LOADER_PATH=../src/modules/loaders/.libs ./test_load_2
...
[ RUN ] LOAD2.load_1
test_load_2.cpp:121: Failure
Expected equality of these values:
crc
Which is: 671661664
tii[i].crc
Which is: 4016720483
test_load_2.cpp:128: Failure
Expected equality of these values:
crc
Which is: 671661664
tii[i].crc
Which is: 4016720483
test_load_2.cpp:135: Failure
Expected equality of these values:
crc
Which is: 671661664
tii[i].crc
Which is: 4016720483
[ FAILED ] LOAD2.load_1 (70 ms)
...
```
After:
```
$ IMLIB2_LOADER_PATH=../src/modules/loaders/.libs ./test_load_2
...
test_load_2.cpp:122: Failure
Expected equality of these values:
crc
Which is: 671661664
tii[i].crc
Which is: 4016720483
wrong crc file: ./images/icon-64.xpm expected: 4016720483 actual: 671661664
test_load_2.cpp:131: Failure
Expected equality of these values:
crc
Which is: 671661664
tii[i]. crc
Which is: 4016720483
wrong crc file: ./images/icon-64.xpm expected: 4016720483 actual: 671661664
test_load_2.cpp:142: Failure
Expected equality of these values:
crc
Which is: 671661664
tii[i]. crc
Which is: 4016720483
wrong crc file: ./images/icon-64.xpm expected: 4016720483 actual: 671661664
[ FAILED ] LOAD2.load_1 (69 ms)
...
```
#17:
As per subject, the imlib_clone_image() function no longer preserves
the alpha channel value since imlib2 1.10.0.
This bug report was initially filed by Niko Tyni in Debian's bug tracker.
If you follow the subsequent link you will also find a test program that
demonstrates the regression.
https://bugs.debian.org/1041406
This upstream change is most likely the root cause of the problem
b39d33c800
It looks like an oversight where other functions were adapted
to the new alpha channel implementation, but imlib_clone_image() remains
unchanged and only copies the flags and not the new alpha byte.
During load from file we would do stat(file), then fopen(file),
and assume the stat'ed size corresponds to the fopen'ed file.
However, the file may be changed between stat() and fopen(), which may
cause trouble.
This should now be fixed by always using fstat() on the opened file
descriptor.