Summary: | media-gfx/kuickshow-0.10.2 on wayland segfaults at kuickshow.cpp:1253 (getX11Display/getX11Screen calls) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Duncan <1i5t5.duncan> |
Component: | Current packages | Assignee: | Christian Gerloff <chrgerloff> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | proxy-maint |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 880043 | ||
Bug Blocks: | |||
Attachments: |
debug code to narrow down the cause of the bug
a workaround to always use screen 0 |
Description
Duncan
2021-08-24 17:44:38 UTC
Created attachment 735935 [details, diff]
debug code to narrow down the cause of the bug
Thank you for the bug report and the initial analysis! I'm going to set up a Wayland environment to try and replicate this error. Wayland has never worked for me in the past (in a similar way to what you experience when trying to start xorg/plasma), so I couldn't test KuickShow with it. It does work fine in xorg/plasma. It is my primary image viewer and I'm using it quite often. The error looks like either something is returning a null pointer or an unexpected value caused an invalid memory access (getX11Screen() / QDesktopWidget->screenNumber(...) could return -1, but the code doesn't test for it...) If you have the time could you please add the following code in front of the line you identified and post its output? (I've attached a Gentoo user patch.) + printf("getX11Display() = %p\n", (void*) getX11Display()); + printf("getX11Screen() = %d\n", getX11Screen()); + printf("ScreenOfDisplay(...) = %p\n", (void*) ScreenOfDisplay(getX11Display(), getX11Screen())); Visual* defaultvis = DefaultVisual(getX11Display(), getX11Screen()); It should print something like this on startup: getX11Display() = 0x55c465a6a300 getX11Screen() = 0 ScreenOfDisplay(...) = 0x55c465a6b890 Thank you! ping, any progress here? Duncan, can you test the patch? Hmm... 10 months later. Maybe I need to be more careful saying I'm up for testing patches. =:^\ Anyway, tested it now. Funny thing, as downloaded all the lines endings on the patch were MS-style CRLFs, not Linux-style LFs only. At first I thought it was a bug with the new firefox-bin-102.0 I merged today (bumped in my overlay as it wasn't in-tree yet when I updated), but I checked a patch I had uploaded on one of my bugs and it was fine, so it seems to be this patch, not a firefox bug. Anyway, ^Ms manually deleted... [With the debugging patch but built with normal C/CXXFLAGS and stripped, and run directly from konsole, not via gdb] $ kuickshow getX11Display() = 0x57ccfd953d60 getX11Screen() = 1 ScreenOfDisplay(...) = 0x80 Segmentation fault So nothing there seems to be null, but ScreenOfDisplay is only 2-hexits, much smaller than your example. Interesting! I have weston merged as a backup wayland compositor in case kwin goes haywire (it's live-git kwin-9999 from the kde overlay after all, and I no longer have xorg merged, so a barebones weston compositor backup isn't a bad idea!) and I decided to try running kuickshow from it, using its weston-terminal not konsole. It WORKS! Furthermore, still with the debugging patch installed, the output is: $ kuickshow getX11Display() = 0x5b6ec1a04320 getX11Screen() = 0 ScreenOfDisplay(...) = 0x5b6ec1a05b40 no current index While in weston (which I'm still running from ATM, launching firefox to load this bug from a weston-terminal too) I decided to start konsole and try launching kuickshow from there, just in case the terminal it was launched from (maybe env var inheritance or some such) had something to do with it. No. kuickshow launched from konsole (launched from weston-terminal as that's the default and only direct launching button setup) works fine too, resulting in similar output. So maybe that 0x80 ScreenOfDisplay that kwin evidently sets has something to do with it? kwin_wayland bug, maybe? Wait!! Another possibility just occurred to me, and actually seems most likely given the new information above: When in wayland with the kwin_wayland compositor, most kde/qt/gtk3 apps seem to start in native wayland mode. In weston, firefox starts in native wayland mode, but cursor hints suggested konsole and kuickshow are running in X mode (via xwayland). Indeed. Using xprop (which I still have installed for use with xwayland) window-picker mode, I can confirm that both konsole and kuickshow start in X mode, while firefox and weston-terminal are invisible to xprop's window-picker so are running in native wayland mode. Of course back on kwin_wayland kuickshow will segfault before displaying a window so I can't so easily confirm whether it's trying to run in native wayland mode or in X mode there, but I suspect it's trying to run in native wayland mode, but still has some X assumptions that aren't valid there, thus the segfault. Meanwhile, there *is* a way to tell kde/qt apps to run in X mode (some environmental var I need to set in a wrapper), but I can't recall it ATM. I'll have to see if I can find it again and try that. I'm betting that will work! [Meanwhile, with kuickshow actually running in X mode under weston, I can see it does indeed offer the reasonably simple but still including flipping/rotating/etc interface I sort of remembered from kde3/4 era and was hoping it had. It should be useful, at least for now, as unfortunately it does seem to be living on borrowed time unless it's ported to qt6/frameworks6 and ideally wayland, and with you being effectively upstream, I'm not sure you're interested enough in that.] OK, back on kwin_wayland. * Trying from weston_terminal under kwin_wayland doesn't work. * Seems one of the switcher options was -platform [wayland, xcb, ...]. * Trying kuickshow -platform wayland gives me the usual ScreenOfDisplay 0x80, apparently confirming that is indeed what it was doing, native wayland, which kuickshow doesn't like. * Unfortunately, trying -platform xcb, while it gives me a more normal ScreenOfDisplay, still segfaults: $ kuickshow -platform xcb getX11Display() = 0x5a853d2ca320 getX11Screen() = 1 ScreenOfDisplay(...) = 0x5a853d2cbba0 Segmentation fault But I don't know if it's at the same place. I guess I'd have to setup -Og and FEATURES=nostrip again to see... * The other switcher option is an environmental var: QT_QPA_PLATFORM=[xcb, wayland, ...] * Seems to have the same results as using the corresponding -platform option above. [So I need to quit and get some sleep now, > 24 awake tho I caught up yesterday so it's not /so/ bad, but I gotta work in a few hours... Unfortunately, once I quit I'm not sure I'll get back to it in a reasonable time, but it is what it is.] At least I know it's /possible/ now, given the xwayland-on-weston results. And quite a bit of progress today... Created attachment 804661 [details, diff]
a workaround to always use screen 0
Hello Duncan, thank you for the updates! I'm sorry it took me so long to respond, work was a little bit hectic for me these last couple of months. This one was the (or at least one) problem: > $ kuickshow > getX11Display() = 0x57ccfd953d60 > getX11Screen() = 1 > ScreenOfDisplay(...) = 0x80 > Segmentation fault It detected that the application's screen was number 1 (starts at 0, so this is the second screen), but the pointer returned was 0x80 which is not a valid pointer. If I had to guess I'd say that getX11Screen() sees a multi-monitor setup as individual screens while ScreenOfDisplay() just sees one big one. Until I've analyzed this fully, a short-term fix could be to replace the call to getX11Screen() with a zero: > - Visual* defaultvis = DefaultVisual(getX11Display(), getX11Screen()); > + Visual* defaultvis = DefaultVisual(getX11Display(), 0); Then it should work with "-platform xcb", assuming that there's at least one screen in the X11 Display that is used there. I've provided a patch for it (it will only apply without the debug-patch). Currently, KuickShow will only run in X mode. When I ported it from KDE4 I've only updated the build-system and the Qt-related changes. If there is code for Wayland in there it wasn't done by me, since I couldn't test it due to a lack of a working Wayland environment. Though I've just got one to work a week ago on a completely new PC, so now I'll be able to properly test it there. BTW, that exact crash is also happening there for me (with getX11Screen() = 1 and ScreenOfDisplay() = 0x80) if I just try to run it after install. And to answer your other question: I will definitely try to port KuickShow to Qt6 at some point. This is my main image viewer and I'm reluctant to switch to another. The replacement of the deprecated imlib is still the first thing I have to do before I can start with Wayland support. |