I recently installed KDE 4.3 (on Arch Linux), and every time my screen saver is about to kick in I get a dialog box warning me that KDE Screen Locker (kscreenlocker) has crashed with a segmentation fault.

I tried submitting a crash report, but the crash reporting assistant warns me that "this crash information is not useful". I followed their link on how to create useful crash reports, but there was nothing specific to my distribution. I did install gdb, in case the crash assistant would somehow use that, but it doesn't seem to have made a difference.

So I guess my question is twofold: first, does anyone happen to know of a way to fix the crash--or if this is more widespread than just me? And second, what debugging tools do I need to install in Arch for the crash assistant to generate useful data?

Please install the debugging packages for Qt, KDELibs and KDEBase ( all variants )

Sorry for the delay in replying: I hadn't yet had the time to switch my main machine over to Arch (and KDE), and had just installed it on an extra drive for testing.

Anyway, I looked for debugging packages for Qt, KDElibs and KDEbase, but the closest I could find was the kde-meta-kdesdk meta package, which has a bunch of development tools, including some for debugging (see here for what it includes). And unfortunately, that doesn't seem to have helped.

The only other suggestion I'm seeing on the "How to create useful crash reports" page is to compile KDE from source, which I am not up to doing. Or would I just need to compile kscreenlocker with some debugging flags enabled? That, I could probably do.

EDIT: I found this page, which is Arch-specific, but I can't get enough information from the Crash Reporting Assistant to follow the steps. That is, it doesn't tell me what libraries aren't supplying debugging symbols. When I hit "reload crash information" it flashes by too quickly, and the summary that the crash assistant shows doesn't have enough information. How do I get the raw crash information (a version that hasn't had stuff stripped out by the crash reporting assistant)?

You need to attach "gdb" using Konsole to the process ID that crashed. This PID is shown on the Crash Handler Assistant window.

Code: Select all

gdb --attach <pid>

Okay, I think I got this figured out. (Thanks for the lead!) I tried attaching gdb the way you said, but my version of it doesn't seem to recognize that parameter. So I used ps -Af | grep kscreenlocker to find the executable and then ran gdb /usr/lib/kde4/libexec/kscreenlocker. I started it ("start") and got the following backtrace:

Code: Select all

Starting program: /usr/lib/kde4/libexec/kscreenlocker
(no debugging symbols found)                         
(no debugging symbols found)                         
(no debugging symbols found)                         
(no debugging symbols found)                         
(no debugging symbols found)                         
(no debugging symbols found)                         
[Thread debugging using libthread_db enabled]         
[New Thread 0xb629e940 (LWP 16225)]                   
Xlib:  extension "XFree86-Misc" missing on display ":0.0".
X Error: BadMatch (invalid parameter attributes) 8       
  Major opcode: 1 (X_CreateWindow)                       
  Resource id:  0xe4                                     
X Error: BadWindow (invalid Window parameter) 3           
  Major opcode: 3 (X_GetWindowAttributes)                 
  Resource id:  0x4c0001f                                 
X Error: BadWindow (invalid Window parameter) 3           
  Major opcode: 2 (X_ChangeWindowAttributes)             
  Resource id:  0x4c0001f                                 
X Error: BadWindow (invalid Window parameter) 3           
  Major opcode: 2 (X_ChangeWindowAttributes)             
  Resource id:  0x4c0001f                                 
X Error: BadWindow (invalid Window parameter) 3           
  Major opcode: 20 (X_GetProperty)                       
  Resource id:  0x4c0001f                                 
X Error: BadWindow (invalid Window parameter) 3           
  Major opcode: 18 (X_ChangeProperty)                     
  Resource id:  0x4c0001f                                 
X Error: BadWindow (invalid Window parameter) 3           
  Major opcode: 18 (X_ChangeProperty)                     
  Resource id:  0x4c0001f                                 
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 18 (X_ChangeProperty)
  Resource id:  0x4c0001f
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 2 (X_ChangeWindowAttributes)
  Resource id:  0x4c0001f
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 2 (X_ChangeWindowAttributes)
  Resource id:  0x4c0001f
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 2 (X_ChangeWindowAttributes)
  Resource id:  0x4c0001f
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 18 (X_ChangeProperty)
  Resource id:  0x4c0001f
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 20 (X_GetProperty)
  Resource id:  0x4c0001f
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 18 (X_ChangeProperty)
  Resource id:  0x4c0001f
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 18 (X_ChangeProperty)
  Resource id:  0x4c0001f
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 20 (X_GetProperty)
  Resource id:  0x4c0001f
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 19 (X_DeleteProperty)
  Resource id:  0x4c0001f
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 20 (X_GetProperty)
  Resource id:  0x4c0001f
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 19 (X_DeleteProperty)
  Resource id:  0x4c0001f
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 2 (X_ChangeWindowAttributes)
  Resource id:  0x4c0001f
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 12 (X_ConfigureWindow)
  Resource id:  0x4c0001f
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 15 (X_QueryTree)
  Resource id:  0x4c0001f

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb629e940 (LWP 16225)]
0xb6988d11 in free () from /lib/libc.so.6

