| Summary: | kdeinit crashes at login | ||
|---|---|---|---|
| Product: | [Unmaintained] kdelibs | Reporter: | Andreas Schallenberg <Andreas.Schallenberg> |
| Component: | kded | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | crash | CC: | cfeck, lamarque, zingel |
| Priority: | NOR | Keywords: | triaged |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Valgrind output, part A
Valgrind output, part B |
||
|
Description
Andreas Schallenberg
2012-02-20 09:52:19 UTC
From the backtrace, it is not possible to tell which kded module causes the crash, as the memory corruption could have happened anywhere. It could be the Network Management module. To check if this is the case, try disabling that module by using System Settings > System Administration > Startup and Shutdown > Service Manager. Disable "NetworkManager" in the "Startup Services" there, and restart KDE. If this does not help, a different module could be causing the crash, and some patience is required to isolate it by disabling one of them. For more information, see http://kdepepo.wordpress.com/2011/05/11/troubleshooting-kded4-bugs/ Thank you for the quick reply! It looks like the network manager is the right direction. I disabled it and restarted KDE twice without the crash appearing. For curiosity, I enabled and disabled the network manager and my system was froze a few seconds later (no mouse movement, xload frozen, ...). I needed to powercycle the PC. I will observe this further and report if it is reliably gone. By the way, this is a PC with a fixed IP so perhaps this causes trouble for NM. The bug happens in kdelibs when inserting the localization catalog of ModemManager backend. Plasma NM is the only program I know that uses the ModemManager backend, that's why removing it workarounds the problem. However, the bug really seems to happen in kdelibs. Or more precisely the bug seems to happen in nvidia driver :-/ Yes, this PC has an NVidia card and its driven by the proprietary driver v290.10. See bug 290864 for the same backtrace without NVIDIA driver. To me it simply looks like a memory corruption, and it would be useful to know if it also happens with newer version of the Plasma networkmanagement suite. In that case, a valgrind log of kded4 running would be needed. #290864 happens in ktorrent and does not have Plasma NM involved according to the backtrace. > (...) In that case, a valgrind log of kded4 running would be needed.
That would require a /usr/bin/kdeinit4 file that is compiled differently, right?
No, valgrind does not require any recompilation. Just kill existing "kded4" process, and start it via valgrind. Well, is that of any help? When it crashes, it does so at login (when it is started by kdeinit). Kded is restarted right afterwards. I could kill that new instance and start a new one with valgrind and then logout. But would that help you in any way? I think a better test is checking if it does not crash when using another driver (nouveau or vesa). It does not crash then it's very likely the problem is in the proprietary nvidia driver or incompatibility between it and xorg. I have an identically problem using the proprietary nvidia driver. I only have this problem when i have connected an external monitor at the laptop. When it crashes, there is much HD activity. If I restart plasma, after it crashes, it will crash again, until the HD activity goes down. Bit it only crashes at login, it never crashed after a while. I had no time to test this with another driver yet but I also use a non-trivial monitor solution. Its two monitors with one turned by 90 degrees. I did a test: 1) Disabled network manager from kde services to start 2) Rebooted system 3) Terminated kded4 (kill -QUIT) and restarted it with valgrind 4) Enabled network manager service 5) killed kded4 again I'll attach the valgrind output in two parts. Part A contains output of 3) and part B from 4) on. Created attachment 69040 [details]
Valgrind output, part A
Created attachment 69041 [details]
Valgrind output, part B
Part B indicates that something goes wrong at networkinterfacemonitor.cpp:70. (In reply to comment #17) > Part B indicates that something goes wrong at networkinterfacemonitor.cpp:70. There is too many things happening in lin 70, which contains a #define macro (foreach). The valgrind log does not help that much to figure out each variable the invalid write happens on. Is this still reproducible with a newer KDE version and/or a newer KDE NetworkManagement version? If you can provide the information requested in comment #19, please add it. 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 set the bug status 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! The report is six years old by now and no comment was indicating that there was anything done along the line. This was KDE 4, I moved to KDE 5 by now. I cannot test, if it the error is still somewhere in the code. After these years of idling, we'll never know. |