Bug#945828: background info
florian.schmidt at dlr.de
Tue Mar 3 11:52:41 GMT 2020
i spent the last 4 days searching because of this bug.
originally i started to write a bug report against libgdk-pixbuf2.0-0
but further investigations revealed the ugly root cause.
it was very hard to "google" this. maybe adding some pointers and
related keywords here will help upcoming victims...
as enrico reported, update-mime-database will not check readdir() for
error-return. instead it will silently create an emtpy mime cache.
this will cause e.g. all gdk pixbuf users to get an error message like
Couldn’t recognize the image file format for file XY
and that while
is completely fine.
gdk pixbuf relies on glib's xdg_mime stuff which reads
it might sound like an unimportant bug, to fix that error checking, but
it seems the only good way to notify people that there is something
wrong going on.
and i think it definitely is a bug within update-mime-database to
silently and happily create an empty mime cache while there always is at
least freedesktop.org.xml to be expected in /usr/share/mime/packages/
because it is installed with that package.
so i would suggest to at least output some warning message in case
/usr/share/mime/packages/ is discovered completely empty.
running 32bit processes via qemu-user-static on a 64bit linux kernel
with a chroot will cause readdir() to error-out with
EOVERFLOW - Value too large for defined data type
for processes that are compiled without "-D_FILE_OFFSET_BITS=64" and for
directories on an ext4 filesystem.
this problem surfaced because of a change in glibc:
linux kernel bug:
i stumbled upon this when preparing an armhf buster rootfs via
multistrap (or debootstrap) and qemu-user-static on my x86_64 buster
host that uses an ext4 filesystem.
if update-mime-database would error-out because of that readdir() error
i would have seen that something is wrong and had something to search for.
with the current situation i had no indication at all and had to start
debugging gdk pixbuf, leading to glib, leading to an empty mime.cache
and further debugging of update-mime-database leading to the EOVERFLOW
please add this error-out to save others from having to go through this!
a workaround that made readdir() work in that scenario was to compile it
with large-file support (-D_FILE_OFFSET_BITS=64) which can be achieved
by adding the macro
attached a patch that does both.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1277 bytes
Desc: not available
More information about the Pkg-freedesktop-maintainers