So I've been running on plasma-wayland by default for many months (>1 year?) now, but kuickshow hasn't been merged until now. FWIW gwenview's my primary image viewer but I usually keep a second one around, which was the gtk2-based gimv until it was recently tree-cleaned due to dead upstream and no gtk3 port. So I was looking for a replacement and since I run plasma anyway, I was happy to see kuickview (which I fuzzily remember from the kde3/4 era) still around. Kuickview merged fine but it wouldn't run, segfaulting before ever opening a window, and gdb wasn't particularly helpful initially due to stripped debug info. Fortunately it's a trivial build and a bit of debug-rebuilding later I had this: Thread 1 "kuickshow" received signal SIGSEGV, Segmentation fault. 0x00007ffff7f649dd in KuickShow::initImlibParams (this=0x5555555a4e30, idata=0x555555618070, par=0x7fffffffd860) at ../kuickshow-0.10.2/src/kuickshow.cpp:1253 In the source that's... 1247 void KuickShow::initImlibParams( ImData *idata, ImlibInitParams *par ) 1248 { ... 1253 Visual* defaultvis = DefaultVisual(getX11Display(), getX11Screen()); Again, I'm on (plasma/kwin-)wayland, but of course xwayland is running to provide legacy X compatibility (and yes the DISPLAY var is set appropriately, double-checked in the gdb-suspended kuickshow env and it's there). Unfortunately that doesn't appear to be enough in this case. Double-unfortunately, checking gentoo's kuickshow bug history I saw the old (IIRC) 2017 bug where it was temporarily treecleaned due to dead upstream, and a current equery meta suggests upstream's still dead, so with qt6/kde-frameworks6 around the corner, while the package probably still works on xorg[1] for the moment I'm guessing it's pretty much a dead-package-running... Fortunately for me kuickshow being a newly merged package I was trying to run, it's not like I've a workflow embedding it or something. So if you just want to WONTFIX the bug I'm fine with it. But as I had the investigative work already done and didn't see anything like this bug filed yet, I thought I'd file it to give you (and other users on or switching to wayland) a heads-up in any case, and since it's a really small build, with the also small imlib being the only dep I didn't already have merged, if you want to try fixing it I'm up for testing patches. =:^) (I guess I'll try a gtk option now. There seem to be several available to try. Hopefully I'll find something gtk3 and wayland-native...) --- [1] I so seldom start plasma on X that it tends to be bit-rotted when I do. Plasma on xorg has been black-screening on me (but the purple gentoo-theme cursor loads so I can see xorg is running, and apparently at least some of the autostart apps run too as when I quit and restart in wayland it's obvious they ran in xorg, I just can't /see/ anything in xorg but that colorful pointer on an otherwise black screen) for I guess a couple months now, but it hasn't been a priority "because wayland". Of course part of the problem there could be that I'm running the live-git-9999 frameworks and plasma from the gentoo/kde project overlay, tho I'd have expected it to be fixed by now if that was the entire story, but I've not bothered investigating further. Anyway, xorg is broken ATM and I don't know when/if it'll work again, so I can't test kuickshow there.
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.
