Summary: | Crash handler crash on login in QString::size() | ||
---|---|---|---|
Product: | [Applications] drkonqi | Reporter: | Jaak Ristioja <jaak> |
Component: | general | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | sitter |
Priority: | NOR | ||
Version: | 5.16.4 | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Jaak Ristioja
2019-08-06 06:40:45 UTC
I am guessing this isn't reproducible? (In reply to Harald Sitter from comment #1) > I am guessing this isn't reproducible? Why do you think so? After reporting this, I've seen the crash notification for drkonqi appear after login at least 2-3 times, but I didn't investigate any further as this was not a blocker. Are there any other details you want me to investigate if this happens again? It's one of the most illusive crashes I've seen. It affects fairly unrelated apps, doesn't always have the same call chain, but most of all I don't actually see how the code could crash there. Also, all other reports have zero worthwhile information beyond the backtrace. So, what I would like you to do is: - install systemd-coredump - make sure it is set up correctly (/proc/sys/kernel/core_pattern should be set to invoke it) - maybe test by using kill -SEGV on a terminal process - disable kcrash by adding KDE_DEBUG=1 to your /etc/environment - restart and trigger the bug coredumpctl will then able to catch a super accurate core and context of the crash. Please post the coredumpctl info of the crash and check if there might be other crashes that happen around the same time. Additionally please check your .xession-errors, journald/syslog for relevant information around the time the crash occurs (coredumpctl will be able to give you the accurate time it crashed). It's a long shot but the crash may be a symptom of something else. The code in question to do with QStringList, while involving pointers, should not really be able to crash, certainly not while the qapplication loop is still running. So, I wouldn't even begin to figure out what is wrong without patching Qt and seeing what happens. From related bugs I could find it looks like this crash appears seemingly randomly and then disappears again and has no discernible pattern beyond the top most stack frame being the QStringList contains. (In reply to Harald Sitter from comment #3) > - install systemd-coredump I'm not using systemd so I don't think this will be an option. However, I think I could still use the gcore command-line utility to generate a core dump (or attach GDB to the crashed process and use the gcore command). > - restart and trigger the bug ...if it triggers. Because I haven't seen it lately. I also tried logging in and out again (+ killall -u username -9) multiple times, but I couldn't reproduce it. > It's a long shot but the crash may be a symptom of something else. The code > in question to do with QStringList, while involving pointers, should not > really be able to crash, certainly not while the qapplication loop is still > running. So, I wouldn't even begin to figure out what is wrong without > patching Qt and seeing what happens. > From related bugs I could find it looks like this crash appears seemingly > randomly and then disappears again and has no discernible pattern beyond the > top most stack frame being the QStringList contains. I'll make sure to investigate for any other signs such if it reoccurs. Do you have any references to similar bug reports? Do you think it is a drkonqi issue or rather a Qt issue (e.g. perhaps something similar to QTBUG-39285)? Possibly related: bug #409752 bug #391358 bug #379862 bug #287480 bug #295903 There are maybe 6 bugs entailing qdbus and maybe 4 times that with a slightly different call chain. Some of the related ones I've looked at go back to ABI problems, which is certainly a possibility here as well. I would rather expect all mainstream distros to have a handle on this though. QTBUG-39285 did sound related, but was supposedly fixed in 5.3. If it is still not thread safe we'll see through coredumpctl though. Drkonqi itself wouldn't be able to fetch a reliable backtrace in that scenario because of how SEGV works for posix threads. Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |