Bug 331784

Please add the backtrace for the crash. For more information, please see http://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports

I had a look at the link that was provided about generating a useful crash report, but there is literally nothing there that helps the situation. I set ulimit -c unlimited, but no core is generated. so I did the following:
gdb kded4
(gdb) run
Starting program: /usr/bin/kded4 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
gobject.py: gdb was not built with custom backtrace support, disabling.
QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.
QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.
kded(25363) ColorD::connectToDisplay: RandR extension missing 
kded(25363) ColorD::ColorD: Failed to connect to DISPLAY and get the needed resources 
Xlib:  extension "RANDR" missing on display ":0".
Xlib:  extension "RANDR" missing on display ":0".
Can't get XRandR version 
kded4: Fatal IO error: client killed
kded(25353): Communication problem with  "kded" , it probably crashed. 
Error message was:  "org.freedesktop.DBus.Error.NoReply" : " "Message did not receive a reply (timeout by message bus)" " 

[Inferior 1 (process 25353) exited with code 0377]
(gdb) bt
No stack.
(gdb) info inferiors
  Num  Description       Executable        
* 1    <null>            /usr/bin/kded4    
(gdb) inferior 1
[Switching to inferior 1 [<null>] (/usr/bin/kded4)]
(gdb) bt
No stack.
(gdb)

So I ran a trace on the inferior and the last system call it makes is exit_group(1), so I added a trap:

(gdb) catch syscall exit_group
Catchpoint 1 (syscall 'exit_group' [231])
(gdb) run
<same output as last run with exception of pid number>
Catchpoint 1 (call to syscall exit_group), 0x00007ffff78c4f69 in __GI__exit (status=status@entry=255) at ../sysdeps/unix/sysv/linux/_exit.c:32
32      ../sysdeps/unix/sysv/linux/_exit.c: No such file or directory.
(gdb) bt
#0  0x00007ffff78c4f69 in __GI__exit (status=status@entry=255) at ../sysdeps/unix/sysv/linux/_exit.c:32
#1  0x00007ffff783f4cb in __run_exit_handlers (status=255, listp=<optimized out>, run_list_atexit=run_list_atexit@entry=true) at exit.c:97
#2  0x00007ffff783f555 in __GI_exit (status=<optimized out>) at exit.c:104
#3  0x00007ffff70af1ba in KUniqueApplication::start (flags=...) at ../../kdeui/kernel/kuniqueapplication.cpp:183
#4  0x00007ffff70afa13 in KUniqueApplication::start () at ../../kdeui/kernel/kuniqueapplication.cpp:110
#5  0x00007ffff7bd35aa in kdemain (argc=1, argv=0x7fffffffde58) at ../../kded/kded.cpp:893
#6  0x00007ffff7824ec5 in __libc_start_main (main=0x4006d0 <main(int, char**)>, argc=1, argv=0x7fffffffde58, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, 
    stack_end=0x7fffffffde48) at libc-start.c:285
#7  0x00000000004006fe in _start ()
(gdb)


Still, nothing of use...
This explains the absence of a core file, it looks like kded4 hit a return, not a crash.
How do I debug this one?

Thanks for your information.

To further debug this issue, you could try disabling some kded modules, to find out which one causes the crash. Probable candidates are anything that has "screen/display/randr" or "color" management in its name.

For more information, please see http://kdepepo.wordpress.com/2011/05/11/troubleshooting-kded4-bugs/

