[krita] [Bug 428332] New: Layers contained in groups that have masks render incorrectly in 4.4.0
https://bugs.kde.org/show_bug.cgi?id=428332 Bug ID: 428332 Summary: Layers contained in groups that have masks render incorrectly in 4.4.0 Product: krita Version: 4.4.0 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Layer Stack Assignee: krita-bugs-n...@kde.org Reporter: r29...@gmail.com Target Milestone: --- Created attachment 132788 --> https://bugs.kde.org/attachment.cgi?id=132788&action=edit stripped down file SUMMARY Layers contained in groups that have masks render incorrectly in 4.4.0 STEPS TO REPRODUCE 1. observe that black frame and checkmarks are the only visible elements on the canvas. 2. turn off then on again the layers named "trait", "couleur_maison" and "couleur_foret". OBSERVED RESULT Layers should be visible immediately on opening the file, as they are set to visible. EXPECTED RESULT Layers have to be toggled off then on again to be visible. This only happens with layers that are contained in a group that has a mask. Toggling the mask however has no effect on the visibility of said layers. SOFTWARE/OS VERSIONS Only Krita 4.4.0 Windows 10 ADDITIONAL INFORMATION GTX1660Ti (mobile gpu), 16GiB, screen res is fullHD, stock Krita settings (fresh install) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 428332] Layers contained in groups that have masks render incorrectly in 4.4.0
https://bugs.kde.org/show_bug.cgi?id=428332 --- Comment #1 from Hadrien --- Oops I accidentally swapped "observed result" and "expected result", but I think this is clear. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 428332] Layers contained in groups that have masks render incorrectly in 4.4.0
https://bugs.kde.org/show_bug.cgi?id=428332 --- Comment #6 from Hadrien --- Thank you so much ! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392944] Crash when returning from sleep
https://bugs.kde.org/show_bug.cgi?id=392944 --- Comment #6 from Hadrien --- I've been trying to reproduce it, but no luck. Since I created this report it happened only once with the stable version 4.0.1, too bad I had forgotten to launch the portable nightly before putting the computer to sleep. Am still trying to reproduce the bug. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 369465] Value sliders are hard to work with
https://bugs.kde.org/show_bug.cgi?id=369465 --- Comment #3 from Hadrien --- I discovered that recently, and experimenting some more led me to discover holding shift slows down the value tweaking, which is the effect I was after. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392944] New: Crash when returning from sleep
https://bugs.kde.org/show_bug.cgi?id=392944 Bug ID: 392944 Summary: Crash when returning from sleep Product: krita Version: 4.0 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: r29...@gmail.com Target Milestone: --- Waking up Windows from sleep crashes Krita. As far as I remember it's always done this, since I've been using Krita (2.8 maybe ?). Not an instant crash, the "krita.exe has stopped working" kind. The particular version of Windows it's happening on is 7 but I think it's doing it on 10 as well (I don't have my W10 machine right now unfortunately) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392944] Crash when returning from sleep
https://bugs.kde.org/show_bug.cgi?id=392944 --- Comment #2 from Hadrien --- It happens every time. I can't find a download for this, where can I find it ? The page mentions a krita crash log in the appdata folder but there is no such thing on my machine, just a "cache" folder with a "qmlcache" folder inside it and a file named "01039b04dde482b045b38fae1a4d7fede3b4b981.qmlc" inside it. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392944] Crash when returning from sleep
https://bugs.kde.org/show_bug.cgi?id=392944 --- Comment #4 from Hadrien --- Ok thanks for walking me through it. Seems like it doesn't crash anymore when using the portable version... -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392894] Hotkey for canvas rotation needs to be pressed twice
https://bugs.kde.org/show_bug.cgi?id=392894 --- Comment #5 from Hadrien --- Assigning a shortcut to this key in Gimp works fine. I'll report it to Qt then. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392894] Hotkey for canvas rotation needs to be pressed twice
https://bugs.kde.org/show_bug.cgi?id=392894 --- Comment #6 from Hadrien --- The Qt bug reporting asks me for exact version and "component", not really sure what to enter there. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392616] Add symmetrize command
https://bugs.kde.org/show_bug.cgi?id=392616 --- Comment #4 from Hadrien --- A way to instance/link layers would also work for me : instance layer, apply scale -1 on x axis, paint. -- You are receiving this mail because: You are watching all bug changes.
[ksysguard] [Bug 304145] Ridiculously high peaks in CPU usage graph
https://bugs.kde.org/show_bug.cgi?id=304145 Hadrien G. changed: What|Removed |Added CC||knights_of...@gmx.com --- Comment #11 from Hadrien G. --- A very good reproducer for this bug is to run a IO-intensive and synchronous workload, such as "hdparm -t --direct /dev/" or "dd bs=2M count=2000 if=/dev/zero of=test conv=fdatasync && rm test". -- You are receiving this mail because: You are watching all bug changes.
[ksysguard] [Bug 329324] Bar maximum value limit
https://bugs.kde.org/show_bug.cgi?id=329324 Hadrien G. changed: What|Removed |Added CC||knights_of...@gmx.com --- Comment #1 from Hadrien G. --- In general, this bug makes bar graphs unusable for quantities which are not percentages, such as I/O rates or RAM usage. -- You are receiving this mail because: You are watching all bug changes.
[ksysguard] [Bug 245337] System monitor doesn't show the title for a digital display
https://bugs.kde.org/show_bug.cgi?id=245337 Hadrien G. changed: What|Removed |Added CC||knights_of...@gmx.com --- Comment #2 from Hadrien G. --- The title is ignored for bar graphs as well. -- You are receiving this mail because: You are watching all bug changes.
[ksysguard] [Bug 404589] New: ksysguard graphs lack a horizontal axis scale
https://bugs.kde.org/show_bug.cgi?id=404589 Bug ID: 404589 Summary: ksysguard graphs lack a horizontal axis scale Product: ksysguard Version: 5.15.0 Platform: Other OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: ksysguard Assignee: ksysguard-b...@kde.org Reporter: knights_of...@gmx.com Target Milestone: --- SUMMARY In ksysguard, graphs have a vertical axis scale, but not a horizontal one. As a result, one can easily get misled by tabs where not every graph has the same "pixel per time interval" setting. Note that resolving this may have farther-reaching implications. For example, graphs should be cleared when the horizontal scale changes (due to either a refresh rate change or a "pixel per time interval" change), and legends may need to move elsewhere in the UI (maybe above the graph, maybe inside). STEPS TO REPRODUCE 1. Open any tab which features monitoring graphs 2. Look at the bottom of each graph OBSERVED RESULT Notice that there is no way to correlate horizontal coordinates with timestamps. EXPECTED RESULT There should be an easy way to figure out when a data point was taken and be aware of different horizontal scales in graphs. SOFTWARE/OS VERSIONS OS: openSUSE Tumbleweed, Linux kernel 4.20.7-1-default KDE Plasma Version: N/A KDE Frameworks Version: 5.55.0 Qt Version: 5.12.0 -- You are receiving this mail because: You are watching all bug changes.
[ksysguard] [Bug 404589] ksysguard graphs lack a horizontal axis scale
https://bugs.kde.org/show_bug.cgi?id=404589 Hadrien G. changed: What|Removed |Added CC||knights_of...@gmx.com -- You are receiving this mail because: You are watching all bug changes.
[ksysguard] [Bug 404590] New: ksysguard plot legends do not work well in small windows
https://bugs.kde.org/show_bug.cgi?id=404590 Bug ID: 404590 Summary: ksysguard plot legends do not work well in small windows Product: ksysguard Version: 5.15.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: ksysguard Assignee: ksysguard-b...@kde.org Reporter: knights_of...@gmx.com Target Milestone: --- SUMMARY When using a smaller ksysguard window (or a window with many plots), sensor legends are collapsed by dropping sensor labels, which makes them hard to read unless one knows the color -> sensor association by heart. For a sufficiently complex plot or a sufficiently small screen, there may be no ksysguard window size that fits in the screen for which the sensor legend is readable. This happens much before the plot itself is too small to be readable. What makes this especially sad is that for many typical plots (e.g. stacked user/nice/system/iowait CPU load, read/write bandwidth of all drives / network interfaces), the legend is actually quite redundant and could be shortened by the user if given the ability to relabel sensors in a fashion that still makes sense in the context of a specific plot (e.g. in the context of a disk bandwidth plot "Read accesses device sda (8:0)" can be shortened to "sda reads"). I can think of several ways to resolve this: - The configuration cop-out: Let users give sensors a shorter label in plot legends (would be particularly useful with I/O sensors, whose name is very long and can usually be shortened in the context of specific plot). - The hard way: Review sensor names to make them shorter, without becoming ambiguous, or try to automatically shrink sensor names to adapt them to the context of a specific plot. - The UI design trick: Redesign the legend display so that it can scale better to multiple sensors, e.g. by putting it inside of the graph or judiciously ellipsing-away a fraction of a sensor's label as the plot size shrinks. STEPS TO REPRODUCE 1. Create a new ksysguard tab with room for a few plots (say, a 2x4 grid, which is otherwise pretty comfortable on a 24-inch screen). 2. Add several I/O sensors to a given plot (say, read/write bandwidth for two drives, which is a common configuration with SSDs + HDDs these days) OBSERVED RESULT The plot's legend is only displayed correctly if the window is maximized. Below a certain critical size, labels are immediately hidden without prior adaptation (e.g. putting an ellipsis in a middle). For sufficiently many traces, the legend may never be displayed correctly at any reasonable window size. It does not seem possible for the user to reconfigure sensor labels so that they fix on the screen. EXPECTED RESULT Plot legends should scale better with decreasing plot/window size. SOFTWARE/OS VERSIONS OS: openSUSE Tumbleweed, Linux kernel 4.20.7-1-default KDE Plasma Version: N/A KDE Frameworks Version: 5.55.0 Qt Version: 5.12.0 -- You are receiving this mail because: You are watching all bug changes.
[ksysguard] [Bug 404591] Missing sensor name for disk partition "percentage used" plot
https://bugs.kde.org/show_bug.cgi?id=404591 Hadrien G. changed: What|Removed |Added CC||knights_of...@gmx.com -- You are receiving this mail because: You are watching all bug changes.
[ksysguard] [Bug 404591] New: Missing sensor name for disk partition "percentage used" plot
https://bugs.kde.org/show_bug.cgi?id=404591 Bug ID: 404591 Summary: Missing sensor name for disk partition "percentage used" plot Product: ksysguard Version: 5.15.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: ksysguard Assignee: ksysguard-b...@kde.org Reporter: knights_of...@gmx.com Target Milestone: --- SUMMARY Partition usage sensors do not have a name in graph legends. This makes it hard to identify which partition is associated with which trace. STEPS TO REPRODUCE 1. Create a tab 2. Make a plot with "percentage used" traces for a few partitions OBSERVED RESULT Legend says "Percentage Used" for all partitions, without clarifying which partition is being monitored. EXPECTED RESULT The legend should somehow clarify which partition corresponds to which trace. For example "Percentage Used /" vs "Percentage Used /home". SOFTWARE/OS VERSIONS OS: openSUSE Tumbleweed, Linux kernel 4.20.7-1-default KDE Plasma Version: N/A KDE Frameworks Version: 5.55.0 Qt Version: 5.12.0 -- You are receiving this mail because: You are watching all bug changes.
[ksysguard] [Bug 404590] ksysguard plot legends do not work well in small windows
https://bugs.kde.org/show_bug.cgi?id=404590 Hadrien G. changed: What|Removed |Added CC||knights_of...@gmx.com -- You are receiving this mail because: You are watching all bug changes.
[ksysguard] [Bug 404637] New: It should be possible to close or customize the built-in "system load" tab
https://bugs.kde.org/show_bug.cgi?id=404637 Bug ID: 404637 Summary: It should be possible to close or customize the built-in "system load" tab Product: ksysguard Version: 5.15.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: ksysguard Assignee: ksysguard-b...@kde.org Reporter: knights_of...@gmx.com Target Milestone: --- SUMMARY One very good thing about ksysguard, which made me switch from gnome-system-monitor in spite of using a GTK desktop and finding it more polished overall (see my other bug reports :)), is that you can tailor it to your needs. For example, I personally consider disk load monitoring a must-have, a point which all GUI system monitor authors seem to disagree with. With ksysguard, I can just roll my own tab and be done with that. To perfect this experience, however, it should be possible to either customize the built-in "system load" tab or to close it after rolling out a replacement. Currently, neither of these seem possible. STEPS TO REPRODUCE 1. Open ksysguard 2. Go to "system load" tab 3. Notice that there is no "Close Tab" in the file menu and no tab editor on the right. OBSERVED RESULT It does not seem possible to customize or replace the built-in system load tab. EXPECTED RESULT It should be possible to do so. SOFTWARE/OS VERSIONS OS: openSUSE Tumbleweed, Linux kernel 4.20.7-1-default KDE Plasma Version: N/A KDE Frameworks Version: 5.55.0 Qt Version: 5.12.0 -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 502959] New: Akonadi should try harder to connect to *DAV servers
https://bugs.kde.org/show_bug.cgi?id=502959 Bug ID: 502959 Summary: Akonadi should try harder to connect to *DAV servers Classification: Frameworks and Libraries Product: Akonadi Version: 6.3.3 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: DAV Resource Assignee: kdepim-b...@kde.org Reporter: knights_of...@gmx.com CC: c...@carlschwan.eu Target Milestone: --- SUMMARY I have noticed on my wired boxes with a simple systemd-networkd setup that if the Akonadi service does not manage to connect to some *DAV servers on startup, it will flag the associated resources as offline and never try to connect to them again. Thus e.g. CalDAV calendar sync will be lost for the entire user session unless manually restarted using something like the "akonadictl restart" CLI command or the KOrganizer account configuration dialog's "Restart" buttons. While I can work around this problem for my own purposes, I believe that in a world where intermittent Internet connectivity is very common (think laptops), only trying to connect to a service once before giving up like this is wrong. IMO Akonadi should do at least one of the following things instead : - When a network interface becomes up or switches to a different configuration, retry previous failed *DAV sync * This notification-based approach minimizes the delay between Internet availability and CalDAV sync service restoration, but it relies on the availability of reliable network status change notifications, which may not be available due to OS limitations and other reasons described below. - When a *DAV sync fails, try it again after some time, possibly putting the user in control of the associated polling rate * This polling-based approach sounds easier to implement and works better with flaky CalDAV servers, as well as some common flavors of flaky Internet connexions like mobile phones acting as a wifi hotspot where the hotspot is stable but the cellular connexion is not. However, in better network conditions, such polling will result in a significant delay between Internet availability and sync availability. Attempting to reduce this delay by reducing the polling interval will increase background resource consumption and make laptop batteries sad. STEPS TO REPRODUCE 1. Set up a CalDAV connection in KOrganizer or Merkuro 2. Restart system in a network configuration where the CalDAV server is unreachable 3. Start any app that relies on Akonadi (this may be automatic if e.g. the clock plasmoid is set up to show CalDAV events) 4. Connect system to the internet OBSERVED RESULT After the initial sync failure, CalDAV sync will never be resumed. Akonadi will keep the CalDAV resource in a failed state for the entire user session unless the sync is manually restarted. EXPECTED RESULT Akonadi should eventually retry to connect to the CalDAV server. It might also be a good idea to make failures a bit noisier as the "(Disconnected)" label is not shown in some apps like the plasmoid applet and it is relatively easy to visually miss even in the apps that do have it because it is not in a UI location that one normally needs to look at. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.3.4 KDE Frameworks Version: 6.12.0 Qt Version: 6.9.0 Kernel Version: 6.14.2-arch1-1 (64-bit) ADDITIONAL INFORMATION I observed this problem on several other Arch-based machines so it does not seem hardware-specific. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 501285] New: kscreenlocker (sometimes) crashes when screen turns off/on
https://bugs.kde.org/show_bug.cgi?id=501285 Bug ID: 501285 Summary: kscreenlocker (sometimes) crashes when screen turns off/on Classification: Plasma Product: plasmashell Version: git-stable-Plasma/6.3 Platform: Arch Linux OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: Screen locking Assignee: plasma-b...@kde.org Reporter: knights_of...@gmx.com Target Milestone: 1.0 SUMMARY So, I know that this is not quite a full bug report with a nice backtrace yet, but I need some help to get there because I'm running out of ideas. Here is what I got so far: - This bug is hardware-specific. I get it on one machine (desktop using an AMD Ryzen 5 5600G's integrated graphics, connected to a Philips 272B7QPTK screen) but not on another (MSI Alpha A4DEK laptop using an AMD Ryzen 7 4800H + RX 5600M hybrid setup + unknown screen model), with otherwise similar hardware configuration. - This bug is related to GPU or screen power management. In the default powerdevil configuration, where the screen automatically turns off, when I wake up the computer I face the message telling me that I need to log in to a VT and run "loginctl unlock-session 2" to unlock the screen. And in journalctl, it says that kscreenlocker_greet segfaulted. If I disable screen poweroff, then the bug never happens, however long I keep the login screen on. I sometimes manage to reproduce the bug by running "sleep 10 && kscreen-doctor --dpms off" on one terminal and "/usr/lib/kscreenlocker_greet --testing" on another terminal, but not always, and it's not clear to me what are the precise circumstances that cause it to trigger. This makes it harder for me to analyze the bug further. - This bug is not related to libddc. Although there were tons of promising libddc warnings/errors in the journalctl logs, turning off libddc as directed by the powerdevil readme silences the warnings but does not stop the crashes. Along the way, I also tried to increase the powerdevil log verbosity as directed in the powerdevil readme, but that did not turn up anything useful. - This bug comes from some sort of memory corruption. One time I managed to get /usr/lib/kscreenlocker_greet to reproduce the bug under GDB, which gave me a stack trace where the code was attempting to dereference a QWeakPointer with a target address of 0x6d1 or something blatantly invalid like that. I hoped to find out who overwrote the address of that pointer with rr, but the bug does not reproduce under either rr or valgrind. That being said, valgrind does report many out-of-bounds issues in KSVG, but judging by the very different memory addresses and the fact that these errors are reported even if the screen does not turn off, this seems to be an unrelated issue. STEPS TO REPRODUCE 1. Get the same hardware as I do? 2. Set "Shutdown screen after..." to anything other than "Never" in powerdevil. 3. Wait for screen to lock and turn off, maybe some extra time (it seems the crash is not always right at the point where the screen turns off). OBSERVED RESULT Wiggle mouse, face a kscreenlocker crash report, need to switch to VT to get back to my desktop. EXPECTED RESULT Screen locker shows up normally and lets me unlock my session without dirty VT tricks. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.3.2 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.13.5-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 5600G with Radeon Graphics Memory: 62.2 Gio of RAM Graphics Processor: AMD Radeon Graphics ADDITIONAL INFORMATION I reliably get a plasma shell crash report dialog on the same system when resuming from sleep. I do not know if this is related or not. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 501285] kscreenlocker (sometimes) crashes when screen turns off/on
https://bugs.kde.org/show_bug.cgi?id=501285 Hadrien G. changed: What|Removed |Added CC||knights_of...@gmx.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 501285] kscreenlocker (sometimes) crashes when screen turns off/on
https://bugs.kde.org/show_bug.cgi?id=501285 --- Comment #1 from Hadrien G. --- ...ah, sorry, when I wrote "otherwise similar hardware configuration above", I meant "otherwise similar **software** configuration". I switched both to Arch recently and configured them in a very similar fashion, basically taking my notes from setting up one machine to set up the other. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 501285] kscreenlocker (sometimes) crashes when screen turns off/on
https://bugs.kde.org/show_bug.cgi?id=501285 --- Comment #4 from Hadrien G. --- Most of the coredumps are from plasmashell from resuming from sleep or power-cycling the monitor, which I suspect to be a different issue. I should probably create a different bug report for those crashes. But if you prefer, I can add some of them here. However, there are actually a few that I missed from kscreenlocker_greet. Here is the most recent one: Core was generated by `/usr/lib/kscreenlocker_greet --testing'. Program terminated with signal SIGSEGV, Segmentation fault. #0 std::__atomic_base::load (this=0xf5, __m=std::memory_order::relaxed) at /usr/include/c++/14.2.1/bits/atomic_base.h:499 499 __glibcxx_assert(__b != memory_order_acq_rel); [Current thread is 1 (Thread 0x777d1ef7fa80 (LWP 70768))] (gdb) bt #0 std::__atomic_base::load (this=0xf5, __m=std::memory_order::relaxed) at /usr/include/c++/14.2.1/bits/atomic_base.h:499 #1 QAtomicOps::loadRelaxed (_q_value=) at /usr/include/qt6/QtCore/qatomic_cxx11.h:202 #2 QBasicAtomicInteger::loadRelaxed (this=0xf5) at /usr/include/qt6/QtCore/qbasicatomic.h:36 #3 QWeakPointer::internalData (this=0x633b9795f328) at /usr/include/qt6/QtCore/qsharedpointer_impl.h:752 #4 QPointer::data (this=, this=) at /usr/include/qt6/QtCore/qpointer.h:75 #5 QPointer::operator QObject* (this=, this=) at /usr/include/qt6/QtCore/qpointer.h:83 #6 PlasmaQuick::SharedQmlEngine::rootObject (this=0x633b97d58d60) at /usr/src/debug/libplasma/libplasma-6.3.2/src/plasmaquick/sharedqmlengine.cpp:226 #7 0x777d27fa3f06 in PlasmaQuick::QuickViewSharedEngine::rootObject (this=) at /usr/src/debug/libplasma/libplasma-6.3.2/src/plasmaquick/quickviewsharedengine.cpp:187 #8 0x633b5790dec3 in ScreenLocker::UnlockApp::markViewsAsVisible (this=0x7ffce6854e60, view=) at /usr/src/debug/kscreenlocker/kscreenlocker-6.3.2/greeter/greeterapp.cpp:450 #9 0x777d259a2f4a in QObject::event (this=0x7ffce6854e60, e=0x777cc4552570) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobject.cpp:1418 #10 0x777d25955b00 in QCoreApplication::notifyInternal2 (receiver=0x7ffce6854e60, event=event@entry=0x777cc4552570) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qcoreapplication.cpp:1172 #11 0x777d25955edc in QCoreApplication::sendEvent (receiver=, event=0x777cc4552570) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qcoreapplication.cpp:1612 #12 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x633b9723fca0) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qcoreapplication.cpp:1946 #13 0x777d25bc859c in QCoreApplication::sendPostedEvents (receiver=0x0, event_type=0) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qcoreapplication.cpp:1800 #14 postEventSourceDispatch (s=s@entry=0x633b97244700) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:246 #15 0x777d23d06104 in g_main_dispatch (context=0x777d18000f00) at ../glib/glib/gmain.c:3398 #16 0x777d23d69d57 in g_main_context_dispatch_unlocked (context=0x777d18000f00) at ../glib/glib/gmain.c:4249 #17 g_main_context_iterate_unlocked.isra.0 (context=context@entry=0x777d18000f00, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../glib/glib/gmain.c:4314 #18 0x777d23d05535 in g_main_context_iteration (context=0x777d18000f00, may_block=1) at ../glib/glib/gmain.c:4379 #19 0x777d25bc575d in QEventDispatcherGlib::processEvents (this=0x633b97245b40, flags=...) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:399 #20 0x777d259606a6 in QEventLoop::processEvents (this=0x7ffce6854b80, flags=...) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventloop.cpp:103 #21 QEventLoop::exec (this=0x7ffce6854b80, flags=...) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventloop.cpp:185 #22 0x777d259591d6 in QCoreApplication::exec () at /usr/src/debug/qt6-base/qtbase/src/corelib/global/qflags.h:74 #23 0x633b5790c6b5 in main (argc=, argv=) at /usr/src/debug/kscreenlocker/kscreenlocker-6.3.2/greeter/main.cpp:207 As you can see, it looks like some QObject got its internal state corrupted, to the point of believing that 0xf5 is a valid userspace pointer. What I did not manage to figure out so far is, who overwrote that memory and why. It would have been great if the crash reproduced under rr or valgrind... -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 501285] kscreenlocker (sometimes) crashes when screen turns off/on
https://bugs.kde.org/show_bug.cgi?id=501285 --- Comment #5 from Hadrien G. --- Oh and by the way, the experiment outcome is that turning the screen off and back on using the hardware power button does not crash the lock screen, even if I leave the screen off for hours. It only (very reliably) crashes plasmashell, which then proceeds to cleanly recover. So it looks like DPMS has to get involved in order to reproduce the kscreenlocker crash. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 501285] kscreenlocker (sometimes) crashes when screen turns off/on
https://bugs.kde.org/show_bug.cgi?id=501285 --- Comment #2 from Hadrien G. --- Another piece of data that may or may not be related: I just thought about turning the screen off via the hardware power button (instead of DPMS), leaving it off for a while, then turning it back on, while the lock screen is active. This did not crash the lock screen. But after logging back in, I got a plasmashell crash window similar to the ones I reliably get when resuming the machine from sleep... I only left the screen off for a short while (~15s?) though, so I'm going to try doing this over a longer period of time, to see if it does eventually crash the lockscreen or not. -- You are receiving this mail because: You are watching all bug changes.
[kaffeine] [Bug 334197] Dvb-t HD channels corrupt audio, slow video, but records fine.
https://bugs.kde.org/show_bug.cgi?id=334197 --- Comment #17 from Hadrien --- It's nice to see that the project is living. So I tried the latest git code (commit 199edfa1c3bbcf20ce4b321e6f7dcfe288982303). Here are my remarks: I'm on Ubuntu 16.04 so I looked in the README in the section about Debian. Those packages were not found with apt: libqt5-sql-sqlite libkf5kdbusaddons-dev, but I've been able to build the source anyway. The program starts without problem but all my settings (including channels) were lost. The TV does not work at all, I've got this error (in a terminal) when I start the program: core libvlc error: No plugins found! Check your VLC installation. 01-06-16 22:45:48.202 [System ] VlcMediaWidget::init: cannot create vlc instance "" -- You are receiving this mail because: You are watching all bug changes.
[kaffeine] [Bug 334197] Dvb-t HD channels corrupt audio, slow video, but records fine.
https://bugs.kde.org/show_bug.cgi?id=334197 --- Comment #18 from Hadrien --- (In reply to Hadrien from comment #17) > The TV does not work at all, I've got this error (in a terminal) when I > start the program: > core libvlc error: No plugins found! Check your VLC installation. > 01-06-16 22:45:48.202 [System ] VlcMediaWidget::init: cannot create vlc > instance "" I tried to reinstall vlc and it fixed the problem: sudo apt install vlc -- You are receiving this mail because: You are watching all bug changes.
[kaffeine] [Bug 334197] Dvb-t HD channels corrupt audio, slow video, but records fine.
https://bugs.kde.org/show_bug.cgi?id=334197 --- Comment #20 from Hadrien --- (In reply to Mauro Carvalho Chehab from comment #19) > Thanks for checking it! I double checked here, and indeed libqt5-sql-sqlite > and libkf5kdbusaddons-dev don't exist on Debian sid and on Ubuntu 16.04. So, > I removed them from the README file and added "vlc". Nice! Thanks for your work, Mauro. -- You are receiving this mail because: You are watching all bug changes.
