Bug 262268 - KDevelop crashes on start, valgrind shows invalid memory access
Summary: KDevelop crashes on start, valgrind shows invalid memory access
Status: RESOLVED WORKSFORME
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: kdecore (show other bugs)
Version: SVN
Platform: Compiled Sources Linux
: NOR crash
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-06 03:20 UTC by Petr Mrázek
Modified: 2018-11-28 06:50 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
Valgrind output from successful start (74.93 KB, text/plain)
2011-01-06 03:20 UTC, Petr Mrázek
Details
Valgrind output from successful start (72.41 KB, text/plain)
2011-01-07 18:50 UTC, Petr Mrázek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Mrázek 2011-01-06 03:20:10 UTC
Created attachment 55633 [details]
Valgrind output from successful start

Version:           SVN (using KDE 4.5.90) 
OS:                Linux

The code was checked out from kdevelop git, master branch. Seems to be some kind of memory corruption issue, see attached valgrind and gdb outputs.
The gdb output is from a run where it crashed, the valgrind output is from one where kdevelop managed to survive.
This is with KDE 4.6 RC1 packages from kde-unstable Arch Linux repository.

Reproducible: Sometimes

Steps to Reproduce:
Run kdevelop.



gdb output:
Starting program: /usr/bin/kdevelop 
[Thread debugging using libthread_db enabled]
KGlobal::locale::Warning your global KLocale is being recreated with a valid main component instead of a fake component, this usually means you tried to call i18n related functions before your main component was created. You should not do that since it most likely will not work 

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff391b2fa in QString::append(QString const&) () from /usr/lib/libQtCore.so.4
(gdb) bt
#0  0x00007ffff391b2fa in QString::append(QString const&) () from /usr/lib/libQtCore.so.4
#1  0x00007ffff7af4ae6 in ?? () from /usr/lib/libkdecore.so.5
#2  0x00007ffff7aec071 in ?? () from /usr/lib/libkdecore.so.5
#3  0x00007ffff7aeb621 in ?? () from /usr/lib/libkdecore.so.5
#4  0x00007ffff7a5ff13 in KGlobal::setActiveComponent(KComponentData const&) () from /usr/lib/libkdecore.so.5
#5  0x00007ffff7a62273 in KComponentData::KComponentData(KAboutData const*, KComponentData::MainComponentRegistration) ()
   from /usr/lib/libkdecore.so.5
#6  0x00007ffff41aa399 in KApplication::KApplication(bool) () from /usr/lib/libkdeui.so.5
#7  0x000000000040892a in KDevelopApplication (argc=<value optimized out>, argv=0x7fffffffe478)
    at /tmp/yaourt-tmp-peterix/aur-kdevelop-git/src/kdevelop/app/main.cpp:76
#8  main (argc=<value optimized out>, argv=0x7fffffffe478) at /tmp/yaourt-tmp-peterix/aur-kdevelop-git/src/kdevelop/app/main.cpp:210
Comment 1 Milian Wolff 2011-01-06 12:06:31 UTC
seems to be a kdelibs issue, anyone can tell me what's going on here? Also note that I cannot reproduce the KGlobal::locale::Warning, hence have no idea on how to fix it...
Comment 2 Michael Pyne 2011-01-07 01:23:52 UTC
It would be very difficult to diagnose what causing the crash (even with the more-helpful Valgrind output) without debugging symbols being available for at least libkdecore.so.5. Most distributions allow you to install these symbols separately with -dbg packages.

Valgrind itself seems to indicate that KDevelop is trying to recover an old session, so the reporter might also want to see about clearing out some of the session directories mentioned in the Valgrind output, as long as those sessions weren't holding something useful, and then starting up KDevelop after that is done.
Comment 3 Petr Mrázek 2011-01-07 18:48:33 UTC
OK. I rebuilt kdelibs with debug symbols and have an updated backtrace. I think I also managed to remove all the config files and session data, so the updated valgrind output should be better.

GDB:
Starting program: /usr/bin/kdevelop 
[Thread debugging using libthread_db enabled]
KGlobal::locale::Warning your global KLocale is being recreated with a valid main component instead of a fake component, this usually means you tried to call i18n related functions before your main component was created. You should not do that since it most likely will not work 

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff64f32dc in QString::append(QString const&) () from /usr/lib/libQtCore.so.4
(gdb) bt
#0  0x00007ffff64f32dc in QString::append(QString const&) () from /usr/lib/libQtCore.so.4
#1  0x00007ffff7af4ae6 in operator+= (languages=..., catalogs=...) at /usr/include/QtCore/qstring.h:281
#2  operator+ (languages=..., catalogs=...) at /usr/include/QtCore/qstring.h:1024
#3  KLocalizedStringPrivate::notifyCatalogsUpdated (languages=..., catalogs=...)
    at /home/peterix/kdelibs/src/kdelibs-4.5.95/kdecore/localization/klocalizedstring.cpp:998
#4  0x00007ffff7aec071 in KLocalePrivate::updateCatalogs (this=0x687810)
    at /home/peterix/kdelibs/src/kdelibs-4.5.95/kdecore/localization/klocale_kde.cpp:846
#5  0x00007ffff7aeb621 in KLocalePrivate::setActiveCatalog (this=0x687810, catalog=<value optimized out>)
    at /home/peterix/kdelibs/src/kdelibs-4.5.95/kdecore/localization/klocale_kde.cpp:875
#6  0x00007ffff7a5ff13 in KGlobal::setActiveComponent (c=...) at /home/peterix/kdelibs/src/kdelibs-4.5.95/kdecore/kernel/kglobal.cpp:232
#7  0x00007ffff7a62273 in KComponentData::KComponentData (this=0x707f98, aboutData=0x7fffffffe140, 
    registerAsMain=KComponentData::RegisterAsMainComponent)
    at /home/peterix/kdelibs/src/kdelibs-4.5.95/kdecore/kernel/kcomponentdata.cpp:101
