tomboy-ng
tomboy-ng copied to clipboard
tomboy-notes
tomboy-ng unexpectedly crashes (per KDE) when using tray icon
tomboy-ng-20191230-110216.kcrash.txt openSUSE 15.1 (Leap) KDE tomboy-ng 0.25.2 (qt5 RPM)
I've noticed that as long as I have a tomboy-ng window open somewhere, the system tray icon to open notes, open the search window, or go to settings, works just fine. If I close the last note window, though, the next time I try to use the system tray icon the application crashes. This has happened several times now, and this last time I saved out the crash text which is down below.
Before installing the first time last night I had to manually tell the system to install the libQt5Pa1 package in order to provide libQt5Pas1.so.1 but with that done the tomboy-ng package installed just fine, on two systems now (I may be able to help figure out why the dependency resolution is not working if that's useful). That libQt5Pas1 package's metadata follow:
Name : libQt5Pas1 Version : 2.0.2 Release : lp151.1.4 Architecture: x86_64 Install Date: Mon 30 Dec 2019 07:58:14 AM MST Group : System/Libraries Size : 2702277 License : LGPL-3.0-only Signature : RSA/SHA256, Fri 03 May 2019 07:10:37 PM MDT, Key ID b88b2fd43dbdc284 Source RPM : lazarus-2.0.2-lp151.1.4.src.rpm Build Date : Fri 03 May 2019 07:01:47 PM MDT Build Host : lamb20 Relocations : (not relocatable) Packager : https://bugs.opensuse.org Vendor : openSUSE URL : http://www.lazarus.freepascal.org/ Summary : Free Pascal interface to Qt5 Description : Library that allows to use Qt5 with Free Pascal Distribution: openSUSE Leap 15.1
Crash dump text:
Application: tomboy-ng (tomboy-ng), signal: Segmentation fault Using host libthread_db library "/lib64/libthread_db.so.1". [Current thread is 1 (Thread 0x7fbb698398c0 (LWP 8874))]
Thread 5 (Thread 0x7fbb3a02a700 (LWP 8878)): #0 0x00007fbb694358ad in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fbb3acd09ab in ?? () from /usr/lib64/dri/i965_dri.so #2 0x00007fbb3acd06b7 in ?? () from /usr/lib64/dri/i965_dri.so #3 0x00007fbb6942f569 in start_thread () from /lib64/libpthread.so.0 #4 0x00007fbb6878f9ef in clone () from /lib64/libc.so.6
Thread 4 (Thread 0x7fbb45f61700 (LWP 8877)): #0 0x000000000041cc1d in ?? () #1 0x0000000000000000 in ?? ()
Thread 3 (Thread 0x7fbb4e799700 (LWP 8876)): #0 0x00007fbb69438eb8 in read () from /lib64/libpthread.so.0 #1 0x00007fbb63a10ca0 in ?? () from /usr/lib64/libglib-2.0.so.0 #2 0x00007fbb639cbcb8 in g_main_context_check () from /usr/lib64/libglib-2.0.so.0 #3 0x00007fbb639cc150 in ?? () from /usr/lib64/libglib-2.0.so.0 #4 0x00007fbb639cc2bc in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #5 0x00007fbb66a4c96b in QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from /usr/lib64/libQt5Core.so.5 #6 0x00007fbb669f190a in QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) () from /usr/lib64/libQt5Core.so.5 #7 0x00007fbb6680fdaa in QThread::exec() () from /usr/lib64/libQt5Core.so.5 #8 0x00007fbb5efa09e5 in ?? () from /usr/lib64/libQt5DBus.so.5 #9 0x00007fbb66814ced in ?? () from /usr/lib64/libQt5Core.so.5 #10 0x00007fbb6942f569 in start_thread () from /lib64/libpthread.so.0 #11 0x00007fbb6878f9ef in clone () from /lib64/libc.so.6
Thread 2 (Thread 0x7fbb5bffe700 (LWP 8875)): #0 0x00007fbb6878519b in poll () from /lib64/libc.so.6 #1 0x00007fbb65f9f307 in ?? () from /usr/lib64/libxcb.so.1 #2 0x00007fbb65fa0f3a in xcb_wait_for_event () from /usr/lib64/libxcb.so.1 #3 0x00007fbb5f496939 in ?? () from /usr/lib64/libQt5XcbQpa.so.5 #4 0x00007fbb66814ced in ?? () from /usr/lib64/libQt5Core.so.5 #5 0x00007fbb6942f569 in start_thread () from /lib64/libpthread.so.0 #6 0x00007fbb6878f9ef in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7fbb698398c0 (LWP 8874)): [KCrash Handler] #6 0x00007fbb5a0ccfb9 in KStatusNotifierItem::activate(QPoint const&) () from /usr/lib64/libKF5Notifications.so.5 #7 0x00007fbb5a0d3a22 in ?? () from /usr/lib64/libKF5Notifications.so.5 #8 0x00007fbb5a0ebb29 in ?? () from /usr/lib64/libKF5Notifications.so.5 #9 0x00007fbb5a0ec0b5 in ?? () from /usr/lib64/libKF5Notifications.so.5 #10 0x00007fbb5efabd98 in ?? () from /usr/lib64/libQt5DBus.so.5 #11 0x00007fbb5efb1049 in ?? () from /usr/lib64/libQt5DBus.so.5 #12 0x00007fbb5efb160c in ?? () from /usr/lib64/libQt5DBus.so.5 #13 0x00007fbb5efb3d2e in ?? () from /usr/lib64/libQt5DBus.so.5 #14 0x00007fbb66a230a2 in QObject::event(QEvent*) () from /usr/lib64/libQt5Core.so.5 #15 0x00007fbb67d2c3dc in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5 #16 0x00007fbb67d33ca4 in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5 #17 0x00007fbb669f38d8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib64/libQt5Core.so.5 #18 0x00007fbb669f604d in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib64/libQt5Core.so.5 #19 0x00007fbb66a4d323 in ?? () from /usr/lib64/libQt5Core.so.5 #20 0x00007fbb639cbe87 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #21 0x00007fbb639cc230 in ?? () from /usr/lib64/libglib-2.0.so.0 #22 0x00007fbb639cc2bc in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #23 0x00007fbb66a4c94f in QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from /usr/lib64/libQt5Core.so.5 #24 0x0000000000550a59 in ?? () #25 0xffffffff697f9b70 in ?? () #26 0x00007fbb697f9fb0 in ?? () #27 0x00007fff910467e0 in ?? () #28 0x0000000000441919 in ?? () #29 0x0000000000000000 in ?? () [Inferior 1 (process 8874) detached]
I thought this was related to having a note open, or not, but I've seen a few cases where that has not mattered; notes have been open, and it has crashed . I've been opening and closing notes, and it has crashed. This last time, I merely clocked on the tray icon, then made it go away, and on the fourth time it crashed. Are there any steps I can take to narrow this down a bit more, or find out the root cause of the crash? The dump text above looks pretty unhelpful.
Thanks dajoker, a detailed bug report is valuable ! Firstly, sad that you have had to manually install libqt5pas1, What I have done is make a deb package, convert that to an rpm via alien. Sounds like the dependency is not making it through that transition. And my testing did not pick it up. Sigh ... Next issue, the big one is the crash. I have not experienced anything like that. The "no window open" must be a clue but does not bring anything to mind. Looking at your dump indicates to me that the problem may be in the Qt loop rather than my code. The Qt version of tomboy-ng is new and relatively untested. And unlike the GTK version, I have not been using it pre-release personally because my platform is Ubuntu18.04 and its Qt is a problem, Ubuntu's 'unattended update' tool keeps overwriting my fix. sigh....
We have a few approaches possible. Firstly, I can make you a new binary with debugging included, its a lot bigger and a bit slower but might just localise the problem. Secondly, you could try the gtk version, particularly easy if you already have some GTK2 apps installed, otherwise it will involve about 300Meg extra disk usage when the necessary libraries are installed.
How do you want to approach this ?
Further on, its going to need to be run, and hopefully crash, from within the Lazarus IDE so the debugger can catch it and show us whats really happening. Two ways, you tell me about your system and I'll try to build a VM and replicate your problem. Secondly, if you are feeling really brave, you could try installing Lazarus, et al and try it on site. Big job and will depend a lot on how keen you are and require some programming background. Honestly, its my problem ...
Davo
Davo
If you are willing to share instructions I'd be happy to try them all. For now I'll see what the GTK version does, since that might be easiest for you and since I likely have GTK stuff installed anyway (Pidgin makes me think it is GTK-based). Ultimately I like learning new troubleshooting techniques, and feel like I might learn a lot from something like this.
I saw, from the manpage, that there is some debugging within the executable. I presume that is not sufficient, and since you mentioned the size and speed, I presume you mean debugging symbols and such.
Based on the package version I posted above, my package version may not be as new as others, both supporting your theory it is Qt-related and that it's something impacting me but not you.
I saw the script in the git repository that converts from .deb to .rpm using alien, and it looks like you specifically create a spec file. Do you have that intermediate spec file handy as it was fed to rpmbuild in there? Reviewing it might be interesting.
If Lazarus is something I can try I'll do that. As mentioned, I have a second laptop on which I can try to duplicate the issue (I'll try that tonight for sure) and on which I can do any amount of debugging without worrying about my previous notes. I've done debugging in IDEs (Eclipse, Zend Studio) before, and have experience with other languages (Java, Perl, and PHP the most).
If you get bored and want to try out a distro WAY better than Ubuntu ;-) then getting openSUSE going is really easy, either with a network-based install or a full DVD install. If handy for you I could probably create it (KVM, VirtualBox, or maybe VMware) and send a disk file over once I have it duplicated.
P.S. I realized the no-undo (Ctrl-Z) bit this afternoon too. As you saw from the other reported issues, that would be a big nice-to-have.
Somehow I forgot to past the openSUSE media URL: https://software.opensuse.org/distributions/leap
Yep, sounds like you are on right track. Pidgin is GTK2, the debugging command line switches won't help in the part the crash appears to happen in. Alien makes that spec file for us but I do play with it mid process. I am not too worried about the libqt5pas1 issue, its quite fixable. The crash does worry me ! Can you tell me what version of Qt5 you are using ? That might be important. I don't remember right now how to find out, nor what the minimum version is but can look it up ... I do have a openSUSE VM I have been testing on, Leap 15.1. (Did not like it, but we all hate unfamiliar stuff !).
yeah, undo/redo is a big miss, long story, relates to the RichText editing component (ie library, widget...) I have used. I have been considering replacing it with another, rival one but thats got a few issues on MacOS ....
To build your own -ng you would need to install FPC and FPC-SRC, easy, packages available. Plus Lazarus, dated packages, better to build on the fly. Plus KControls, easy from within Lazarus but needs a patch to deal with a bug I logged almost two months ago (!). If and when you are ready, let me know and I can provide some useful details.
Davo
Hmm, my OpenSuse VM is Gnome only, don't think I want to install QT5 on it yet, might clone it to keep it a clean install. If you have qmake available, you could try qmake -query [enter] // note single dash :-( You could also try, if you have a bit of free time - find / -name "libqt5*" 2> /dev/null [enter] That might tell us your qt version. As I remember it, need at least Qt5.12 (which is newer than Qt5.9) but there are some grey areas .....
Queried all the 'libqt'-containing packages in the system:
rpm -qa | grep -i libqt
libqt5-qtimageformats-5.9.7-lp151.1.2.x86_64 libqt4-sql-sqlite-4.8.7-lp151.8.4.x86_64 libqt5-qtgraphicaleffects-5.9.7-lp151.1.2.x86_64 libQt5WebKitWidgets5-5.212~alpha2-lp151.5.37.x86_64 libQt5Test5-5.9.7-lp151.3.1.x86_64 libQt5Sql5-sqlite-5.9.7-lp151.3.1.x86_64 libQt5Widgets5-5.9.7-lp151.3.1.x86_64 libQt5Script5-5.9.7-lp151.1.37.x86_64 libQt5Sensors5-imports-5.9.7-lp151.1.3.x86_64 libQt5QuickControls2-5-5.9.7-lp151.1.3.x86_64 libQt5Pas1-2.0.2-lp151.1.4.x86_64 libqt4-x11-4.8.7-lp151.8.4.x86_64 libQt5Concurrent5-5.9.7-lp151.3.1.x86_64 libQt5Xml5-5.9.7-lp151.3.1.x86_64 libQt5Sensors5-5.9.7-lp151.1.3.x86_64 libQtQuick5-5.9.7-lp151.2.2.x86_64 libQt5WebChannel5-5.9.7-lp151.1.2.x86_64 libQt5WebChannel5-imports-5.9.7-lp151.1.2.x86_64 libqt5-qtquickcontrols2-5.9.7-lp151.1.3.x86_64 libqt4-4.8.7-lp151.8.4.x86_64 libqt4-sql-4.8.7-lp151.8.4.x86_64 libqt4-qt3support-4.8.7-lp151.8.4.x86_64 libQt5Multimedia5-5.9.7-lp151.1.3.x86_64 libQt5Positioning5-5.9.7-lp151.1.3.x86_64 libQt5Sql5-5.9.7-lp151.3.1.x86_64 libQt5Sql5-mysql-5.9.7-lp151.3.1.x86_64 libQt5XmlPatterns5-5.9.7-lp151.1.3.x86_64 libQt5PrintSupport5-5.9.7-lp151.3.1.x86_64 libQt5WaylandClient5-5.9.7-lp151.1.4.x86_64 libQt5OpenGL5-5.9.7-lp151.3.1.x86_64 libQt5QuickTemplates2-5-5.9.7-lp151.1.3.x86_64 libQt5WebKit5-5.212~alpha2-lp151.5.37.x86_64 libqt5-qdbus-5.9.7-lp151.1.38.x86_64 libqt5-qtquickcontrols-5.9.7-lp151.1.3.x86_64 libqt5-qtbase-platformtheme-gtk3-5.9.7-lp151.3.1.x86_64 libQt5NetworkAuth5-5.9.7-lp151.1.3.x86_64 libQt5TextToSpeech5-5.9.7-lp151.3.2.x86_64 libQt5Network5-5.9.7-lp151.3.1.x86_64 libQt5X11Extras5-5.9.7-lp151.1.1.x86_64 libQt5Svg5-5.9.7-lp151.1.3.x86_64 libQt5WaylandCompositor5-5.9.7-lp151.1.4.x86_64 libqt5-qtwayland-5.9.7-lp151.1.4.x86_64 libQt5WebKit5-imports-5.212~alpha2-lp151.5.37.x86_64 libQt5DBus5-5.9.7-lp151.3.1.x86_64 libQt5Gui5-5.9.7-lp151.3.1.x86_64 libqt5-qtstyleplugins-platformtheme-gtk2-5.0.0+git20170311-lp151.4.2.x86_64 libqt5-qtvirtualkeyboard-5.9.7-lp151.1.1.x86_64 libqt5-qttranslations-5.9.7-lp151.1.1.x86_64 libQt5Core5-5.9.7-lp151.3.1.x86_64 libqt5-qtwebengine-5.9.7-lp151.1.42.x86_64 libqt5-qtpaths-5.9.7-lp151.1.38.x86_64
Running the find command the majority of the libraries under /usr/lib64 end in .5.9.7, which seems to match the list above. 5.9 < 5.12, so perhaps that's the issue.
At the end of the day, the non-Qt5 version is working better so far; I just installed, and poked at the tray icon quite a bit, and so far no issues. If it turns out this is some "your Qt5 is too old" issue, then perhaps that dependency can be added to the spec file for that particular build and then we're done. I'm not sure which package is best, but libqt5-qtbase-platformtheme-gtk3 MIGHT be a sensible start; I wish there was a simple libqt5-qtbase package only, but there are are various "provides" options in/around these packages on my current system:
libqt5-qtbase-platformtheme-gtk3(x86-64) = 5.9.7-lp151.3.1
Building some kind of dependency that states we need >= 5.12 might match up with your understanding. Perhaps I'll see if I can get a Tumbleweed VM going as its qt5 packages should be about as bleeding edge as possible.
One of the biggest reasons I love openSUSE: It's good for this kind of thing thanks to the Open Build Service (OBS):
https://software.opensuse.org/package/libqt5-qtbase
If that opens for you like it does for me, you should be able to click the "Show libqt5-qtbase for other distributions" button, and it will show you 5.9.7 is for Leap, and 5.13.1 is available on Tumbleweed, plus a bunch of other versions, and distros, and often that even includes Debian stuff. Anyway, I'll see if I can get Tumbleweed going in a VM and test out there, or maybe just see about getting 5.12+ on my other system for testing/verification.
I built an openSUSE Tumblweed install yesterday (test rig) and today in a virtual machine (VirtualBox) so I have now duplicated a new problem, but the old problem is gone, so perhaps that means we should close this issue and open another.
The new issue, or maybe the related issue, is something I stumbled upon while verifying the newer libqt5 (5.13) in Tumbleweed fixes the issue reported here, and while the crash does not happen my testing consisted of a bunch of system tray icon access in a quick sequence (which may or may not be relevant, but I think it probably is). I'm attaching a screenshot of the error.
In the screenshot the dialog box in the middle pops up, with some scary warning, right when I click on the tray icon, but nothing comes up from the tray icon. While I was getting ready to take the screenshot, though, the tray finally showed its menu (shown), though you do not see any notes created (I had created six (6) in about thirty (30) seconds, most with just one word in them, Testing0, Testing1, Testing2, etc., and with their default titles). Not showing any of them makes me think that the writes had not completed properly, or maybe the indexing had not happened, or maybe something else was wrong, but either way the message is scary. After the app crashed and I reloaded it I now see the notes as expected:
I have not noticed this with the GTK version, but I also have not tried this particular test, so maybe I'll try that shortly on another system.
Hmm, interesting. I don't see any reason why the Qt5 version of -ng would be more prone to this problem than the GTK one. So, think it could be a broader issue. Clearly you could trigger race conditions creating new notes faster that the system can keep up but, firstly, I doubt you would with empty notes. Longer notes with a lot of content take longer to save. But secondly, I don't see how that would lead to an Access Violation. Generally that means the app is trying to access memory that its not entitled to access. A bad thing ! Unix caching means the notes don't really need to be physically saved to disk, just passed to the unix file system, thats pretty quick unless you are struggling for memory. And new notes require very little memory. Sigh...
We keep a list in memory that represents the on disk status and do regard that as authoritative. But if that gets out of sync, you'd get a well handled file i/o exception, no assumptions are made about access being available.
------------- QUESTION ? When you hit that trayicon quickly what are you asking it to do ? Add a new note, reopen another, bring an open one to focus or open one of the other windows ?
Thanks for tracking down that QT5 version issue ! I think I will state that it should use 5.12 or later, while it can be forced to use earlier (by replacing the libqt5pas1 with a specially compiled one), I think any system using the older Qt5 is probably going to have GTK2 available any way. Its far better tested. Lets play safe !
Steps I was using were simply:
Click on tray icon Click New Note Type a few characters in the new note. Close the new note ('x' in the corner)
Rinse and repeat.
I tried again this morning on my test box (Qt5 version of tomcat-ng, but Tumbleweed so 5.13 version of Qt5) and it happened when I created the second note, so not very encouraging. I'm going to swap that one to GTK to see if that helps.
Testing with the GTK version did not have any errors; where before I would get that exception after just a few notes (or in that one case, on just the second note) with GTK I was able to create twenty (20) without any errors using the same steps as above only using Alt+F4 to close the notes (rather than clicking the 'x' in the corner) in order to go faster.
Anyway, I'm not sure what this means other than the Qt version seems to have some interesting underlying issue. I have a VirtualBox VM I can put somewhere if you want to use it directly. It is not the box where I duplicated GTK's success just now, but it's the same setup otherwise, just a minimal Tumbleweed with Qt 5.13.
I feel that I will really need to get to bottom of this (late model) Qt5 problem. That means being able to replicate it and so far, I cannot and then replicate it in some very simple app. Often drilling down like that will clarify the problem and its necessary to get the Qt5/Lazarus people interested.
If I can help, perhaps by providing the VM, let me know. My own testing makes me think that this should be easy to duplicate with whatever version of Qt comes with Leap or Tumbleweed, but if nothing else I can send a VM, or build a new one.
Eek... on my main box (Leap, NON-Qt version of Tomboy-ng) I just saw the same Access Violation error I saw in Tumbleweed with Qt. It happened, maybe coincidentally, as I was making the note I was using a bit thinner (resizing it). I do not recall if I had typed in it recently, thus it might have been saving changes, but there you go. I closed and reopened and had no problems since (of which I am aware), nor until this time since using the GTK version, but at least it confirms it is not a Qt-version-only issue.
Yes, I really did not expect that since my earlier GTK testing on my test box did so well creating test notes a couple dozen times. I also did not expect it because I was just resizing the window. I've seen it once since, again while resizing the window on my main (GTK) box. I guess I'll be careful when doing that.
Hmm, I don't want to put "be careful when resizing" in the release notes :-( So, must get to bottom of both thses issues. One thing I have been quite proud of is how stable -ng is, Tomboy did have some problems... dojoker, you had an open note and resized it ? By grabbing the edge with the mouse ? Anything you tell me about the note ? Big, small, unicode characters ? Lots of bullet points perhaps ? Davo
I am not making a lot of progress here. Firstly, dajoker, can you tell me more about your platform ? Its OpenSuse, I am testing against Leap 15.1. But what desktop are your using, given your initial choice of Qt5-ng, I am guessing Plasma/KDE ? Or are you using Gnome ? I have little OpenSuse experience, I assume you can download what people call 'spins' or 'flavours' of OpenSuse getting different desktops ?
I cannot replicate your problem on my OpenSuse Leap 15.1 using either Wayland or Xorg. I am absolutely astounded that I can run Qt5-ng on the Wayland version of OpenSuse, thats a real no-no on Fedora and I tend to lump Suse with Redhat.
The issue about libqt5pas1 also has me puzzled. I did not initially test OpenSuse with the Qt5-ng because it uses Wayland and I was sure it would not work. Wrong. But also wrong is that rpm, when told to install Qt5-ng, complains it needs libqt5pas, thats wrong, the deb the rpm was made from specifies libqt5pas1, note the '1' at the end. If I manually install using yast, libqt5pas1, all is good. Somehow, something, maybe alien is changing the name of the dependency. Ah, got it, Fedora and its spins call that library qt5pas, no '1', so perhaps Ubuntu's alien is making RedHat specific rpm files ...... This is getting messy ! I am still more worried about the crashes. And why I cannot replicate them.
Davo
I'm using openSUSE Leap 15.1 (x86_64) with KDE (main rig). The other system where I originally saw the error as noted in the screenshots was on an openSUSE Tumbleweed (installed a few days ago for this testing) system, also with KDE (test rig).
My main rig has 16 GiB RAM, a decent SSD (lat time I tested I could write around 340+ MiB/second), lots of free space, and I'm using XFS as the filesystem for /home (as opposed to Btrfs used for the rest of the system). My test rig is significantly less, but newly installed so lots of free space.
I have some huge notes, but my daily notes are not huge. For example, here is yesterday's note as reported by ls:
-rw-r--r-- 1 aaron users 25135 Jan 3 05:43 231AD7F2-D826-4B63-9AD6-E18B5D11FBA1.note
As a rule I try to avoid doing anything not-basic in my notes, i.e. I stick with ASCII characters mostly, though UTF8 is permitted, and I avoid bullets and such things always.
Usually when I resize I use a KDE-ism to do so, and I think that's probably what I did yesterday (or else I grabbed the edge), by using Alt+right-click which lets you move the closest edge of the window however you move the mouse. I believe it is basically the same as dragging the edge of the window, but without needing to perfectly aim for the edge of the window. Similarly, KDE lets you Alt+left-click to move a window, so instead of needing to grab the window header you can move anything from anywhere as long as you can touch it with the mouse at all.
I do not believe I am using Wayland anywhere currently; I get /usr/share/xsessions/plasma5 returned when I query the DESKTOP_SESSION environment variable, and XDG_SESSION_TYPE returns 'x11'.
I made a little screen-capture video thingy of the duplicated error using the GTK version of Tomboy-ng on my test rig; the goal here is to show you what I did, as well as how basic (not huge, complex, anything) the note is.
Same test, test rig, KDE, Tumbleweed, GTK version of -ng, etc., but this time I loaded it with strace (strace -ttt -ff -s 499 -e file tomboy-ng) and then started capturing when I started resizing things. I am not sure if this is useful, but here you go. All the 'Peek !!!!' lines show up doing any actual resizing, then we see a SIGSEGV and that is about the end of it. Perhaps limiting strace to just file operations is a mistake, but it's what I know best.
Yeah, strace is my friend ! Some very useful info there. On the assumption that things happening just before a crash (and the crash is an unhandled InOutError) are related to the crash ... Down at #1627, "TKMemo.Destroy with LCLRefCount>0. Hint: That means -ng was trying to close a note window. But clearly not on your instructions. So, up a bit we are playing with a temp file I create when rewriting a note to disk when its being resized. Thats about remembering the size if you reopen it later. And is only called as the NoteWindow closes. So, a decision that something was wrong was taken before then. So, further up, all I see is attempts to open various theme icons. I am wondering if -ng has detected something it does not like, has attempted to open a message window to tell you but cannot find the icons the OS directs it to use for that sort of dialog box.
Anyway, the problems seems to be strictly related to your particular config. I have been testing on a Gnome desktop, thats probably why I cannot duplicate your results.
Just so I can get as close as possible to what you are doing, did you install from the standard Leap 15.1 iso file that installs a Gnome (and Wayland) system and then add the necessary KDE packages ? Or did you install from a OpenSuse KDE 'spin' ? Or a 'net install' ?
(Wayland only works with Gnome and barely works there...)
I am going to open a new thread on the libqt5pas issue, these two issue are both important and quite different.
I built my box from the install ISO (USB) and specified online sources when prompted so it basically did auto-updates at install time (vs. doing more updates after the install is done), not that I think that part matters. If you did a network-based install (smaller ISO) that should be fine.
I also chose KDE during the installation (it's a prompt on one of the screens, Desktop with KDE vs. Desktop with Gnome vs. Server vs. other options).
If you want strace without the "file" filter I can send that along too, just a lot more stuff. I'm open to other troubleshooting options too.
Thanks for all your help with this.
In case it helps, here is a screenshot of what popped up in Lazarus as I was doing my resize-induced crash; test rig, so Tumbleweed, from the Git repo so the latest code, etc. P.S. Setting it up was super-easy so apparently your instructions are great. I'll post a script to do the openSUSE-side setup so you can use them if you'd like to duplicate with Lazarus there easily.
I can get whatever you want from Lazarus at this point, just wasn't sure what would be most helpful.
Sigh, thats just what I was hoping to not see. This problem would be heaps easier if it appears in my (pascal) code. Still, its possible we can trace the problem to being caused by my code, just showing up there. I am currently building a Leap15.1 Plasma, hope that finds a smoking gun.
You can step through that asm code line by line and may eventually end up in Pascal space but it is usually quite difficult. Buttons to the right of the red square 'stop' icon.
OK, at last I have been able to replicate both problems -
- The Qt5 issue where it crashes if no windows open.
- The KDE issue that crashes if you shake the border of a note window. Interesting that neither show up in OpenSuse 15.1 using Gnome. Davo
This is looking like some problem ! Generally, if I grab a corner (not edge ?) of a tomboy-ng window, and shake quite violently, after a few seconds, I will trigger something bad. More often than not, crash the display manager because I end up logged off. Not just a note window, I can do it with the settings or search window. And, wait for it, I can trigger the crash with a totally different application. Hmm....
For what it's worth, I concur that the side edge (right side, to be specific) does not cause the crash, but the bottom edge does, so maybe it is just an issue with resizing up and down, thus the corners work, as does the bottom.
What applications, in what way, also caused this? I have tried a couple (Kate, Pidgin), but no luck yet. I presume you mean that shaking other applications causes Tomboy-ng to crash, not that it causes the other applications themselves to crash.
No, I can crash the other application, completely independent of tomboy-ng. But its another application made in Lazarus, using the same GTK2 stack. Just a demo app from own collection. Same process has no effect on any other system I try it on. Very interesting ....