Is that enough to help? Unfortunately, this was showing up in the terminal, not the crash reporting assistant, so I don't know what the best way to report it is (assuming there's a better place than here).

EDIT: I started to report this bug to the KDE bug tracker (bugs.kde.org), but was stymied when I was prompted to select the application I was reporting a bug for. kscreenlocker isn't listed, and I don't know what else to say it's part of. Ideas? (Once I know what to report it as, I'll finish up the bug report.)

Try "kscreensaver" instead, as kscreenlocker is part of it. You can use "bt" at the gdb prompt to get a backtrace. Make sure you have the Qt / KDE debugging symbols installed.

bcooksley wrote:Try "kscreensaver" instead, as kscreenlocker is part of it. You can use "bt" at the gdb prompt to get a backtrace. Make sure you have the Qt / KDE debugging symbols installed.

Thank you for the help. How do I install the debugging symbols? (As I'm sure you can tell, I'm unfamiliar with the debugging process, but I'm hoping to get enough information that someone can figure out what's happening.) Does this mean I should compile kscreensaver with debugging turned on?

Yes, you need to compile it using "RelWithDebInfo". Same for KDELibs.

Okay, I finally took the time to compile kdelibs and kscreensaver with RelWithDebInfo turned on. And...I got exactly the same information from gdb. (The crash handler also still told me that "This information is not useful.")

I'm not sure why this didn't work. I changed the PKGBUILD file (which Arch uses to automate builds) so that the DCMAKE_BUILD_TYPE flag passed to cmake was RelWithDebInfo rather than Release (which it was originally). Does anyone know if this was the wrong way to do it, somehow? (Maybe I should ask over on the Arch forums for help with this particular problem?)

I did uninstall the versions of kdelibs and kdescreensaver that were originally installed from the repositories before installing the new versions, so it's definitely using the compiled versions now.

Does Qt have debugging symbols enabled? ( Not Debug mode, but it needs the symbols enabled, which it does by default )

Alas, I don't know how to check. I did search the repositories for anything related to Qt and debugging or symbols, but couldn't find any packages related to that. (If it's a compile-time option, I don't know how to check that either.)

Unfortunately then the crash appears to be so severe that the backtrace is corrupted.

Hi,

If you have an nvidia card this is an archlinux bug.

I have the same problem and found the solution.

The nvidia-utils package was not correctly upgraded between
185.18.* -> 190.42-1

run

sudo rm /usr/lib/tls/libnvidia-tls.so.185.*
sudo pacman -S nvidia-utils nvidia (just in case)

Hope this helps.

Alas, I don't have nvidia--my laptop used integrated Intel graphics (the 945GM, I believe).

However, this is an interesting track--I wonder if the drivers for it are either out of date or incorrectly configured (my fault). I'll see if I can track anything down...