#8  0x00007ffff6d82399 in KApplicationPrivate (this=0x7fffffffc580, GUIenabled=true)
    at /home/peterix/kdelibs/src/kdelibs-4.5.95/kdeui/kernel/kapplication.cpp:191
#9  KApplication::KApplication (this=0x7fffffffc580, GUIenabled=true)
    at /home/peterix/kdelibs/src/kdelibs-4.5.95/kdeui/kernel/kapplication.cpp:346
#10 0x00000000004082b2 in KDevelopApplication (argc=<value optimized out>, argv=0x7fffffffe478)
    at /home/peterix/kdevelop-git/src/kdevelop/app/main.cpp:76
#11 main (argc=<value optimized out>, argv=0x7fffffffe478) at /home/peterix/kdevelop-git/src/kdevelop/app/main.cpp:210
Comment 4 Petr Mrázek 2011-01-07 18:50:05 UTC
Created attachment 55706 [details]
Valgrind output from successful start

This time without user settings/sessions present.
Comment 5 Petr Mrázek 2011-01-07 23:03:03 UTC
OK, found out what's happening.

A long time ago, KDE had the Kiosk framework, which allowed admins to set up some unchangeable KDE settings for users/groups. It's deeply integrated into the application startup. Loading configuration into KConfig, KGlobal, KStandardDirs and the like. It's mostly unused and badly maintained and my guess is that somewhere between KDE 4.5 and KDE 4.6, it got broken even more than it already was.
KDevelop is for some reason different enough from the usual KDE apps. Maybe it's the lock used in main(). I had many problems with Kiosk and the order in which things are initialized during application startup before.
So, it's a kdelibs bug in KStandardDirs and possibly other related classes, because this didn't happen with KDE 4.5.

This is the strace output right before the crash that gave it away:
lstat("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/usr/share", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0
lstat("/usr/share/locale", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/home/peterix", {st_mode=S_IFDIR|0700, st_size=45056, ...}) = 0
lstat("/home/peterix/.kde4", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
lstat("/home/peterix/.kde4/share", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
lstat("/home/peterix/.kde4/share/locale", 0x7fffce9f7650) = -1 ENOENT (No such file or directory)
access("/home/peterix/.kde4/share/locale/", R_OK) = -1 ENOENT (No such file or directory)
access("/home/peterix/.kde4/share/", R_OK) = 0
stat("/home/peterix/.kde4/share/", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
lstat("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/home/peterix", {st_mode=S_IFDIR|0700, st_size=45056, ...}) = 0
lstat("/home/peterix/.kde4", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
lstat("/home/peterix/.kde4/share", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
lstat("/etc", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0
lstat("/etc/kde-profile", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/etc/kde-profile/profile1", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/etc/kde-profile/profile1/share", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/etc/kde-profile/profile1/share/locale", 0x7fffce9f7650) = -1 ENOENT (No such file or directory)
access("/etc/kde-profile/profile1/share/locale/", R_OK) = -1 ENOENT (No such file or directory)
access("/etc/kde-profile/profile1/share/", R_OK) = 0
stat("/etc/kde-profile/profile1/share/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/etc", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0
lstat("/etc/kde-profile", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/etc/kde-profile/profile1", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/etc/kde-profile/profile1/share", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/etc/kde-profile/profile1/share/locale", 0x116fc68) = -1 ENOENT (No such file or directory)
lstat("/etc/kde-profile/profile1/share/locale", 0x7fffce9f86d0) = -1 ENOENT (No such file or directory)
stat("/usr/share/locale", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access("/home/peterix/.kde4/share/locale/en_US/LC_SCRIPTS/kdecalendarsystems/kdecalendarsystems.js", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/locale/en_US/LC_SCRIPTS/kdecalendarsystems/kdecalendarsystems.js", R_OK) = -1 ENOENT (No such file or directory)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Segmentation fault

According to valgrind, problems start with KStandardDirs::addCustomized and KStandardDirs::lookupProfiles.

Way to replicate the valgrind output:
1. Create files named /etc/kde4rc and /etc/kde-user-profile.
/etc/kde4rc should contain this:
[Directories]
userProfileMapFile=/etc/kde-user-profile

Alternatively, you can use the KioskTool application from KDE playground to set up proper Kiosk profiles.
2. Run kdevelop and watch the fireworks.
Comment 6 Andrew Crouthamel 2018-10-29 22:30:49 UTC
Dear Bug Submitter,

This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond.

Thank you for helping us make KDE software even better for everyone!
Comment 7 Bug Janitor Service 2018-11-13 14:29:45 UTC
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!
Comment 8 Petr Mrázek 2018-11-13 21:33:55 UTC
I barely remember this and I don't think it is relevant anymore.


Anyway, for reference:
https://userbase.kde.org/KDE_System_Administration/Kiosk/Introduction#Introduction

```
Once the reader understands how the Kiosk framework actually works through KDE's configuration files, we will discuss the Kiosk Admin Tool for those that prefer a GUI interface. This tool also allows administrators to more easily set-up Kiosk profiles and assign them system wide, per-user or per-group.
```

The tool is most likely dead. I tried to get it into some sort of decent shape around the time I reported this.
I suspect that since then, the buggy parts (support for Kiosk profiles in KStandardDirs, along with KStandardDirs) just got ripped out.

The above linked article also probably needs to be fact-checked.
Comment 9 Bug Janitor Service 2018-11-28 04:45:56 UTC
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!