It appears that media-libs/imlib2-1.5.1 (just stabilized about a week ago) causes problems when the program using imlib2 is run remotely using X11 forwarding. I've been able to reproduce this using the feh and qiv programs remotely from several remote systems using differing X11 drivers (one with nVidia and one with the X11 intel). Downgrading back to 1.4.9 corrects this.
What happens is that the program locks up and can only be killed with kill -9. I also noticed that on the client machine, I get messages like this in /var/log/Xorg.0.log:
[1944940.082] Using O_TMPFILE
...which do not occur with imlib2-1.4.9 on the host when things work correctly. As yet I have no idea what that means.
Okay, this seems a bit harder to solve. Thanks for the report.
I see many X-related things have changed between 1.4.9 and 1.5.1, but I think this could be the closest for this problem,
(You could try installing *xcb* related packages if that helps)
I think you should definitely report this upstream as they are more capable of helping you. I saw a bug report about this in arch linux but it was targeted towards xorg-server. Still unsolved,
There's one thing you could try if you just are willing. Modify the 1.5.1 ebuild and add
inside local myconf_imlib2=( ... ) somewhere. Verify from configure / build.log that it's indeed disabled, then build and test.
Arch also packages imlib2 with custom --x-libraries=DIR but I dont think thats related. Might also be related to stable-unstable xorg etc...
But I suggest you to make a bug upstream. I will try to reproduce this next weekend when I have more time.
Thanks!...and yes adding that --without-x-shm-fd to the ebuild in my local overlay does correct this. I also noticed that without that, using programs like feh even locally always adds those "Using O_TMPFILE" messages to /var/log/Xorg.0.log, though it does work.
I'll see if I can get a bug logged upstream. Thanks again!
Holy crap. I want the last hour of my life back. I CANNOT figure out how to log a bug for that project at all. I created an account on the site you linked (including a nearly endless bout with that godless Google reCaptcha travesty) and can't find any means of doing it there ir even posting some sort of comment. Something there implied that bugs could logged at https://discourse.phabricator-community.org/c/bug so I created an account there but frankly that doesn't look right either. At this point I don't even get who/what that project is managed by.
I give up. Maybe you can figure it out.
Thanks for testing and confirming. I'll prepare a -r1 bump once I grasp the meaning of 'x-shm-fd', and can it be made optional or not.
Yeah I was a bit fault there too. Their ticketing system is a bit messy :P
I shouldve given you direct links,
https://phab.enlightenment.org/maniphest/task/edit/form/2/ to report new bugs and
https://www.enlightenment.org/contrib/report-bug.md for README. However Im not sure if this is their bug anymore with the revelation of --without-x-shm-fd. I'll try to work it out and I will report a bug if it belongs to imlib2 developers. Sorry to see you wasted your time, but thanks for your efforts! :)
I think that "O_TMPFILE" is somehow related to xorg, and there's a patch to "silence" it submitted to xorg-server.
I'm gonna keep this bug open for a while for others who might face the issue (until 1.5.1-r1 is stabilized).
Thanks! I'm unclear on that O_TMPFILE thing as well. In general that appears to be related to creating secure tmp files, though I have no idea how it's being used in X in this case.
That xorg-server server patch is clearly just to silence the logging, but here's what I suspect as far as the X11Forwarding lockups:
My guess is that imlib2 is attempting to use that O_TMPFILE feature, which is probably creating some sort of tmp file handle on the host where the actual code is running, without verifying whether or not X is actually being run locally at all. That is, X on the client machine may be trying to use a tmp file that's literally on the wrong computer. That would explain hard lockups for sure.
I mistakenly thought you were going to log a bug upstream, but I must have misread something. I just entered this upstream...hopefully that's correct, as that's a pretty confusing system they have:
Right, I forgot about this. Sorry.
But I still have a feeling that it's probably not an upstream bug to imlib2 as they provide a configure option to "fix" it, I was going to research a bit about that shm thing and what changes in xorg cause that O_TMPFILE. So it might be a bug in xorg, and that's already reported. I should get back to this, but I'm going for a vacation for ~2 weeks and hopefully don't have to touch computers during :)
I'll track your bug on E's bugtracker now that its made, to get some sense for this situation. Thanks.
We'll see what they say, but I still strongly suspect that they're simply attempting to use that feature without verifying whether or not X is even being run locally, which would simply be a mistake, and not something that should require compiling the feature out of the library.
If you didn't see in the upstream bug already, I stand corrected. The lockups were an Xorg bug which has been resolved, but only in master:
Also note the mention of the IMLIB2_SHM_OPT environment variable, which is another work-around other than building with --without-x-shm-fd.
So I guess there's really nothing to resolve here.
Thanks for being so active on this. Let's keep the bug open until PR to update imlib2 into 1.5.1-r1 gets merged, so if anyone experiences the same issues, they will find this easily.
The bug has been closed via the following commit(s):
Author: Joonas Niilola <firstname.lastname@example.org>
AuthorDate: 2018-07-11 15:16:15 +0000
Commit: Andreas Sturmlechner <email@example.com>
CommitDate: 2018-07-22 23:21:53 +0000
media-libs/imlib2: 1.5.1: EAPI-7 revbump with new USE flags
Added 'doc' for documentation and 'shm' for X shared memory support.
media-libs/imlib2/imlib2-1.5.1-r1.ebuild | 72 ++++++++++++++++++++++++++++++++
media-libs/imlib2/metadata.xml | 3 ++
2 files changed, 75 insertions(+)