This reverts commit a104e317ce.
Breaks image loading in certain situations.
It seems that some loaders may return 0 even when load() "succeeds".
This appears to happen with the jpeg loader when not loading data
immediately (but only reading the header).
In this case jpeg_finish_decompress() exits via _JPEGFatalErrorHandler()
-> longjmp() causing the return code to be 0.
The fix reverted here is probably basically correct, but it will have to
wait until the loaders are fixed to behave properly.
Prevents:
==22831== Conditional jump or move depends on uninitialised value(s)
==22831== at 0x634F040: load (loader_gif.c:181)
==22831== by 0x1F7D7B3: __imlib_LoadImage (image.c:1041)
==22831== by 0x1F090E4: imlib_load_image_with_error_return (api.c:1299)
==22831== by 0x40F47B: feh_load_image (imlib.c:252)
==22831== by 0x42CA0E: winwidget_loadimage (winwidget.c:753)
==22831== by 0x42C918: winwidget_create_from_file (winwidget.c:126)
==22831== by 0x421869: init_slideshow_mode (slideshow.c:62)
==22831== by 0x418F13: main (main.c:78)
==22831==
==22831== Use of uninitialised value of size 8
==22831== at 0x634F0F4: load (loader_gif.c:190)
==22831== by 0x1F7D7B3: __imlib_LoadImage (image.c:1041)
==22831== by 0x1F090E4: imlib_load_image_with_error_return (api.c:1299)
==22831== by 0x40F47B: feh_load_image (imlib.c:252)
==22831== by 0x42CA0E: winwidget_loadimage (winwidget.c:753)
==22831== by 0x42C918: winwidget_create_from_file (winwidget.c:126)
==22831== by 0x421869: init_slideshow_mode (slideshow.c:62)
==22831== by 0x418F13: main (main.c:78)
==22831==
==22831== Use of uninitialised value of size 8
==22831== at 0x634F122: load (loader_gif.c:191)
==22831== by 0x1F7D7B3: __imlib_LoadImage (image.c:1041)
==22831== by 0x1F090E4: imlib_load_image_with_error_return (api.c:1299)
==22831== by 0x40F47B: feh_load_image (imlib.c:252)
==22831== by 0x42CA0E: winwidget_loadimage (winwidget.c:753)
==22831== by 0x42C918: winwidget_create_from_file (winwidget.c:126)
==22831== by 0x421869: init_slideshow_mode (slideshow.c:62)
==22831== by 0x418F13: main (main.c:78)
==22831==
==22831== Use of uninitialised value of size 8
==22831== at 0x634F151: load (loader_gif.c:192)
==22831== by 0x1F7D7B3: __imlib_LoadImage (image.c:1041)
==22831== by 0x1F090E4: imlib_load_image_with_error_return (api.c:1299)
==22831== by 0x40F47B: feh_load_image (imlib.c:252)
==22831== by 0x42CA0E: winwidget_loadimage (winwidget.c:753)
==22831== by 0x42C918: winwidget_create_from_file (winwidget.c:126)
==22831== by 0x421869: init_slideshow_mode (slideshow.c:62)
==22831== by 0x418F13: main (main.c:78)
==22831==
when opening id:000001,orig:smaller-animated.gif with feh.
Prevents tons of:
==10646== Conditional jump or move depends on uninitialised value(s)
==10646== at 0x4F7D30C: png_write_find_filter (pngwutil.c:2578)
==10646== by 0x4F7568F: png_write_row (pngwrite.c:827)
==10646== by 0x4F751B0: png_write_rows (pngwrite.c:587)
==10646== by 0x4D40C7D: save (loader_png.c:373)
==10646== by 0x1297084: __imlib_SaveImage (image.c:1282)
==10646== by 0x124252B: imlib_save_image (api.c:4615)
==10646== by 0x401990: main (imlib2_conv.c:74)
when trying to convert id:000134,src:000105,op:havoc,rep:32.
Prevents an integer overflow later on that resulted in a datasize of
18446744073709551575 for id:000131,src:000104,op:havoc,rep:32,+cov
whose actual size is 48 byte.
Fixes:
==14822== Conditional jump or move depends on uninitialised value(s)
==14822== at 0x4E08376: load (loader_tiff.c:285)
==14822== by 0x1F7D70F: __imlib_LoadImage (image.c:1041)
==14822== by 0x1F090E4: imlib_load_image_with_error_return (api.c:1299)
==14822== by 0x40F47B: feh_load_image (imlib.c:252)
==14822== by 0x42CA0E: winwidget_loadimage (winwidget.c:753)
==14822== by 0x42C918: winwidget_create_from_file (winwidget.c:126)
==14822== by 0x421869: init_slideshow_mode (slideshow.c:62)
==14822== by 0x418F13: main (main.c:78)
==14822==
==14822== Conditional jump or move depends on uninitialised value(s)
==14822== at 0x4E083BC: load (loader_tiff.c:285)
==14822== by 0x1F7D70F: __imlib_LoadImage (image.c:1041)
==14822== by 0x1F090E4: imlib_load_image_with_error_return (api.c:1299)
==14822== by 0x40F47B: feh_load_image (imlib.c:252)
==14822== by 0x42CA0E: winwidget_loadimage (winwidget.c:753)
==14822== by 0x42C918: winwidget_create_from_file (winwidget.c:126)
==14822== by 0x421869: init_slideshow_mode (slideshow.c:62)
==14822== by 0x418F13: main (main.c:78)
==14822==
when scaling id:000407,src:000226,op:havoc,rep:32 in feh.
Was supposed to fixes:
==24603== Invalid read of size 1
==24603== at 0x1FCD748: __imlib_ScaleAARGB (scale.c:990)
==24603== by 0x1F9BF81: __imlib_RenderImage (rend.c:405)
==24603== by 0x1F0F82C: imlib_render_image_part_on_drawable_at_size (api.c:1886)
==24603== by 0x40CD75: gib_imlib_render_image_part_on_drawable_at_size (gib_imlib.c:231)
==24603== by 0x42C732: winwidget_render_image (winwidget.c:576)
==24603== by 0x417ACA: feh_event_handle_keypress (keyevents.c:598)
==24603== by 0x4190DE: feh_main_iteration (main.c:119)
==24603== by 0x418F45: main (main.c:82)
==24603== Address 0x4824832 is 3,650 bytes inside a block of size 4,096 free'd
==24603== at 0x103E498: free (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==24603== by 0x234157D: fclose (fclose.c:62)
==24603== by 0x5B3CD7F: load (loader_pnm.c:540)
==24603== by 0x1F7D70F: __imlib_LoadImage (image.c:1041)
==24603== by 0x1F090E4: imlib_load_image_with_error_return (api.c:1299)
==24603== by 0x40F47B: feh_load_image (imlib.c:252)
==24603== by 0x42CA0E: winwidget_loadimage (winwidget.c:753)
==24603== by 0x42C918: winwidget_create_from_file (winwidget.c:126)
==24603== by 0x421869: init_slideshow_mode (slideshow.c:62)
==24603== by 0x418F13: main (main.c:78)
when using feh to scale input/queue/id:000407,src:000226,op:havoc,rep:32
but isn't sufficient by itself.
Still looks correct to me, though.
Prevents invalid reads and unreasonably large memory allocations
with input/queue/id:000210,src:000114,op:int32,pos:3,val:be:+32,+cov:
==20321== Invalid read of size 1
==20321== at 0x1FCDB16: __imlib_ScaleAARGB (scale.c:1043)
==20321== by 0x1F9BF81: __imlib_RenderImage (rend.c:409)
==20321== by 0x1F0F82C: imlib_render_image_part_on_drawable_at_size (api.c:1886)
==20321== by 0x40CD75: gib_imlib_render_image_part_on_drawable_at_size (gib_imlib.c:231)
==20321== by 0x42C732: winwidget_render_image (winwidget.c:576)
==20321== by 0x417ACA: feh_event_handle_keypress (keyevents.c:598)
==20321== by 0x4190DE: feh_main_iteration (main.c:119)
==20321== by 0x418F45: main (main.c:82)
==20321== Address 0x3a12e034 is 12 bytes before a block of size 1,965,846,976 alloc'd
==20321== at 0x103D293: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==20321== by 0x5B3D1F1: load (loader_pnm.c:149)
==20321== by 0x1F7D70F: __imlib_LoadImage (image.c:1041)
==20321== by 0x1F090E4: imlib_load_image_with_error_return (api.c:1299)
==20321== by 0x40F47B: feh_load_image (imlib.c:252)
==20321== by 0x42CA0E: winwidget_loadimage (winwidget.c:753)
==20321== by 0x42C918: winwidget_create_from_file (winwidget.c:126)
==20321== by 0x421869: init_slideshow_mode (slideshow.c:62)
==20321== by 0x418F13: main (main.c:78)
Summary:
From giflib-5.1.0's NEWS:
"A small change to the API: DGifClose() and EGifClose() now take a
pointer-to-int second argument (like the corresponding openers)
where a diagnostic code will be deposited when they return
GIF_ERROR."
Test Plan:
I've built imlib2 against giflib-4.2.3 and 5.1.0 and opened a few
gif files with feh.
Reviewers: kwo
Reviewed By: kwo
Differential Revision: https://phab.enlightenment.org/D1529
When building out-of-source, the headers are located in subdirectories
in $(top_srcdir) rather than $(top_builddir). Adjust AM_CPPFLAGS
accordingly.
URL: https://bugs.gentoo.org/510522
This fixes warnings with newer compilers/distros that enable warning
flags by default:
loader_zlib.c: In function 'uncompress_file':
loader_zlib.c:33:17: warning: ignoring return value of 'write',
declared with attribute warn_unused_result [-Wunused-result]
write(dest, outbuf, bytes);
^
- Eliminate deprecated AC_TRY_CPP.
- Use pkg-config in stead of freetype-config to get freetype info.
- Eliminate my_includes/my_libs.
- Clean up include paths.
Drawing of the closing line could be skipped depending on the specific
vertex coordinates (and order).
Can't say that I undestand the code completely but this change seems
to fix the problem, and I don't think it can cause trouble.
Kim Woelders
Fabian Keil
Heiko Becker
Michał Górny
Mike Frysinger