I have been running 4.2 rc1, and found that several plasmoids caused plasma to crash. Naturally, I want to file a bug report. The problem is, I'm utterly failing to get enough useful information to file a bug report the devs can use. Here's the trouble:

- For starters, i can't figure out how to get a backtrace from plasma. I tried this:

Code: Select all

pkill plasma && gdb plasma |tee plasmatrace.txt


The problem is, after plasma finished loading, the original process exits. meaning I'm not getting a trace any longer.

- The second problem is, after I installed the debugging symbols, THE PROBLEM STOPPED. Which probably is enlightening for why the developers didn't notice it. What would cause a problem like this to stop if the debugging symbols are installed? And how do I get a meaningful crash report if it only crashes without them?

Any advice would be appreciated, I really want to see KDE get solid.

It could have been that a binary-incompatible plasmoid was updated when you installed the debugging symbols. What plasmoid was causing the crash?

The comic strip and the lcd weather; I didn't see any packages get installed other than the debugging symbols -- I'm a habitual dist-upgrader.

EDIT: lcd weather still crashes plasma, comic strip appears stable.

admoore wrote:The problem is, after plasma finished loading, the original process exits. meaning I'm not getting a trace any longer.

You can attach gdb to a running process using its --pid option

admoore wrote: - The second problem is, after I installed the debugging symbols, THE PROBLEM STOPPED. Which probably is enlightening for why the developers didn't notice it. What would cause a problem like this to stop if the debugging symbols are installed?

Such things can happen if memory is being accessed after it has been released.
In a debug build there is less optimization on memory management, so the previously used memory migth still be accessible and filled with suitable data. In a release build it can get overwritten faster thus causing a crash on the invalid access later on.

admoore wrote:And how do I get a meaningful crash report if it only crashes without them?

The only thing you can do then is to report that switching to a debug build hides the problem. The developer might then have other means to get useful information, e.g. by knowing how such things usually happen they could run the process through a memory access checking tool like valgrind.

admoore wrote:Any advice would be appreciated, I really want to see KDE get solid.

Thanks a lot for your efforts!

Cheers,
_

Thanks! I will see if I can get a bug report together.

EDIT: OK, when i open konsole and attach gdb to plasma's process, plasma locks up, so I can't replicate the problem. Sorry, I'm not very experienced with gdb, I've only used it a few times. Is there a better way to get a backtrace from a plasma crash?

Ok, man gdb. I hit "c" after attaching and plasma continues execution.... in a different thread. So no debug output. It just segfaults.

After the initial loadup, this is all I get:

Code: Select all

(gdb) c
Continuing.
[New Thread 0xa8bbeb90 (LWP 18171)]

Program received signal SIGSEGV, Segmentation fault.


Should I just file the bug anyway, or is that going to be useless?

Try

Code: Select all

gdb --args plasma --nofork


then type "run" at the prompt. When it crashes, type

Code: Select all

bt


NOTE: It's actually possible to log to a file in gdb - if you want to dump the bt to a log file, something like

Code: Select all

set logging plasma-crash.kcrash
bt
set logging off


instead of just bt should do the trick.

Thanks! I couldn't figure out the logging bit (it was set logging file plasma-whatever.kcrash, but the file didn't show up), but I just used tee and managed to get a copy of the backtrace.

I'll go ahead and file the bug; thanks again!

I would go ahead and file the bug with as much information as you have. Some developers will fling poo at you for it, but just fling it back.

Well, after all that, it turns out it was a QT bug that's fixed upstream. Oh well, it was educational anyway...

admoore wrote:Well, after all that, it turns out it was a QT bug that's fixed upstream. Oh well, it was educational anyway...

Yep, next time it will be nice and easy I wonder why DrKonqi wasn't triggered, though ... ?