- User Since
- Jun 3 2017, 7:27 PM (102 w, 2 d)
Sun, May 12
- apply comments by @asemke
Sun, May 5
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
Sat, May 4
Mar 31 2019
Would you accept now @apol?
This will override 5d28eaaf9041 (fixing the same bug), but I'll apply it anyway.
Feb 28 2019
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.
Feb 27 2019
Feb 26 2019
Feb 25 2019
- add comment
Feb 24 2019
A backtrace where it gets stuck in the destructor of QApplication.
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>
Feb 22 2019
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
Feb 9 2019
Feb 5 2019
Feb 3 2019
Jan 30 2019
- re-insert check for existing hosts
Jan 27 2019
- suppose that casting is possible, add ifdef
Jan 26 2019
- switch (fix) raiseDockSetupConnect and raiseDockSetup
If I had known in advance...
- use enum to identify AbstractAspects and use it throughout the project
Jan 25 2019
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.
Jan 23 2019
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.
Jan 20 2019
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).
Jan 17 2019
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
Jan 16 2019
- 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.
please explicitly mark all handled issues as done - you'll notice on the way that you didn't address some of them.
- use debuggee pid instead of DrKonqi pid for socket name
- make sure to read/write all bytes from/to socket
- unlink old sockets before binding
- remove superfluous EAGAIN check
- use debuggee pid instead of DrKonqi pid for socket name
- fix comments
- use poll instead of select
- set ptracer pid and poll for request for the directly started DrKonqi as well and make the ifdef-section more readable
- replace bogus perror
- rename queryPtrace to setPtracer
- add a kdeinit option in crashtest
Jan 15 2019
Actually, by using KCrash::setFlags(KCrash::KeepFDs) in KDevelop, so preventing the closing of all FDs, the problem is fixed(?) as well.
But I think, that the situation should not appear, even for a "misconfigured" debuggee.
Actually the problem is about joining threads at the end of main(). After being stuck and kill -SIGSTOP $(pidof kdevelop), DrKonqi turns out to be here:
#0 0x00007fbf18adbf6d in __pthread_timedjoin_ex () from /usr/lib/libpthread.so.0 #1 0x00007fbf0aee0a01 in ?? () from /usr/lib/dri/i965_dri.so #2 0x00007fbf0aee1299 in ?? () from /usr/lib/dri/i965_dri.so #3 0x00007fbf0aedc76a in ?? () from /usr/lib/dri/i965_dri.so --Type <RET> for more, q to quit, c to continue without paging--c #4 0x00007fbf0ae66374 in ?? () from /usr/lib/dri/i965_dri.so #5 0x00007fbf0aed83ff in ?? () from /usr/lib/dri/i965_dri.so #6 0x00007fbf0bd4b04c in ?? () from /usr/lib/libGLX_mesa.so.0 #7 0x00007fbf0bd37822 in ?? () from /usr/lib/libGLX_mesa.so.0 #8 0x00007fbf0bd378a9 in ?? () from /usr/lib/libGLX_mesa.so.0 #9 0x00007fbf0bd379fe in ?? () from /usr/lib/libGLX_mesa.so.0 #10 0x00007fbf18d893e2 in XCloseDisplay () from /usr/lib/libX11.so.6 #11 0x00007fbf144b8fe2 in ?? () from /usr/lib/libQt5XcbQpa.so.5 #12 0x00007fbf1448e33a in QXcbConnection::~QXcbConnection() () from /usr/lib/libQt5XcbQpa.so.5 #13 0x00007fbf1448f5f7 in QXcbIntegration::~QXcbIntegration() () from /usr/lib/libQt5XcbQpa.so.5 #14 0x00007fbf1448f6fa in QXcbIntegration::~QXcbIntegration() () from /usr/lib/libQt5XcbQpa.so.5 #15 0x00007fbf1a0c5f29 in QGuiApplicationPrivate::~QGuiApplicationPrivate() () from /usr/lib/libQt5Gui.so.5 #16 0x00007fbf1a6c370a in QApplicationPrivate::~QApplicationPrivate() () from /usr/lib/libQt5Widgets.so.5 #17 0x00007fbf19d2e1cf in QObject::~QObject() () from /usr/lib/libQt5Core.so.5 #18 0x00007fbf19cfed10 in QCoreApplication::~QCoreApplication() () from /usr/lib/libQt5Core.so.5 #19 0x00007fbf1a6c5852 in QApplication::~QApplication() () from /usr/lib/libQt5Widgets.so.5 #20 0x0000558afb850900 in main (argc=<optimized out>, argv=<optimized out>) at /home/christoph/Software/kde/kde/workspace/drkonqi/src/main.cpp:148
Jan 14 2019
Jan 13 2019
Jan 10 2019
In my opinion this should be committed, since it fixes a few crashes next to improving the file mode identification.