[plasmashell] [Bug 480477] With NVIDIA GPU on X11 , plasmashell crashed when opening Kickoff after unlocking the screen
https://bugs.kde.org/show_bug.cgi?id=480477 --- Comment #2 from Sven Eden --- (In reply to Nate Graham from comment #1) > Crash is deep in graphics stuff, which I guess is not surprising given that > you have an NVIDIA GPU unfortunately. > > Does the issue reproduce if you disconnect all monitors except for one? Sorry, I haven't tried that. After trying out Wayland again with some "workarounds" (Like setting KWIN_FORCE_SW_CURSOR=1) applied, which still resulted in no mouse cursor on the external screen and a full freeze (with Magic SysRq not working) on logout, I reverted back to KDE 5 (KF 5.114). Anyway, the first symptom was that on screen lock the dia show did not start (or any other option I tried), but all three displays got shut off completely, even with all power options to dim or turn off displays disabled. The interesting part is that the internal display, which is not powered by the RTX, got also shut off. So this does not seem to be an Nvidia-thing alone. When trying to reactivate, the internal display flicked on, and half a second later off again. Then, 1-2 seconds later, it came back to life, then the second monitor flicked on, and half a second later both went away again. Then, 1-2 seconds later it was panel plus third monitor, then panel plus first and second, then panel alone, and so on. That was really weird... -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 480477] New: plasmashell crash when accessing menu after screen lock
https://bugs.kde.org/show_bug.cgi?id=480477
Bug ID: 480477
Summary: plasmashell crash when accessing menu after screen
lock
Classification: Plasma
Product: plasmashell
Version: 5.92.0
Platform: Compiled Sources
OS: Linux
Status: REPORTED
Keywords: drkonqi
Severity: crash
Priority: NOR
Component: generic-crash
Assignee: plasma-b...@kde.org
Reporter: s...@eden-worx.com
Target Milestone: 1.0
Application: plasmashell (5.92.0)
(Compiled from sources)
Qt Version: 6.6.1
Frameworks Version: 5.248.0
Operating System: Linux 6.6.13-gentoo x86_64
Windowing System: X11
Distribution: "Gentoo Linux"
DrKonqi: 5.92.0 [KCrashBackend]
-- Information about the crash:
GPUs: Intel i7 10thGen + Nvidia Quadro RTX 5000, nvidia-drivers-545.29.06
(KDE 6.0 RC1 started in X11 mode, because I have no mouse cursors on the
external displays with Wayland)
When I lock the Session, I do not get the dia show that I previously had set
up, but all three displays are completely shut off. When I then try to log back
in, Plasma has extreme difficulties enabling the displays again and needs
dozens of attempts until I can log back in.
After that the whole desktop is extremely laggy, but Conky does not show any
extreme activity.
The crash happened when I tried to access the start menu. It took several
seconds before anything showed up, then several seconds until plasmashell
crashed, then about a minute until the crash handler appeared and plasmashell
restarted.
Now every context menu or subwindow opening takes 5-10 seconds.
The crash can be reproduced sometimes.
-- Backtrace:
Application: plasmashell (plasmashell), signal: Segmentation fault
Content of s_kcrashErrorMessage: std::unique_ptr = {get() = 0x0}
[KCrash Handler]
#6 0x7feca265d1ca in QOpenGLContext::isValid
(this=this@entry=0x7fec64002000) at
/data/portage/portage/dev-qt/qtbase-6.6.1-r4/work/qtbase-everywhere-src-6.6.1/src/gui/kernel/qopenglcontext.cpp:501
#7 0x7feca265e0b2 in QOpenGLContext::doneCurrent (this=0x7fec64002000) at
/data/portage/portage/dev-qt/qtbase-6.6.1-r4/work/qtbase-everywhere-src-6.6.1/src/gui/kernel/qopenglcontext.cpp:727
#8 0x7feca2660ce6 in QGuiGLThreadContext::~QGuiGLThreadContext
(this=0x7fec643c7260, __in_chrg=) at
/data/portage/portage/dev-qt/qtbase-6.6.1-r4/work/qtbase-everywhere-src-6.6.1/src/gui/kernel/qopenglcontext.cpp:35
#9 qThreadStorage_deleteData (d=0x7fec643c7260) at
/data/portage/portage/dev-qt/qtbase-6.6.1-r4/work/qtbase-everywhere-src-6.6.1_build/include/QtCore/../../../qtbase-everywhere-src-6.6.1/src/corelib/thread/qthreadstorage.h:56
#10 QThreadStorage::deleteData (x=0x7fec643c7260) at
/data/portage/portage/dev-qt/qtbase-6.6.1-r4/work/qtbase-everywhere-src-6.6.1_build/include/QtCore/../../../qtbase-everywhere-src-6.6.1/src/corelib/thread/qthreadstorage.h:99
#11 0x7feca1cd4cac in QThreadStorageData::finish (p=p@entry=0x7fec90018518)
at
/data/portage/portage/dev-qt/qtbase-6.6.1-r4/work/qtbase-everywhere-src-6.6.1/src/corelib/thread/qthreadstorage.cpp:164
#12 0x7feca1ccda88 in operator() (__closure=) at
/data/portage/portage/dev-qt/qtbase-6.6.1-r4/work/qtbase-everywhere-src-6.6.1/src/corelib/thread/qthread_unix.cpp:349
#13 0x7feca1ccdc16 in (anonymous
namespace)::terminate_on_exception
>(struct {...} &&) (t=) at
/data/portage/portage/dev-qt/qtbase-6.6.1-r4/work/qtbase-everywhere-src-6.6.1/src/corelib/thread/qthread_unix.cpp:260
#14 0x7feca1ccde45 in QThreadPrivate::finish (arg=0x5591f01ff320) at
/data/portage/portage/dev-qt/qtbase-6.6.1-r4/work/qtbase-everywhere-src-6.6.1/src/corelib/thread/qthread_unix.cpp:337
#15 __pthread_cleanup_class::~__pthread_cleanup_class (this=, __in_chrg=) at
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include-fixed/pthread.h:587
#16 __pthread_cleanup_class::~__pthread_cleanup_class (this=, __in_chrg=) at
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include-fixed/pthread.h:587
#17 QThreadPrivate::start (arg=0x5591f01ff320) at
/data/portage/portage/dev-qt/qtbase-6.6.1-r4/work/qtbase-everywhere-src-6.6.1/src/corelib/thread/qthread_unix.cpp:330
#18 0x7feca14bbc19 in start_thread (arg=) at
pthread_create.c:444
#19 0x7feca152dc08 in clone3 () at
../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
Thread 12 (Thread 0x7fec36c0 (LWP 1391) "QSGRenderThread"):
#1 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x5591f25e1910,
expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0,
private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
#2 0x7feca14b881b in __GI___futex_abstimed_wait_cancelable64
(futex_word=futex_word@entry=0x5591f25e1910, expected=expected@entry=0,
clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at
futex-internal.c:139
#3 0x7feca14baf79 in __pthread_cond_wait_common (abstime=0x0, clockid=0,
mutex=0x5591f25e18c0,
[plasmashell] [Bug 466095] Plasma crashes in DesktopView::screenToFollow() on screen wake up when KScreen service is active and high refresh rate monitor is connected and AdaptivSync is enabled
https://bugs.kde.org/show_bug.cgi?id=466095 --- Comment #17 from Sven Eden --- Created attachment 159511 --> https://bugs.kde.org/attachment.cgi?id=159511=edit New crash information added by DrKonqi plasmashell (5.27.5) using Qt 5.15.9 DesktopView::screenToFollow() got called on a NULL pointer in my case. (See trace) Monitor in question reported not having a signal when I turned it on this morning, which was very unusual. Then it came back after 2-3 seconds and I logged into my machine being greeted by the crash reporter. The Montor is an ASUS Predator with AdaptiveSync (G-Sync compatible) running at 2k resolution @144Hz. Just one more thing: Could DrKonqi please tell its audience (me) exactly *WHEN* the crash happened? The laptop was doing work overnight, so it could've been useful to know when this happened. Not in this case, obviously, but in outhers it might. Thanks! -- Backtrace (Reduced): #6 QWeakPointer::internalData() const (this=0x58) at /usr/include/qt5/QtCore/qsharedpointer_impl.h:696 #7 QPointer::data() const (this=0x58) at /usr/include/qt5/QtCore/qpointer.h:77 #8 QPointer::operator QScreen*() const (this=0x58) at /usr/include/qt5/QtCore/qpointer.h:83 #9 DesktopView::screenToFollow() const (this=0x0) at /data/portage/portage/kde-plasma/plasma-workspace-5.27.5/work/plasma-workspace-5.27.5/shell/desktopview.cpp:124 #10 0x55a2a9a685c0 in ShellCorona::screenInvariants() const (this=0x55a2aa4f3670) at /data/portage/portage/kde-plasma/plasma-workspace-5.27.5/work/plasma-workspace-5.27.5/shell/shellcorona.cpp:828 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 466095] Plasma crashes in DesktopView::screenToFollow() on screen wake up when KScreen service is active
https://bugs.kde.org/show_bug.cgi?id=466095 --- Comment #9 from Sven Eden --- Created attachment 157104 --> https://bugs.kde.org/attachment.cgi?id=157104=edit New crash information added by DrKonqi plasmashell (5.27.2) using Qt 5.15.8 Yesterday evening I closed all programs, started BOINC manager and let my attached projects run. I locked the session and turned my monitors off. Nothing else was active. Turned everything back on this morning, everything looked normal, but I had the little crash icon in my info area telling me that Plasma had crashed. I do not know when, sorry. Might have been before I tunred everything off yesterday, during the night, or when turning everything back on. -- Backtrace (Reduced): #6 QWeakPointer::internalData() const (this=0x58) at /usr/include/qt5/QtCore/qsharedpointer_impl.h:696 #7 QPointer::data() const (this=0x58) at /usr/include/qt5/QtCore/qpointer.h:77 #8 QPointer::operator QScreen*() const (this=0x58) at /usr/include/qt5/QtCore/qpointer.h:83 #9 DesktopView::screenToFollow() const (this=0x0) at /data/portage/portage/kde-plasma/plasma-workspace-5.27.2/work/plasma-workspace-5.27.2/shell/desktopview.cpp:124 #10 0x559825f2cc80 in ShellCorona::screenInvariants() const (this=0x55982798bc80) at /data/portage/portage/kde-plasma/plasma-workspace-5.27.2/work/plasma-workspace-5.27.2/shell/shellcorona.cpp:828 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 466095] Plasma crashes in DesktopView::screenToFollow() on screen wake up when KScreen service is active
https://bugs.kde.org/show_bug.cgi?id=466095 Sven Eden changed: What|Removed |Added CC||s...@eden-worx.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 465892] New: Nullpointerexception in plasma-workspace-5.27.0/shell/desktopview.cpp:120
https://bugs.kde.org/show_bug.cgi?id=465892
Bug ID: 465892
Summary: Nullpointerexception in
plasma-workspace-5.27.0/shell/desktopview.cpp:120
Classification: Plasma
Product: plasmashell
Version: 5.27.0
Platform: Compiled Sources
OS: Linux
Status: REPORTED
Keywords: drkonqi
Severity: crash
Priority: NOR
Component: general
Assignee: plasma-b...@kde.org
Reporter: s...@eden-worx.com
CC: k...@davidedmundson.co.uk
Target Milestone: 1.0
Application: plasmashell (5.27.0)
(Compiled from sources)
Qt Version: 5.15.8
Frameworks Version: 5.103.0
Operating System: Linux 6.1.12-gentoo x86_64
Windowing System: X11
Distribution: "Gentoo Linux"
DrKonqi: 5.27.0 [KCrashBackend]
-- Information about the crash:
Gridcoin (minimized to tray) and BOINC where running, like almost every
evening, when I locked the session, turned off my monitors, disabled my laptops
panel (DnD-Mode) and went to bed.
This morning I was greeted with the crash handler.
This never happened before upgrading to Plasma 5.27.0.
Main screen is a 2K screen at 144Hz. Secondary are my laptop panel and an extra
HDMI connected monitor, both in FHD.
xrandr information:
Screen 0: minimum 8 x 8, current 6400 x 1440, maximum 32767 x 32767
eDP-1-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis)
344mm x 194mm
DP-4connected primary 2560x1440+1920+0 (normal left inverted right x axis y
axis) 600mm x 340mm
HDMI-0 connected 1920x1080+4480+0 (normal left inverted right x axis y axis)
510mm x 290mm
The reporter is unsure if this crash is reproducible.
-- Backtrace:
Application: Plasma (plasmashell), signal: Segmentation fault
Content of s_kcrashErrorMessage: std::unique_ptr = {get() = 0x0}
[KCrash Handler]
#6 QWeakPointer::internalData() const (this=0x58) at
/usr/include/qt5/QtCore/qsharedpointer_impl.h:696
#7 QPointer::data() const (this=0x58) at
/usr/include/qt5/QtCore/qpointer.h:77
#8 QPointer::operator QScreen*() const (this=0x58) at
/usr/include/qt5/QtCore/qpointer.h:83
#9 DesktopView::screenToFollow() const (this=0x0) at
/data/portage/portage/kde-plasma/plasma-workspace-5.27.0/work/plasma-workspace-5.27.0/shell/desktopview.cpp:120
#10 0x5590525b3a40 in ShellCorona::screenInvariants() const
(this=0x559053c418e0) at
/data/portage/portage/kde-plasma/plasma-workspace-5.27.0/work/plasma-workspace-5.27.0/shell/shellcorona.cpp:828
#11 0x7ff960cab90c in QtPrivate::QSlotObjectBase::call(QObject*, void**)
(a=0x7ffc18d19300, r=0x559053c418e0, this=0x55905443a000) at
/data/portage/portage/dev-qt/qtcore-5.15.8-r3/work/qtbase-everywhere-src-5.15.8/include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398
#12 doActivate(QObject*, int, void**) (sender=0x559053c41a08,
signal_index=3, argv=0x7ffc18d19300) at
/data/portage/portage/dev-qt/qtcore-5.15.8-r3/work/qtbase-everywhere-src-5.15.8/src/corelib/kernel/qobject.cpp:3923
#13 0x7ff960ca581f in QMetaObject::activate(QObject*, QMetaObject const*,
int, void**) (sender=, m=m@entry=0x7ff960f49300
, local_signal_index=local_signal_index@entry=0,
argv=argv@entry=0x7ffc18d19300) at
/data/portage/portage/dev-qt/qtcore-5.15.8-r3/work/qtbase-everywhere-src-5.15.8/src/corelib/kernel/qobject.cpp:3983
#14 0x7ff960cafa0a in QTimer::timeout(QTimer::QPrivateSignal)
(this=, _t1=...) at .moc/moc_qtimer.cpp:205
#15 0x7ff960ca37ed in QObject::event(QEvent*) (this=0x559053c41a08,
e=0x7ffc18d19460) at
/data/portage/portage/dev-qt/qtcore-5.15.8-r3/work/qtbase-everywhere-src-5.15.8/src/corelib/kernel/qobject.cpp:1369
#16 0x7ff961962fbe in QApplicationPrivate::notify_helper(QObject*, QEvent*)
(this=, receiver=0x559053c41a08, e=0x7ffc18d19460) at
/data/portage/portage/dev-qt/qtwidgets-5.15.8-r2/work/qtbase-everywhere-src-5.15.8/src/widgets/kernel/qapplication.cpp:3640
#17 0x7ff960c78f28 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
(receiver=0x559053c41a08, event=0x7ffc18d19460) at
/data/portage/portage/dev-qt/qtcore-5.15.8-r3/work/qtbase-everywhere-src-5.15.8/src/corelib/kernel/qcoreapplication.cpp:1064
#18 0x7ff960cc86a9 in QTimerInfoList::activateTimers()
(this=0x559053726dd0) at
/data/portage/portage/dev-qt/qtcore-5.15.8-r3/work/qtbase-everywhere-src-5.15.8/src/corelib/kernel/qtimerinfo_unix.cpp:643
#19 0x7ff960cc8f44 in timerSourceDispatch(GSource*, GSourceFunc, gpointer)
(source=) at
/data/portage/portage/dev-qt/qtcore-5.15.8-r3/work/qtbase-everywhere-src-5.15.8/src/corelib/kernel/qeventdispatcher_glib.cpp:183
#20 0x7ff95f935998 in g_main_dispatch (context=0x7ff954005010) at
../glib-2.74.5/glib/gmain.c:3454
#21 g_main_context_dispatch (context=context@entry=0x7ff954005010) at
../glib-2.74.5/glib/gmain.c:4172
#22 0x7ff95f935c28 in g_main_context_iterate
(context=context@entry=0x7ff954005010, block=block@entry=1,
dispatch=dispatch@entry=1, self=) at
[systemsettings] [Bug 447199] System Settings crashes on Wayland in KScreen::Config::clone() when display configuration changes
https://bugs.kde.org/show_bug.cgi?id=447199 --- Comment #8 from Sven Eden --- Created attachment 150605 --> https://bugs.kde.org/attachment.cgi?id=150605=edit New crash information added by DrKonqi systemsettings (5.25.2) using Qt 5.15.5 Maybe these additions help: After the crash the timer does not come back, no matter how I change my screen resolution or which screen (one panel, two monitors) => That said, I had DrKonqi open while I tried to reproduce the crash. -- Backtrace (Reduced): #6 QSharedPointer::data (this=) at /usr/include/qt5/QtCore/qsharedpointer_impl.h:301 #7 QSharedPointer::operator-> (this=) at /usr/include/qt5/QtCore/qsharedpointer_impl.h:307 #8 KScreen::Config::clone (this=0x0) at /data/portage/portage/kde-plasma/libkscreen-5.25.2/work/libkscreen-5.25.2/src/config.cpp:205 #9 0x7f05bce0ea1f in ConfigHandler::updateInitialData (this=0x557a6d64e910) at /usr/include/qt5/QtCore/qsharedpointer_impl.h:301 #10 0x7f05bce1100f in operator() (__closure=0x557a6f48c2a0) at /data/portage/portage/kde-plasma/kscreen-5.25.2/work/kscreen-5.25.2/kcm/kcm.cpp:180 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 447199] System Settings crashes on Wayland in KScreen::Config::clone() when display configuration changes
https://bugs.kde.org/show_bug.cgi?id=447199 Sven Eden changed: What|Removed |Added CC||s...@eden-worx.com -- You are receiving this mail because: You are watching all bug changes.
[kontact] [Bug 449872] Kontact crashed while trying to reply to email
https://bugs.kde.org/show_bug.cgi?id=449872
--- Comment #4 from Sven Eden ---
I have resolved my issue:
Nothing I found on the internet worked. Then I stumbled about a several year
old post, where someone on a Kubuntu system suggested to purge sonnet.
So I unmerged (deinstalled) kde-frameworks/sonnet-5.90.0 from my system.
As several other packages where linked against
/usr/lib64/libKF5SonnetCore.so.5.90.0 and /usr/lib64/libKF5SonnetUi.so.5.90.0,
the Gentoo build manager Portage kept those libraries nevertheless.
There is a special install target to rebuild those packages ("emerge
@preserved-rebuild"), which I ran.
It did not only re-install sonnet, but also rebuilt
kde-frameworks/ktextwidgets-5.90.0
kde-apps/kpimtextedit-21.12.2
kde-apps/kanagram-21.12.2
kde-plasma/kdeplasma-addons-5.24.0
kde-plasma/kmenuedit-5.24.0
kde-plasma/plasma-desktop-5.24.0
kde-apps/libksieve-21.12.2
kde-apps/messagelib-21.12.2
kde-apps/ktp-text-ui-21.12.2
kde-apps/parley-21.12.2
kde-frameworks/khtml-5.90.0
kde-frameworks/ktexteditor-5.90.0
and finally:
kde-apps/kmail-21.12.2
The next time I tried to start Kontact, it showed up, and opened dozens of
windows with an empty e-mail to the person I originally tried to reply to.
After I had closed (and discarded) all these windows, everything seemed to be
fine.
I am still testing, but it seems Kontact is back to normal.
--
You are receiving this mail because:
You are watching all bug changes.
[kontact] [Bug 449872] Kontact crashed while trying to reply to email
https://bugs.kde.org/show_bug.cgi?id=449872 --- Comment #3 from Sven Eden --- I ran "akonadictl fsck" and it found some items to clean up and scheduled some re-indexing. When the indexing agent finished, another run of "akonadictl fsck" did not find any issues. Kontact/Kmail are still crashing when starting. Once thing I forgot to mention: The crash happens even before a window shows up. -- You are receiving this mail because: You are watching all bug changes.
[kontact] [Bug 449872] Kontact crashed while trying to reply to email
https://bugs.kde.org/show_bug.cgi?id=449872 --- Comment #2 from Sven Eden --- Interesting... Adams and my crash happened about around the same time, yesterday... Both go through (Adam) KMComposerWin::slotRecipientAdded(MessageComposer::RecipientLineNG*) (this=0x562d31d2fe70, line=) at kmail-21.12.2/src/editor/kmcomposerwin.cpp:3776 ( me ) KMComposerWin::slotRecipientAdded(MessageComposer::RecipientLineNG*) (this=0x556321561410, line=) at kmail-21.12.2/src/editor/kmcomposerwin.cpp:3776 Then (Adam) QGpgME::QGpgMEAddUserIDJob::start(GpgME::Key const&, QString const&, QString const&, QString const&) (this=0x562d32e9f830, key=..., name=..., email=..., comment=) at qt/src/qgpgmeadduseridjob.cpp:82 ( me )QGpgME::QGpgMEAddUserIDJob::start(GpgME::Key const&, QString const&, QString const&, QString const&) (this=0x55632406a610, key=..., name=..., email=..., comment=...) at qgpgmeadduseridjob.cpp:82 Before that the stack consists of: (shortened) #33 src/widgets/widgets/qlineedit.cpp:318 #34 src/klineedit.cpp:371 #35 src/pimcommonakonadi/addressline/addresslineedit/addresseelineedit.cpp:249 #36 src/recipient/recipientline.cpp:169 #37 src/recipient/recipientline.cpp:135 #38 src/libkdepim/multiplyingline/multiplyinglineeditor.cpp:50 #39 src/recipient/recipientseditor.cpp:102 I think that this is an odd stack for an application startup. When I start KMail only, it also crashes and consists of this in the stack trace: (I have reformatted the lines to point at what DrKonqi presented me in red) #20 0x7f1649f142af in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (sender=sender@entry=0x560d43431dd0, m=m@entry=0x7f1649067800 , local_signal_index=local_signal_index@entry=2, argv=argv@entry=0x0) <=== argv=0x0 ? marked red by DrKonqi at src/corelib/kernel/qobject.cpp:3946 #21 0x7f1648f5be03 in MessageComposer::RecipientLineNG::countChanged() (this=this@entry=0x560d43431dd0) at messagecomposer/src/KF5MessageComposer_autogen/LXYSN6NNNG/moc_recipientline.cpp:481 #22 0x7f1648fb4ffe in MessageComposer::RecipientLineNG::analyzeLine(QString const&) (this=0x560d43431dd0, text=) at messagecomposer/src/recipient/recipientline.cpp:120 Why does starting kmail call the message composer at all? -- You are receiving this mail because: You are watching all bug changes.
[kontact] [Bug 449872] Kontact crashed while trying to reply to email
https://bugs.kde.org/show_bug.cgi?id=449872 --- Comment #1 from Sven Eden --- Created attachment 146521 --> https://bugs.kde.org/attachment.cgi?id=146521=edit New crash information added by DrKonqi kontact (5.19.2 (21.12.2)) using Qt 5.15.2 - What I was doing when the application crashed: Pressed 'a' to reply to everybody on a selected E-Mail in kmail component. Since then I can no longer start kontact, it immediately crashes. However, when I restart akonadi, I get notifications about new E-Mails, and KOrganizer works. Starting kmail directly also crashes. - Custom settings of the application: Gentoo Linux with gcc-11.2.1 and Qt-5.15.2 I have rebuilt everything needed for kontact plus kontact itself and have restarted the computer several times. The odd thing is, that Kontact worked just fine like every day. However, I have removed ~/.local/share/akonadi/db_data a week ago and have had akonadi recreate it. Everything worked just fine, so I doubt this could be the issue. -- Backtrace (Reduced): #6 QString::QString(QString const&) (other=, this=) at /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/include/g++-v11/bits/move.h:104 #7 std::_Head_base<4ul, QString, false>::_Head_base(QString const&) (__h=, this=) at /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/include/g++-v11/tuple:193 #8 std::_Tuple_impl<4ul, QString>::_Tuple_impl(QString const&) (__head=, this=) at /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/include/g++-v11/tuple:435 #9 std::_Tuple_impl<3ul, QString, QString>::_Tuple_impl(QString const&, QString const&) (__tail#0=, __head=, this=) at /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/include/g++-v11/tuple:284 #10 std::_Tuple_impl<2ul, QString, QString, QString>::_Tuple_impl(QString const&, QString const&, QString const&) (__tail#1=, __tail#0=, __head=, this=) at /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/include/g++-v11/tuple:284 -- You are receiving this mail because: You are watching all bug changes.
[kontact] [Bug 449872] Kontact crashed while trying to reply to email
https://bugs.kde.org/show_bug.cgi?id=449872 Sven Eden changed: What|Removed |Added CC||sven.e...@gmx.de -- You are receiving this mail because: You are watching all bug changes.
[kontact] [Bug 425872] Kontact crashes when accepting a delegated invitation
https://bugs.kde.org/show_bug.cgi?id=425872 --- Comment #1 from Sven Eden --- > Possible duplicates by query: bug 425720, bug 425651, bug 425629, bug > 425619, bug 425340. I have read all five and more, and none come close to this backtrace or near what is happening. So I hope I did the right thing reporting a new bug. -- You are receiving this mail because: You are watching all bug changes.
[kontact] [Bug 425872] New: Kontact crashes when accepting a delegated invitation
https://bugs.kde.org/show_bug.cgi?id=425872 Bug ID: 425872 Summary: Kontact crashes when accepting a delegated invitation Product: kontact Version: unspecified Platform: Compiled Sources OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kdepim-b...@kde.org Reporter: sven.e...@gmx.de Target Milestone: --- Application: kontact (5.15.0 (20.08.0)) (Compiled from sources) Qt Version: 5.15.0 Frameworks Version: 5.73.0 Operating System: Linux 5.7.18-gentoo x86_64 Windowing system: X11 Distribution: Gentoo/Linux -- Information about the crash: - What I was doing when the application crashed: A collegue delegated an invitation for a zoom meeting to me. When I press the "Accept" button, kontact crashes immediately. Important: Kontact works perfectly fine on any of the invitation response buttons in any invitation that got directly sent to me. This is the only case where it crashes. So I daresay the delegation has something to do with it. Some Background: The calendar used is an Exchange Calendar on an on-premise Exchange 2013 server, and is connected using CalDav over the latest version of davmail. I have searched for duplicates, but all DrKonqi showed me where about other areas than this. So hopefully I didn't miss _the_ relevant report I should have latched on. The crash can be reproduced every time. -- Backtrace: Application: Kontact (kontact), signal: Segmentation fault Content of s_kcrashErrorMessage: (null) [KCrash Handler] #6 0x7fb9a9cdedd4 in KMime::Content::parent() const (this=this@entry=0x5609fbd0cc80) at /data/portage/portage/kde-apps/kmime-20.08.0/work/kmime-20.08.0/src/kmime_content.cpp:828 #7 0x7fb9a9cdedea in KMime::Content::topLevel() const (this=this@entry=0x5609fbd0cc80) at /data/portage/portage/kde-apps/kmime-20.08.0/work/kmime-20.08.0/src/kmime_content.cpp:834 #8 0x7fb964eae11e in (anonymous namespace)::UrlHandler::findReceiver(KMime::Content*) (node=0x5609fbd0cc80) at /data/portage/portage/kde-apps/kdepim-addons-20.08.0/work/kdepim-addons-20.08.0/plugins/messageviewer/bodypartformatter/calendar/text_calendar.cpp:414 #9 0x7fb964eb3da0 in (anonymous namespace)::UrlHandler::handleInvitation(QString const&, KCalendarCore::Attendee::PartStat, MimeTreeParser::Interface::BodyPart*, MessageViewer::Viewer*) const (this=0x5609fb2cdce0, iCal=..., status=KCalendarCore::Attendee::Accepted, part=0x7ffe17263100, viewerInstance=0x5609f93da820) at /data/portage/portage/kde-apps/kdepim-addons-20.08.0/work/kdepim-addons-20.08.0/plugins/messageviewer/bodypartformatter/calendar/text_calendar.cpp:875 #10 0x7fb964eb615e in (anonymous namespace)::UrlHandler::handleClick(MessageViewer::Viewer*, MimeTreeParser::Interface::BodyPart*, QString const&) const (this=this@entry=0x5609fb2cdce0, viewerInstance=0x5609f93da820, part=part@entry=0x7ffe17263100, path=...) at /data/portage/portage/kde-apps/kdepim-addons-20.08.0/work/kdepim-addons-20.08.0/plugins/messageviewer/bodypartformatter/calendar/text_calendar.cpp:1217 #11 0x7fb9a87afab0 in MessageViewer::BodyPartURLHandlerManager::handleClick(QUrl const&, MessageViewer::ViewerPrivate*) const (this=, url=..., w=0x5609f95db0d0) at /data/portage/portage/kde-apps/messagelib-20.08.0-r1/work/messagelib-20.08.0/messageviewer/src/viewer/urlhandlermanager.cpp:168 #12 0x7fb9a87ad2c8 in MessageViewer::URLHandlerManager::handleClick(QUrl const&, MessageViewer::ViewerPrivate*) const (this=, url=..., w=w@entry=0x5609f95db0d0) at /data/portage/portage/kde-apps/messagelib-20.08.0-r1/work/messagelib-20.08.0/messageviewer/src/viewer/urlhandlermanager.cpp:288 #13 0x7fb9a8791661 in MessageViewer::ViewerPrivate::slotUrlOpen(QUrl const&) (this=0x5609f95db0d0, url=...) at /data/portage/portage/kde-apps/messagelib-20.08.0-r1/work/messagelib-20.08.0/messageviewer/src/viewer/viewer_p.cpp:2004 #14 0x7fb9ece100cd in QObject::event(QEvent*) (this=0x5609f95db0d0, e=0x7fb9b81091f0) at /data/portage/portage/dev-qt/qtcore-5.15.0/work/qtbase-everywhere-src-5.15.0/src/corelib/kernel/qobject.cpp:1314 #15 0x7fb9ed8567cf in QApplicationPrivate::notify_helper(QObject*, QEvent*) (this=this@entry=0x5609f89db9a0, receiver=receiver@entry=0x5609f95db0d0, e=e@entry=0x7fb9b81091f0) at /data/portage/portage/dev-qt/qtwidgets-5.15.0/work/qtbase-everywhere-src-5.15.0/src/widgets/kernel/qapplication.cpp:3671 #16 0x7fb9ed85f5f0 in QApplication::notify(QObject*, QEvent*) (this=0x7ffe17263840, receiver=0x5609f95db0d0, e=0x7fb9b81091f0) at /data/portage/portage/dev-qt/qtwidgets-5.15.0/work/qtbase-everywhere-src-5.15.0/src/widgets/kernel/qapplication.cpp:3417 #17 0x7fb9ecde4598 in QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=0x5609f95db0d0, event=0x7fb9b81091f0) at
[ksmserver] [Bug 256605] KSMServer crashes everytime on shutdown or restart [~QRasterWindowSurface, ~QWidgetBackingStore, ..., KSelectionOwner::Private::~Private, KSelectionOwner::~KSelectionOwner]
https://bugs.kde.org/show_bug.cgi?id=256605 --- Comment #11 from Sven Eden --- As both KDE 4.5.3 and Qt 4.7.0 are off the grid for a long time, now, this can surely be closed, can't it? -- You are receiving this mail because: You are watching all bug changes.
[kdelibs] [Bug 324084] QA Notice: kdelibs-4.11.0/kdecore/io/kdebug.h:260:64: warning: array subscript is above array bounds [-Warray-bounds]
https://bugs.kde.org/show_bug.cgi?id=324084 Sven Eden changed: What|Removed |Added Resolution|--- |WORKSFORME Status|REPORTED|RESOLVED --- Comment #6 from Sven Eden --- I think we can close this. If there is a system still using kdelibs-4.x out there, it hasn't exploded, yet. Therefore I assume that this array in question is in no way able to wreak havoc. -- You are receiving this mail because: You are watching all bug changes.
[kwalletmanager] [Bug 356624] KWalletManager - You are not allowed to save settings
https://bugs.kde.org/show_bug.cgi?id=356624 Sven Eden <sven.e...@gmx.de> changed: What|Removed |Added CC||sven.e...@gmx.de --- Comment #3 from Sven Eden <sven.e...@gmx.de> --- I can confirm that the kwallet kcm module does no longer allow me to save any settings. All relevant files are owned by me. Gentoo Linux QT 5.7.1 KDE Frameworks 5.29 KDE Plasma 5.8.5 KDE Apps 16.12.1 Changing the settings by editing ~/.config/kwalletrc by hand does work. But the kcm does not allow any changes. -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 368161] Plasma (plasmashell), signal: Segmentation fault
https://bugs.kde.org/show_bug.cgi?id=368161 Sven Eden <sven.e...@gmx.de> changed: What|Removed |Added CC||sven.e...@gmx.de --- Comment #3 from Sven Eden <sven.e...@gmx.de> --- Unfortunately I have to add my backtrace by hand. DrKonqi lets me log in and find this report, but when I want to attach my report and click on "continue", nothing happens. :-( The crashing Thread 1 looks similar, but not exactly equal. However, Plasma crashed after I issued "akonadictl stop" in a console. I think that this is odd. I am using: System : Gentoo x86_64 Framework: 5.29.0 Plasma : 5.8.4 Apps : 16.12.0 QT : 5.7.1 GCC : 5.4.0 GLIBC: 2.23 Could this be some sort of race condition? -- Backtrace: Application: Plasma (plasmashell), signal: Segmentation fault Using host libthread_db library "/lib64/libthread_db.so.1". [Current thread is 1 (Thread 0x7f5e9c608780 (LWP 16603))] Thread 9 (Thread 0x7f5dcd141700 (LWP 22436)): #0 0x7f5e92f8e4a9 in g_source_iter_next (iter=iter@entry=0x7f5dcd140c80, source=source@entry=0x7f5dcd140c78) at /home/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/glib/gmain.c:982 #1 0x7f5e92f90d9a in g_main_context_check (context=context@entry=0x7f5dc8003200, max_priority=2147483647, fds=fds@entry=0x7f5dc80033e0, n_fds=n_fds@entry=1) at /home/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/glib/gmain.c:3742 #2 0x7f5e92f91400 in g_main_context_iterate (context=context@entry=0x7f5dc8003200, block=block@entry=1, dispatch=dispatch@entry=1, self=) at /home/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/glib/gmain.c:3926 #3 0x7f5e92f9156c in g_main_context_iteration (context=0x7f5dc8003200, may_block=may_block@entry=1) at /home/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/glib/gmain.c:3990 #4 0x7f5e97894ccb in QEventDispatcherGlib::processEvents (this=0x7f5dc8002700, flags=...) at kernel/qeventdispatcher_glib.cpp:425 #5 0x7f5e9784654a in QEventLoop::exec (this=this@entry=0x7f5dcd140e40, flags=..., flags@entry=...) at kernel/qeventloop.cpp:212 #6 0x7f5e9769de24 in QThread::exec (this=) at thread/qthread.cpp:507 #7 0x7f5e976a206c in QThreadPrivate::start (arg=0x73ce6a0) at thread/qthread_unix.cpp:368 #8 0x7f5e967503a4 in start_thread (arg=0x7f5dcd141700) at pthread_create.c:333 #9 0x7f5e96f4c50d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 8 (Thread 0x7f5dd5da3700 (LWP 18808)): #0 0x7f5e96f3f45d in read () at ../sysdeps/unix/syscall-template.S:84 #1 0x7f5e92fd6230 in read (__nbytes=16, __buf=0x7f5dd5da2c00, __fd=) at /usr/include/bits/unistd.h:44 #2 g_wakeup_acknowledge (wakeup=0x7f5dd01b0f90) at /home/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/glib/gwakeup.c:210 #3 0x7f5e92f90f2e in g_main_context_check (context=context@entry=0x7f5dd000f030, max_priority=2147483647, fds=fds@entry=0x7f5dd0351c00, n_fds=n_fds@entry=1) at /home/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/glib/gmain.c:3707 #4 0x7f5e92f91400 in g_main_context_iterate (context=context@entry=0x7f5dd000f030, block=block@entry=1, dispatch=dispatch@entry=1, self=) at /home/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/glib/gmain.c:3926 #5 0x7f5e92f9156c in g_main_context_iteration (context=0x7f5dd000f030, may_block=may_block@entry=1) at /home/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/glib/gmain.c:3990 #6 0x7f5e97894ccb in QEventDispatcherGlib::processEvents (this=0x7f5dd01ae230, flags=...) at kernel/qeventdispatcher_glib.cpp:425 #7 0x7f5e9784654a in QEventLoop::exec (this=this@entry=0x7f5dd5da2e20, flags=..., flags@entry=...) at kernel/qeventloop.cpp:212 #8 0x7f5e9769de24 in QThread::exec (this=this@entry=0x1926330) at thread/qthread.cpp:507 #9 0x7f5e99e72895 in QQmlThreadPrivate::run (this=0x1926330) at qml/ftw/qqmlthread.cpp:147 #10 0x7f5e976a206c in QThreadPrivate::start (arg=0x1926330) at thread/qthread_unix.cpp:368 #11 0x7f5e967503a4 in start_thread (arg=0x7f5dd5da3700) at pthread_create.c:333 #12 0x7f5e96f4c50d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 7 (Thread 0x7f5dde3ac700 (LWP 16878)): #0 0x7f5e92f8e462 in g_source_iter_next (iter=iter@entry=0x7f5dde3abc40, source=source@entry=0x7f5dde3abc38) at /home/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/glib/gmain.c:987 #1 0x7f5e92f90d9a in g_main_context_check (context=context@entry=0x7f5dd8000990, max_priority=2147483647, fds=fds@entry=0x7f5dd80048a0, n_fds=n_fds@entry=1) at /home/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/glib/gmain.c:3742 #2 0x7f5e92f91400 in g_main_context_iterate (context=context@entry=0x7f5dd8000990, block=block@entry=1, dispatch=dispatch@entry=1, self=) at /home/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/glib/gmain.c:3926 #3 0x7f5e92f9156c in g_main_context_it
[kwin] [Bug 372015] kwin_x11 crashes when logging in
https://bugs.kde.org/show_bug.cgi?id=372015 --- Comment #14 from Sven Eden <sven.e...@gmx.de> --- (In reply to Martin Gräßlin from comment #13) > > However, there was a time when GLES2 support was needed for EGL, which is > > needed for wayland. If that is no longer the case, we can eventually build > > everything without any OpenGL ES support? That would be so great! :-) > (Honestly, GLES is a pain.) > > This requirement went away years ago. EGL is not bound to OpenGL ES any more > and can create an OpenGL context. That's how Wayland works today. And it was the culprit. I have removed all support for OpenGL ES and Plasma works fine with my Aurorae setup using mesa-13.0.1. Martin, thank you very much! Without your help I would not have suspected GLES support to be the problem anytime soon! :-) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 372015] kwin_x11 crashes when logging in
https://bugs.kde.org/show_bug.cgi?id=372015 --- Comment #12 from Sven Eden <sven.e...@gmx.de> --- Unfortunately this was a no go. And the "Backtrace" is highly illuminating: "Application: KWin (kwin_x11), signal: Aborted" That's it. Nothing more. No backtrace, nothing. (In reply to Martin Gräßlin from comment #11) > @Sven: the only possibility that KWin picks EGL without any config set to it > or env variable is that you compiled the Qt and KWin stack with OpenGL ES > instead of OpenGL. This is something we see quite often for Gentoo users. So there is a) the removal of the EGL/GLX choice, but b) a backdoor for EGL slithering back in without any control of the user. I'd call that an oversight that needs to be fixed? ;-) However, there was a time when GLES2 support was needed for EGL, which is needed for wayland. If that is no longer the case, we can eventually build everything without any OpenGL ES support? That would be so great! :-) (Honestly, GLES is a pain.) But as I see now, libsdl2-2.0.5 wants mesa with GLES2 support for it to be able to use wayland. Yes. It's configure script needs both video_opengl_egl and video_opengles_v2 to allow to enable video_wayland. ...what a pity. No wayland support for libsdl2 then. Everything else seems to have gotten rid of that ridiculous dependency. *yay*! (In reply to Martin Gräßlin from comment #11) > Concerning the Aurorae crash: no, nobody is working on it. While we see the > crash happens for many users, we devs have never been able to reproduce it. Well, I have no crash with mesa-12.0.4 and GLX. The whole damn thing is rock solid here. The only way for me to reproduce this is when "EGL" is chosen. (Which I just forced off anyway.) Bt maybe your hint about OpenGL ES 2 is the key to solving this. I am currently rebuilding everything that had GLES2 support without it. The fine thing about gentoo is, that we can easily try these things out, and even on a very fine grained scale. :-) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 372015] kwin_x11 crashes when logging in
https://bugs.kde.org/show_bug.cgi?id=372015 --- Comment #10 from Sven Eden <sven.e...@gmx.de> --- (In reply to Martin Gräßlin from comment #7) > @Sven: because KWin writes out the current runtime configuration. It loads > with that from your config and writes it back. If you manually want to > change the config you need to stop KWin. I am very sorry that I did not make this clear enough. I'll try with a list of actions. - Machine booted to console after one of those crashes. - Edit ~/.config/kwinrc and set OpenGLIsUnsafe to "false" and GLPlatformInterface to "glx". (Without the quotation marks of course) - Start SDDM via xdm and log into Plasma. - Compositor is off, systemsettings5 states that it crashed kwin in the past. - Reactivate OpenGL detection. - All decorations disappear with kwin crashing. - Open Yakuake with F12 and "grep GLPlatform ~/.config/kwinrc" reveals, that it is back to "egl". So no, it did not write back a configuration it read, it just decided that egl is a good thing to use. I have scanned all my system and user files whether I have accidentally set KWIN_OPENGL_INTERFACE="egl" somewhere, but my search revealed nothing. So I have solved this particular part for me by simply adding KWIN_OPENGL_INTERFACE="glx" to the environment. I am back on mesa-12.0.4 and kwin uses the glx back end. Everything is stable. But another question: Is the "Standard Aurorae/QML" thing something that is worked on? Actually I do use Oxygen with Helium Design and air-oxygen decorations. It is okay if people like Breeze, but I do not. It is too flat, too monochromatic and is more in my way than it helps. The desings based on Breeze do not mix well with the Oxygen icons, and the breeze icons are a nightmare. It is like being back on an Amiga 500 Workbench 1.3 with a monochrome monitor. However, kwin crashes too with everything set to "Breeze" when mesa-13+ is installed. But I guess forcing "glx" might fix that, I'll try this out today and report back. Meaning: kwin-5.8.3 + mesa-13.0.1 + forced "glx" PlatformInterface + "Breeze everywhere". -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 372015] kwin_x11 crashes when logging in
https://bugs.kde.org/show_bug.cgi?id=372015 Sven Eden <sven.e...@gmx.de> changed: What|Removed |Added CC||sven.e...@gmx.de --- Comment #6 from Sven Eden <sven.e...@gmx.de> --- It's mesa. I have tried a few times to upgrade to mesa-13.0.1, but kwin does not like it. Or it is the other way round. Downgrading to mesa-12.0.4 solved the issue for me. @Gregory: Find an ebuild of the missing 12.0.4 version of mesa in my overlay layman/seden. My System: Gentoo Linux Kernel-4.8.9 QT-4.7.0 KDE-Frameworks-5.28.0 KDE-Plasma-5.8.3 KDE-Apps-16.08.3 Init System: OpenRC Session Tracker: elogind @Martin: btw, in august you blogged that in plasma 5.8 the EGL/GLX selection was removed, and that "on X11 the default will stay GLX". Why is it, then, that whenever I re-activate compositing it will write "GLPlatformInterface=egl" into my kwinrc? -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 363741] akonadi server 16.04.2: crashing every few seconds
https://bugs.kde.org/show_bug.cgi?id=363741 Sven Eden <sven.e...@gmx.de> changed: What|Removed |Added CC||sven.e...@gmx.de --- Comment #14 from Sven Eden <sven.e...@gmx.de> --- I tried this and removed the search folder. After a restart of both akonadi and kontact (I had gdb hooked to the akonadiserver process) and trying to do a search, gdb caught a SIGSEGV with the following trace: Thread 60 "QThread" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fd009ffb700 (LWP 17593)] 0x7fcfe854b9a8 in vtable for Xapian::Internal::QueryTerm () from /usr/lib64/libxapian-1.3.so.8 (gdb) bt #0 0x7fcfe854b9a8 in vtable for Xapian::Internal::QueryTerm () from /usr/lib64/libxapian-1.3.so.8 #1 0x7fcfe82a301b in ExternalPostList::ExternalPostList (this=0x7fcff009f1e0, db=..., source_=, factor_=, matcher=0x7fd009ff9d10) at matcher/externalpostlist.cc:40 #2 0x7fcfe81b5d4b in Xapian::Internal::QueryPostingSource::postlist (this=, qopt=0x7fd009ff9630, factor=1) at api/queryinternal.cc:739 #3 0x7fcfe81b40b1 in Xapian::Query::Internal::postlist_sub_xor (this=, ctx=..., qopt=, factor=) at api/queryinternal.cc:634 #4 0x7fcfe81b5533 in Xapian::Internal::QueryBranch::do_or_like (this=this@entry=0x7fcff001bd60, ctx=..., qopt=qopt@entry=0x7fd009ff9630, factor=factor@entry=1, elite_set_size=elite_set_size@entry=0, first=first@entry=1) at api/queryinternal.cc:1186 #5 0x7fcfe81b5afa in Xapian::Internal::QueryAndMaybe::postlist (this=0x7fcff001bd60, qopt=0x7fd009ff9630, factor=1) at api/queryinternal.cc:1550 #6 0x7fcfe82a32da in LocalSubMatch::get_postlist (this=0x7fcff009a6c0, matcher=0x7fd009ff9d10, total_subqs_ptr=0x7fd009ff979c) at matcher/localsubmatch.cc:204 #7 0x7fcfe82a9741 in MultiMatch::get_mset (this=this@entry=0x7fd009ff9d10, first=first@entry=0, maxitems=95894, check_at_least=check_at_least@entry=95894, mset=..., stats=..., mdecider=0x0, sorter=0x0) at matcher/multimatch.cc:419 #8 0x7fcfe81a4641 in Xapian::Enquire::Internal::get_mset (this=0x7fcff009a830, first=, maxitems=, check_at_least=, check_at_least@entry=0, rset=rset@entry=0x0, mdecider=0x0) at api/omenquire.cc:548 #9 0x7fcfe81a4984 in Xapian::Enquire::get_mset (this=this@entry=0x7fd009ffa030, first=, maxitems=, check_at_least=check_at_least@entry=0, rset=rset@entry=0x0, mdecider=0x0) at api/omenquire.cc:906 #10 0x7fcfe05e967d in Akonadi::Search::XapianSearchStore::exec (this=0x7fcff003fe70, query=...) at /home/portage/kde-apps/akonadi-search-16.04.2/work/akonadi-search-16.04.2/xapian/xapiansearchstore.cpp:177 #11 0x7fd00919e2e5 in Akonadi::Search::Query::exec (this=this@entry=0x7fd009ffa2a0) at /home/portage/kde-apps/akonadi-search-16.04.2/work/akonadi-search-16.04.2/core/query.cpp:252 #12 0x7fd0095f5f6d in SearchPlugin::search (this=, akonadiQuery=..., collections=..., mimeTypes=...) at /home/portage/kde-apps/akonadi-search-16.04.2/work/akonadi-search-16.04.2/akonadiplugin/searchplugin.cpp:348 #13 0x0053ed1d in Akonadi::Server::SearchRequest::searchPlugins (this=this@entry=0x7fd009ffa880) at /home/portage/kde-apps/akonadi-16.04.2/work/akonadi-16.04.2/src/server/search/searchrequest.cpp:112 #14 0x0053ef7f in Akonadi::Server::SearchRequest::exec (this=this@entry=0x7fd009ffa880) at /home/portage/kde-apps/akonadi-16.04.2/work/akonadi-16.04.2/src/server/search/searchrequest.cpp:123 #15 0x00443944 in Akonadi::Server::SearchManager::updateSearchImpl (this=, collection=..., cond=0x7fceeaffc4e0) at /home/portage/kde-apps/akonadi-16.04.2/work/akonadi-16.04.2/src/server/search/searchmanager.cpp:350 #16 0x004fbea5 in Akonadi::Server::SearchManager::qt_static_metacall (_o=, _c=, _id=, _a=) at /home/portage/kde-apps/akonadi-16.04.2/work/akonadi-16.04.2_build/src/server/moc_searchmanager.cpp:108 #17 0x7fd0165f8711 in QObject::event (this=0x27ac890, e=) at kernel/qobject.cpp:1256 #18 0x7fd0165cfaaa in doNotify (receiver=, event=) at kernel/qcoreapplication.cpp:1090 #19 0x7fd0165cfbda in QCoreApplication::notifyInternal2 (receiver=0x27ac890, event=event@entry=0x7fceec0deef0) at kernel/qcoreapplication.cpp:1015 #20 0x7fd0165d1c2a in QCoreApplication::sendEvent (event=0x7fceec0deef0, receiver=) at kernel/qcoreapplication.h:225 #21 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x27ab840) at kernel/qcoreapplication.cpp:1650 #22 0x7fd0165d20e8 in QCoreApplication::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0) at kernel/qcoreapplication.cpp:1508 #23 0x7fd01661ec13 in postEventSourceDispatch (s=0x7fcff00012d0) at kernel/qeventdispatcher_glib.cpp:270 #24 0x7fd013da0
[Akonadi] [Bug 255388] Kmail filters dont work in incoming mail
https://bugs.kde.org/show_bug.cgi?id=255388 --- Comment #114 from Sven Eden <sven.e...@gmx.de> --- Update on my previous report: After the mail filter finished, it got stuck at 100%. The akonadi_mailfilter_agent process used 100% CPU, and was neither interruptible nor stoppable using akonadiconsole. I quit kontact, shut down akonadi and even logged out and back into plasma, but the process remained until I killed it. After that it worked just fine yesterday. Today I wanted to filter some mails and it just started at 100% and was stuck again until the process got killed. I tried several times, with kontact and akonadi restarting in between, but always ended up killing the akonadi_mailfilter_agent. Then, all of a sudden, a myriad of status windows popped up, all with the filter being at 100%, but eventually it started its work regularly. If I had to guess, I'd think the filter has at least one race condition and a problematic endless loop somewhere. Didn't look up the sources, though... -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 255388] Kmail filters dont work in incoming mail
https://bugs.kde.org/show_bug.cgi?id=255388 Sven Eden <sven.e...@gmx.de> changed: What|Removed |Added CC||sven.e...@gmx.de --- Comment #113 from Sven Eden <sven.e...@gmx.de> --- I just came across this. Normally it was enough to fire up akonadiconsole, restart the mail filter agent, and then quickly start kontact. Not today. When, for the umpteenth time, the mail filter was stuck at 0%, I opened the akonadiconsole, and selected "Abort Activity" on the mail filter agent. And it immediately began to filter the 1,046 mails I had selected. So it seems, that the filter agent got ordered to do something else before answering my request and got stuck on that, and not the requested filtering itself. It is slow right now, because I had activated the filter log, but at least it works again. -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 354994] Crash of Akonadi CardCalDav
https://bugs.kde.org/show_bug.cgi?id=354994 --- Comment #13 from Sven Eden <sven.e...@gmx.de> --- Created attachment 97378 --> https://bugs.kde.org/attachment.cgi?id=97378=edit Check mEtagCaches[collection.remoteId()] result before using it The patch fixed the crash for me. However, I *do* think that it is a different issue, but at least you now know about it. ;-) -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 354994] Crash of Akonadi CardCalDav
https://bugs.kde.org/show_bug.cgi?id=354994 Sven Eden <sven.e...@gmx.de> changed: What|Removed |Added CC||sven.e...@gmx.de --- Comment #12 from Sven Eden <sven.e...@gmx.de> --- Hmm... I've updated to 15.12.2 but all mails regarding exchange calendar invitations still crash the resource. Maybe I hit a different bug? I got: "akonadi_davgroupware_resource" Signal: Segmentation fault (11) The most interesting lines from the backtrace are: #5 #6 QMap<QString, QString>::detach (this=0x10) at /usr/include/qt5/QtCore/qmap.h:364 #7 QMap<QString, QString>::operator[] (akey=..., this=0x10) at /usr/include/qt5/QtCore/qmap.h:629 #8 EtagCache::setEtag (this=0x0, remoteId=..., etag=...) at /home/portage/kde-apps/kdepim-runtime-15.12.2/work/kdepim-runtime-15.12.2/resources/dav/common/etagcache.cpp:38 #9 0x004719ed in DavGroupwareResource::onItemFetched (this=0x1239990, job=, updateType=DavGroupwareResource::ItemUpdateAdd) at /home/portage/kde-apps/kdepim-runtime-15.12.2/work/kdepim-runtime-15.12.2/resources/dav/resource/davgroupwareresource.cpp:958 See frame #8 where 'this' is 0x0? Frame #8 source is: (gdb) frame 8 #8 EtagCache::setEtag (this=0x0, remoteId=..., etag=...) at /home/portage/kde-apps/kdepim-runtime-15.12.2/work/kdepim-runtime-15.12.2/resources/dav/common/etagcache.cpp:38 38 mCache[ remoteId ] = etag; Frame #9 source is: (gdb) frame 9 #9 0x004719ed in DavGroupwareResource::onItemFetched (this=0x1239990, job=, updateType=DavGroupwareResource::ItemUpdateAdd) at /home/portage/kde-apps/kdepim-runtime-15.12.2/work/kdepim-runtime-15.12.2/resources/dav/resource/davgroupwareresource.cpp:958 958 mEtagCaches[collection.remoteId()]->setEtag(item.remoteId(), davItem.etag()); So I *guess* collection.remoteId() should be checked first... -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 344328] krunner is not visible when using multiple monitors
https://bugs.kde.org/show_bug.cgi?id=344328 Sven Eden <sven.e...@gmx.de> changed: What|Removed |Added CC||sven.e...@gmx.de --- Comment #18 from Sven Eden <sven.e...@gmx.de> --- I can confirm this issue on Gentoo Linux with the following software installed: QT 5.5.1 Frameworks 5.18.0 Plasma 5.5.4 Apps: 15.12.1 The workaround from comment #5 is a real helper! Thank you a lot! I take my laptop home every day and only have an external monitor at work. It does not not seem to be relevant whether I plug in the external monitor before resuming from suspend or after. krunner does not show up on the external monitor but works invisibly. -- You are receiving this mail because: You are watching all bug changes.
