I can no longer reproduce the deadlock, so I'll abandon this.

Thanks for your review. It was the last in a series of patches and I'll try to advertise the whole "Debug your KDE application with KDevelop"-feature somewhere.

In D11234#492200, @sitter wrote:

Could you explain your thinking behind the adjustSize call please? The way I see it the window should scale up as necessary if the size hints are properly set (which they should be on master).

• more style fixes
• do not adjustSize after adding the button, since that is redundant now

Thanks for looking into this :D

• Fix code style.
• Save state of the debug button in a member variable.
• Resize the dialog after inserting/removing the debug button.

Rebase to current master

Rebase to current master

• apply comments by @asemke

In D19420#460766, @apol wrote:

Looks good to me, have you checked that it's now not breaking what @broulik found?

Instead of an enum inside AbstractAspect, there now is an enum class outside of the class. This way, the items can be named properly.

• Rearrange AbstractAspect type enums
• Transform AspectType enum into global enum class, rename items

In D19420#441163, @croick wrote:

Would you accept now @apol?

Would you accept now @apol?

This will override 5d28eaaf9041 (fixing the same bug), but I'll apply it anyway.

In D19420#422043, @apol wrote:

With a unit test it would be much easier to accept the patch ;)

add unit test, reset bNeedHeader

Oh, sorry for that, I thought it would comply with how Z_OK and Z_STREAM_END are used and therefore be a trivial change.
I will create a bug report instead.

In D18245#418708, @thiago wrote:

I repeat: there's no indication in the backtrace that it is stuck. What's your evidence that it is? You wrote an application that shows nothing and never exits. Now it showed nothing and didn't exit. That's not stuck, that's the expected behaviour.

• add comment

A backtrace where it gets stuck in the destructor of QApplication.

In D18245#418656, @thiago wrote:

This last backtrace does not show anything stuck. Thread 1 was actively running, in fact (it's inside of malloc).

Also note your testcase has no window, since the widget is destroyed before app.exec().

The problem does not seem to be specific to DrKonqi. Once DrKonqi and KDevelop are stuck, any Qt program may have problems starting or quitting. A minimal example

#include <QApplication>
#include <QWidget>

I dug in the history of KCrash and realized, that closing all the file descriptors was introduced (7bbf112e5e97d40b9a4f9fdd167b064a1019843b) to make the X11 window disappear.
Later @ossi added the X11 FD explicitly (7ac326ddb05eec296fdfbebd86d0d1320e579063), but kept closing the FDs by default.

The following steps allow creating the backtraces. Simply attaching to KDevelop does not work, since that sends a SIGSTOP to all threads (and releases the dead lock). Attaching to DrKonqi after closing the dialog does not work since the process already is defunct:

• kill -SIGSEGV $(pidof kdevelop)
• raise DrKonqi dialog
• gdb -p $(pidof drkonqi), continue execution
• close DrKonqi dialog
• CTRL + C in gdb, which now is stuck
• kill -SIGSTOP $(pidof kdevelop), gdb reacts again, generate backtrace for DrKonqi
• gdb -p $(pidof kdevelop), generate backtrace for KDevelop

• re-insert check for existing hosts

• suppose that casting is possible, add ifdef

• switch (fix) raiseDockSetupConnect and raiseDockSetup

If I had known in advance...

• use enum to identify AbstractAspects and use it throughout the project

A few screenshots:

Do you think we should check for the version of Plasma to make a distinction between DrKonqi versions?
I think not, the Debug feature is not (yet) very popular, but I would like another opinion.

I still prefer my solution ;)

Ok, now I got it. After reading the YAMA doc again (more carefully) I realize that it really just is the parent that can be attached to the child by default and not the other way around.
I still wonder why I seem to recall that there was a working backtrace for the directly started DrKonqi in the tests, although the tracer was never set. Sorry about that.

the 3rd line is still wrong ...

Would you agree on such a change?
case "Worksheet"_hash: is still human-readable (compare to if (className == "Worksheet").
The very unlikely case of a hash collision would appear at compile time (if new dock widgets are introduced).
On the other hand the selection of the right dock is now more efficient than before.

So would you agree, that qobject_cast is not required, since the class name is checked anyway?
The result of the cast isn't checked anywhere, so one could just use static_cast (and simply take the first element in the list).

The dock looks like this:

• swap variable declaration

I think it's quite useful (see BUG 175362). Remaining threads remain quite busy otherwise, especially since KCrash is closing all file descriptors by default, which leads to a lot of polling of non-existant FDs in the background.
Maybe you would like to join the discussion in D18245 about this ;)

• invert debugger-debuggee hierarchy in comment

you got the parent-child ordering wrong in the commit message. ^^

• swap lines, declare array for response message where needed

• adjust warning and check for EINTR when polling

• emit warning if no socket is available

that sounds suspicious. i don't think the kernel's behavior did changed, and the process hierarchy presumably didn't, either. the right is handed down the ancestry, and that's irrespective of whether the tracer is a "natural" ancestor or the tracee, or was set via prctl(). maybe your sysctl settings simply changed?

• modify comment and remove check for EAGAIN

• change order and add comment to kdeinit option in crashtest
• add warning if debuggee does not respond as expected

read() and write() were assumed to work right away, I added a loop around.