(In reply to comment #3)
> Thanks for your information.
> 
> To further debug this issue, you could try disabling some kded modules, to
> find out which one causes the crash. Probable candidates are anything that
> has "screen/display/randr" or "color" management in its name.
> 
> For more information, please see
> http://kdepepo.wordpress.com/2011/05/11/troubleshooting-kded4-bugs/

Thank you, that was link very helpful. It would sure be nice if that information was included in the documentation for kded4. I read the man pages about kded4 some time ago and it simply does not provide enough information for me to understand what it does. I have worked with bits and pieces of KDE from time to time, but I never got involved with kded4 enough to understand how it works, that document made it very clear what is going on. It is clear that the issue is not kded4, it is the module kded_kscreen.so version 1.0.2.1 (tagged as 2.0~rc1really1.3.2 in the package manager).
I have also found some warnings in kded_bluedevil.so.
Now that I have determined where the issues are, how do I go about debugging a specific plugin for kded4?
Should I close this bug and open a new one(s) that are specific to the modules or should I continue with posting debugging information in this bug since kded4 is the parent/system?
I changed the priority of this bug to 'normal' because I have a work-around now.

I have reassigned this bug to kscreen developers; if they cannot reproduce, they might ask you for further information.

Regarding the bluedevil warnings, please report them separately for solid/bluetooth.

I have the same issue with kded, which I initially experienced with Okular, as reported https://bugs.kde.org/show_bug.cgi?id=334088

I have the same issue, however I have it on Slackware64 14.1 running KDE 4.10.5, so this is not a Ubuntu specific issue.

To reproduce the problem:

Attach multiple monitors, so that you can enable xinerama, which will disable randr. Log out, log back in.

To mask the problem, disable xinerama (making the multiple monitors functionally useless), log out and back in.

Consequential problems include System Settings -> Startup and Shutdown -> Service Manager being greyed out and producing a pop-up error:
    Unable to contact KDED.
Hence, to make changes to Service Manager settings, you have to turn off xinerama, log out and in again, make the changes, turn xinerama back on then log out and in again.

Doing this, I reduced the problem to KScreen 2. With it disabled and everything else enabled, kded runs.

Yeah, that definitely looks like a KScreen 2 problem. I can reproduce this with Okular as well. Using openSUSE Factory packages (4.13.0), KScreen crashes every time I try to view a document:

#6  QHash (other=<error reading variable: Cannot access memory at address 0x10>, this=0x7fffd7af80a0, this@entry=0x7fffd7af7fd0) at /usr/include/QtCore/qhash.h:282
#7  KScreen::Config::outputs (this=0x0) at /usr/src/debug/libkscreen-1.0.3/src/config.cpp:220
#8  0x00007f93507af51f in Okular::Utils::realDpi (widgetOnScreen=0xe86080) at /usr/src/debug/okular-4.13.0/core/utils.cpp:103
#9  0x00007f935078a1eb in Okular::DocumentPrivate::openDocumentInternal (this=0xe80120, offer=..., isstdin=isstdin@entry=false, docFile=..., filedata=...) at /usr/src/debug/okular-4.13.0/core/document.cpp:939
#10 0x00007f935078a855 in Okular::Document::openDocument (this=0xc72bd0, docFile=..., url=..., _mime=...) at /usr/src/debug/okular-4.13.0/core/document.cpp:2225
#11 0x00007f9350a524fc in Okular::Part::openFile (this=0xe25ad0) at /usr/src/debug/okular-4.13.0/part.cpp:1244
#12 0x00007f9361a1bfa7 in KParts::ReadOnlyPartPrivate::openLocalFile (this=this@entry=0xe25da0) at /usr/src/debug/kdelibs-4.13.0/kparts/part.cpp:591
#13 0x00007f9361a1d58e in KParts::ReadOnlyPart::openUrl (this=this@entry=0xe25ad0, url=...) at /usr/src/debug/kdelibs-4.13.0/kparts/part.cpp:555
#14 0x00007f9350a4784b in Okular::Part::openUrl (this=0xe25ad0, _url=...) at /usr/src/debug/okular-4.13.0/part.cpp:1394
#15 0x000000000040fad7 in Shell::openUrl (this=this@entry=0xd8d5a0, url=...) at /usr/src/debug/okular-4.13.0/shell/shell.cpp:246
#16 0x000000000040ff6e in Shell::openDocument (this=this@entry=0xd8d5a0, doc=...) at /usr/src/debug/okular-4.13.0/shell/shell.cpp:186
#17 0x000000000040a78a in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/okular-4.13.0/shell/main.cpp:163

There’s a problem with the old (non-XCB) XRandR backend (backends/xrandr/xrandr.cpp):

XRRQueryExtension(s_display, &s_randrBase, &s_randrError);

That line always triggers “Fatal IO error: client killed”. s_display appears to be valid, though.
In fact, it seems like calling any of the XRR-prefixed API functions does this.

And without a valid config, i.e. no working backends since the Fake one is ignored, libkscreen (current git master) still crashes with that same null pointer dereference mentioned in my previous post. This is bad.

Oh well, excuse me for being a terrible whiny backseat developer, but I’ve got to get this out of my system before I can go to bed. I am seriously pissed off. This shit right here is just another example of what’s been going so horribly wrong with KDE over the past few years I’ve been watching it. You’re doing too much of a “good thing”. Sprinkling modules, agents, backends and parts everywhere ends up being a terrible idea more often than not. You should seriously stop doing this with everything you come up with and ask yourselves whether you actually need it.

Why does something as simple as this display management library have its backends in separate .so files? How does this make any sense at all? I simply don’t see what justifies such a design because it seems needlessly complicated and error-prone, not to mention utterly retarded to me. For each platform (X11, Wayland, Windows, OS X), there only ever has to be one single supported way to do this. We know for sure that the XRandR extension is for X11 and not for Wayland. We know that if for some reason the XRandR backend does not work while running on an X11 system, there is absolutely no point in trying any of the remaining backends. So why are we using this “throw shit at the wall and see what sticks” approach here? Why are we trying every available backend until we find one that claims to provide a valid config and crash the user if we didn’t, when we could just be doing the right thing from the start?

Don’t get me wrong. I like KDE, and I know there’s a bunch of people putting a lot of time and effort into it. I don’t think anything could replace Dolphin, Konsole, KMail and Konqueror for me. But this. Fucking this. It’s incomprehensible.

I realized that I have not left instructions that might help others as a temporary work around until kscreen is fixed. It breaks for sure if you have RANDR disabled, so the only way that I have been able to use my machine is to disable it. I did this by renaming the service file, so kscreen will not get loaded.
The service files are in:
/usr/share/kde4/services/kded
There, you will find a file called kscreen.desktop
You can move it to something like kscreen.desktop.disabled
-Neil-

You can also set the environment variable KSCREEN_BACKEND=Fake (since this bug also affects applications like Okular).

> Why does something as simple as this display management library have its backends in separate .so files?

Simply because you do not want both Wayland and X11 libraries linked into the libkscreen code. By dynamically loading a plugin, you minimize runtime dependencies.

(In reply to comment #13)
You load the monstrosity called Qt (with QtCore, QJSON, QDBus, QtNetwork, QtXml, all of which only get larger with Qt5) along with kdecore but worry about a runtime dependency on a tiny piece of Wayland/XCB libs? :D

Not to mention that with the current approach, you will end up blindly loading those anyway.

Can anybody test with libkscreen 1.0.4? I similar bug has been fixed in there already.

(In reply to comment #16)
Unfortunately still crashes (see comment #9).

Reopening based on comment #17.

A patch for this available at https://git.reviewboard.kde.org/r/119547/

Git commit b8bf84863aef55f05fb770a818c8a410e156049b by Albert Astals Cid.
Committed on 03/08/2014 at 00:18.
Pushed by aacid into branch 'master'.

Use a xcb private connection to query for xrandr version

REVIEW: 119547

M  +2    -0    backends/xrandr/CMakeLists.txt
M  +23   -11   backends/xrandr/xrandr.cpp
M  +12   -4    backends/xrandr1.1/wrapper.h
M  +3    -1    backends/xrandr1.1/xrandr11.cpp

http://commits.kde.org/libkscreen/b8bf84863aef55f05fb770a818c8a410e156049b

I can confirm that the libkscreen 1.05 pushed yesterday fixes the problem.