Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 767799 - media-libs/freeimage[tiff]: breaks consumers that use libtiff (media-libs/tiff) and possibly not entirely functional
Summary: media-libs/freeimage[tiff]: breaks consumers that use libtiff (media-libs/tif...
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Gentoo Games
URL: https://github.com/eXeC64/imv/issues/309
Whiteboard:
Keywords:
Depends on:
Blocks: 833903
  Show dependency tree
 
Reported: 2021-01-29 05:06 UTC by Ionen Wolkens
Modified: 2022-06-28 10:02 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
backtrace + emerge --info.txt (backtrace-emerge-info.txt,8.28 KB, text/plain)
2021-01-29 05:06 UTC, Ionen Wolkens
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ionen Wolkens gentoo-dev 2021-01-29 05:06:06 UTC
Created attachment 685005 [details]
backtrace + emerge --info.txt

Been experiencing segfaults opening TIFF images with media-gfx/imv and, if I'm not wrong, the issue traces back to the unbundling patch used by Gentoo on freeimage.

freeimage[-tiff] with imv[tiff]: works
freeimage[tiff] with imv[-tiff]: segfault
freeimage[tiff] with imv[tiff]: imv's libtiff backend fails because it uses freeimage's TIFFOpen (which does nothing but return 0) rather than linked libtiff's, then tries freeimage backend and segfaults.

Linking against vanilla freeimage works in every situations.

No difference between freeimage-3.18.0-r1 and -r2, so this isn't caused by the tiff security patch.

Was experiencing this issue while testing imv-4.2.0 (bump PR pending), but reproducible with in-tree 4.1.0 as well.

If no easy solution then masking tiff on freeimage "would" work for me but games-util/slade currently depends on it. The entire tiff handling seem like a bad hack.


Happening in backend_libtiff.c which is trying to call TIFFOpen from libtiff:

Thread 1 "imv" hit Breakpoint 1, TIFFOpen (name=0x5555555b7ce0 "/tmp/test.tif", 
    mode=0x5555555695b0 "r") at Source/FreeImage/PluginTIFF.cpp:207
207             return 0;


And then tries gentoo's freeimage:

Thread 3 "imv" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff1e0f640 (LWP 17606)]
0x00007ffff793dc95 in TIFFFieldTag (fip=0x100000000)
    at /tmp/portage/media-libs/tiff-4.2.0/work/tiff-4.2.0/libtiff/tif_dirinfo.c:758
758             return fip->field_tag;
Comment 1 James Le Cuirot gentoo-dev 2021-01-29 22:22:19 UTC
I don't think it's entirely the patch's fault. FreeImage redefines a bunch of the standard libtiff functions, including this one. I'm not sure what happens with the vanilla build but when patched, it exports symbols like TIFFOpen. If these symbols were hidden then perhaps the issue would go away. This isn't an area I'm very familiar with though. Do you want to have a go?
Comment 2 Ionen Wolkens gentoo-dev 2021-01-29 22:39:56 UTC
Not something I'm particularly familiar with either, merely made observations.

I'd be very thankful if someone else could have a look, but if it comes down to it I'll see what I can do.

There seem to be possibly two issues here, but as long as imv[tiff]'s backend can work (with right TIFFOpen) then it at least won't reach freeimage's to fail there affect very few users.
Comment 3 Ionen Wolkens gentoo-dev 2022-06-28 10:02:12 UTC
Hm, unsure why but this issue seem to have went went away with freeimage-3.18.0-r8 and the >=tiff-4.4.0 dependency, all 3 of the mentioned cases work now (still segfaults/fail if go back to -r7).

I imagine it may not be truly fixed, but it's not causing issues for imv's use case anymore.