Re: Review Request 121286: Adding support for lldb in DrKonqi (step 1)
On Nov. 29, 2014, 10:20 p.m., Pino Toscano wrote:
drkonqi/backtracegenerator.cpp, line 97
https://git.reviewboard.kde.org/r/121286/diff/3/?file=331098#file331098line97
Still hardcodes the debugger name; I'm not a drkonqui developer, so I
cannot tell you exactly what to do -- surely, not hardcoding a particular
debugger behaviour will be better anyway.
Ian Wadham wrote:
a) I think codeName() would be the appropriate method (see
drkonqi/debugger.h). The name() method gives you the translated name,
possibly in non-Latin characters.
b) FWIW there are at least two other places in this patch where lldb is
used, but gdb and kdbgwin are also already used at those places... :-) So
what is wrong with continuing the tradition?
c) Would adding something to the file drkonqi_globals.h be of any use?
d) I agree that adding a config file entry just for this case and an
extra method in debugger.* to access it would be an overkill.
a) I think codeName() would be the appropriate method (see
drkonqi/debugger.h). The name() method gives you the translated name,
possibly in non-Latin characters.
Yet another reason why hardcoding the backend name is problematic...
b) FWIW there are at least two other places in this patch where lldb is
used, but gdb and kdbgwin are also already used at those places... :-) So
what is wrong with continuing the tradition?
A factory method and the default value of the debugger configuration? Those are
ok for what they do.
c) Would adding something to the file drkonqi_globals.h be of any use?
Unrelated place.
d) I agree that adding a config file entry just for this case and an extra
method in debugger.* to access it would be an overkill.
I don't think adding a method to get a configuration for a behavior of a
debugger would be overkill; it seems like that's what `Debugger` is for, after
all. Otherwise, just add a method like:
```c++
QString Debugger::backendConfiguration(const QString key) const
{
if (!isValid() || !m_config-hasGroup(m_backend)) {
return false;
} else {
return m_config-group(m_backend).readEntry(key, QString());
}
}
```
so you can just query it to get a configuration you need.
- Pino
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121286/#review71100
---
On Nov. 29, 2014, 10:03 p.m., René J.V. Bertin wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121286/
---
(Updated Nov. 29, 2014, 10:03 p.m.)
Review request for KDE Software on Mac OS X and KDE Runtime.
Repository: kde-runtime
Description
---
DrKonqi currently lacks support for lldb, which means KDE users on recent OS
X versions cannot generate and submit post-mortem backtraces.
The patches in this RR introduce simple logic (based on *compile-time* OS
version detection) to select either gdb or lldb, as well as appropriate
lldbrc files.
This is the first step to be taken: determine when lldb should be launched,
and how (to obtain a backtrace).
Diffs
-
drkonqi/backtracegenerator.cpp 1107e11
drkonqi/data/debuggers/external/lldbrc PRE-CREATION
drkonqi/data/debuggers/internal/lldbrc PRE-CREATION
drkonqi/drkonqibackends.cpp 064d07d
drkonqi/parser/CMakeLists.txt d08d0d7
drkonqi/parser/backtraceparser.cpp 7f62c97
drkonqi/parser/backtraceparserlldb.h PRE-CREATION
drkonqi/parser/backtraceparserlldb.cpp PRE-CREATION
Diff: https://git.reviewboard.kde.org/r/121286/diff/
Testing
---
On OS X 10.9.4 with kdelibs git/4.14 .
Launching lldb works, as does the BatchCommand to obtain a backtrace; parsing
of that information will be tackled later.
The backtrace isn't particularly useful though, because it doesn't
(always/never/...?) display the location of the crash and steps leading up to
it, *presumably* because of an issue in the interaction between KDE's crash
reporter and lldb. This will need work...
```
Application: Kate (kate), signal: Segmentation fault: 11
(lldb) process attach --pid 88853
Process 88853 stopped
Executable module set to /opt/local/bin/kate.
Architecture set to: x86_64-apple-macosx.
(lldb) command source -s 0
'/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiB88857.tmp'
Executing commands in
'/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiB88857.tmp'.
(lldb) set set term-width 200
(lldb) set set interpreter.prompt-on-quit false
(lldb) thread info
thread #1: tid = 0x1bda48, 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4
+ 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
(lldb) bt all
*
Re: Review Request 121286: Adding support for lldb in DrKonqi (step 1)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121286/#review71117 --- drkonqi/backtracegenerator.cpp https://git.reviewboard.kde.org/r/121286/#comment49681 -setOpenMode(QIODevice::ReadOnly|.)? Why is this required, btw.? Does lldb wet itself if DrKonqi writes into it? - Thomas Lübking On Nov. 29, 2014, 10:03 nachm., René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121286/ --- (Updated Nov. 29, 2014, 10:03 nachm.) Review request for KDE Software on Mac OS X and KDE Runtime. Repository: kde-runtime Description --- DrKonqi currently lacks support for lldb, which means KDE users on recent OS X versions cannot generate and submit post-mortem backtraces. The patches in this RR introduce simple logic (based on *compile-time* OS version detection) to select either gdb or lldb, as well as appropriate lldbrc files. This is the first step to be taken: determine when lldb should be launched, and how (to obtain a backtrace). Diffs - drkonqi/backtracegenerator.cpp 1107e11 drkonqi/data/debuggers/external/lldbrc PRE-CREATION drkonqi/data/debuggers/internal/lldbrc PRE-CREATION drkonqi/drkonqibackends.cpp 064d07d drkonqi/parser/CMakeLists.txt d08d0d7 drkonqi/parser/backtraceparser.cpp 7f62c97 drkonqi/parser/backtraceparserlldb.h PRE-CREATION drkonqi/parser/backtraceparserlldb.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121286/diff/ Testing --- On OS X 10.9.4 with kdelibs git/4.14 . Launching lldb works, as does the BatchCommand to obtain a backtrace; parsing of that information will be tackled later. The backtrace isn't particularly useful though, because it doesn't (always/never/...?) display the location of the crash and steps leading up to it, *presumably* because of an issue in the interaction between KDE's crash reporter and lldb. This will need work... ``` Application: Kate (kate), signal: Segmentation fault: 11 (lldb) process attach --pid 88853 Process 88853 stopped Executable module set to /opt/local/bin/kate. Architecture set to: x86_64-apple-macosx. (lldb) command source -s 0 '/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiB88857.tmp' Executing commands in '/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiB88857.tmp'. (lldb) set set term-width 200 (lldb) set set interpreter.prompt-on-quit false (lldb) thread info thread #1: tid = 0x1bda48, 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP (lldb) bt all * thread #1: tid = 0x1bda48, 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8 frame #1: 0x00010272bc8e libkdeui.5.dylib`KCrash::startProcess(int, char const**, bool) [inlined] startProcessInternal(argc=unavailable, directly=unavailable) + 265 at kcrash.cpp:556 frame #2: 0x00010272bb85 libkdeui.5.dylib`KCrash::startProcess(argc=unavailable, argv=unavailable, waitAndExit=unavailable) + 21 at kcrash.cpp:538 frame #3: 0x00010272adb9 libkdeui.5.dylib`KCrash::defaultCrashHandler(sig=unavailable) + 1209 at kcrash.cpp:441 frame #4: 0x7fff8fe965aa libsystem_platform.dylib`_sigtramp + 26 frame #5: 0x7fff8a55c098 libobjc.A.dylib`objc_msgSend + 24 thread #2: tid = 0x1bda4b, 0x7fff8cb86662 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager' frame #0: 0x7fff8cb86662 libsystem_kernel.dylib`kevent64 + 10 frame #1: 0x7fff905a1421 libdispatch.dylib`_dispatch_mgr_invoke + 239 frame #2: 0x7fff905a1136 libdispatch.dylib`_dispatch_mgr_thread + 52 thread #3: tid = 0x1bda4c, 0x7fff8cb85e6a libsystem_kernel.dylib`__workq_kernreturn + 10 frame #0: 0x7fff8cb85e6a libsystem_kernel.dylib`__workq_kernreturn + 10 frame #1: 0x7fff8f5d6f08 libsystem_pthread.dylib`_pthread_wqthread + 330 frame #2: 0x7fff8f5d9fb9 libsystem_pthread.dylib`start_wqthread + 13 thread #4: tid = 0x1bda52, 0x7fff8cb85e6a libsystem_kernel.dylib`__workq_kernreturn + 10 frame #0: 0x7fff8cb85e6a libsystem_kernel.dylib`__workq_kernreturn + 10 frame #1: 0x7fff8f5d6f08 libsystem_pthread.dylib`_pthread_wqthread + 330 frame #2: 0x7fff8f5d9fb9 libsystem_pthread.dylib`start_wqthread + 13 thread #5: tid = 0x1bda75, 0x7fff8cb859aa libsystem_kernel.dylib`__select + 10, name = 'com.apple.CFSocket.private'
Re: Review Request 121286: Adding support for lldb in DrKonqi (step 1)
On Nov. 29, 2014, 11:20 p.m., Pino Toscano wrote:
drkonqi/drkonqibackends.cpp, line 175
https://git.reviewboard.kde.org/r/121286/diff/3/?file=331101#file331101line175
This macros won't be defined outside Mac, so please check for its
existency as well.
On the compilers I have experience with this evaluates to false f the token
isn't defined...
On Nov. 29, 2014, 11:20 p.m., Pino Toscano wrote:
drkonqi/parser/backtraceparser.cpp, line 204
https://git.reviewboard.kde.org/r/121286/diff/3/?file=331103#file331103line204
Most probably not needed?
No, not needed. But as the complexity of this code grows, so does the
computational cost if we do all checks, even those that are clearly irrelevant
or even in inappropriate (non MS Windows software might well have reasons to
define a function called WinMain).
Hence my suggestion above to group the checks per platform/OS. That could be
done in a single if statement, but it could of course also be
```
#ifdef Q_OS_MAC
if (/*...*/) {
return true;
}
#elif defined(Q_OS_WIN)
if (/*...*/) {
return true;
}
#elif defined(Q_OS_WHATEVER)
// ...
#else
// standard Unix/Linux
if (/*...*/) {
return true;
}
#endif
return false;
On Nov. 29, 2014, 11:20 p.m., Pino Toscano wrote:
drkonqi/parser/backtraceparser.cpp, line 206
https://git.reviewboard.kde.org/r/121286/diff/3/?file=331103#file331103line206
This does not need a regexp.
doh ...
- René J.V.
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121286/#review71100
---
On Nov. 29, 2014, 11:03 p.m., René J.V. Bertin wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121286/
---
(Updated Nov. 29, 2014, 11:03 p.m.)
Review request for KDE Software on Mac OS X and KDE Runtime.
Repository: kde-runtime
Description
---
DrKonqi currently lacks support for lldb, which means KDE users on recent OS
X versions cannot generate and submit post-mortem backtraces.
The patches in this RR introduce simple logic (based on *compile-time* OS
version detection) to select either gdb or lldb, as well as appropriate
lldbrc files.
This is the first step to be taken: determine when lldb should be launched,
and how (to obtain a backtrace).
Diffs
-
drkonqi/backtracegenerator.cpp 1107e11
drkonqi/data/debuggers/external/lldbrc PRE-CREATION
drkonqi/data/debuggers/internal/lldbrc PRE-CREATION
drkonqi/drkonqibackends.cpp 064d07d
drkonqi/parser/CMakeLists.txt d08d0d7
drkonqi/parser/backtraceparser.cpp 7f62c97
drkonqi/parser/backtraceparserlldb.h PRE-CREATION
drkonqi/parser/backtraceparserlldb.cpp PRE-CREATION
Diff: https://git.reviewboard.kde.org/r/121286/diff/
Testing
---
On OS X 10.9.4 with kdelibs git/4.14 .
Launching lldb works, as does the BatchCommand to obtain a backtrace; parsing
of that information will be tackled later.
The backtrace isn't particularly useful though, because it doesn't
(always/never/...?) display the location of the crash and steps leading up to
it, *presumably* because of an issue in the interaction between KDE's crash
reporter and lldb. This will need work...
```
Application: Kate (kate), signal: Segmentation fault: 11
(lldb) process attach --pid 88853
Process 88853 stopped
Executable module set to /opt/local/bin/kate.
Architecture set to: x86_64-apple-macosx.
(lldb) command source -s 0
'/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiB88857.tmp'
Executing commands in
'/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiB88857.tmp'.
(lldb) set set term-width 200
(lldb) set set interpreter.prompt-on-quit false
(lldb) thread info
thread #1: tid = 0x1bda48, 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4
+ 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
(lldb) bt all
* thread #1: tid = 0x1bda48, 0x7fff8cb85e20
libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop
reason = signal SIGSTOP
* frame #0: 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8
frame #1: 0x00010272bc8e libkdeui.5.dylib`KCrash::startProcess(int,
char const**, bool) [inlined] startProcessInternal(argc=unavailable,
directly=unavailable) + 265 at kcrash.cpp:556
frame #2: 0x00010272bb85
libkdeui.5.dylib`KCrash::startProcess(argc=unavailable, argv=unavailable,
waitAndExit=unavailable) + 21 at kcrash.cpp:538
frame #3: 0x00010272adb9
libkdeui.5.dylib`KCrash::defaultCrashHandler(sig=unavailable) + 1209 at
kcrash.cpp:441
frame #4: 0x7fff8fe965aa
Re: Review Request 121286: Adding support for lldb in DrKonqi (step 1)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121286/ --- (Updated Nov. 30, 2014, 8:53 p.m.) Review request for KDE Software on Mac OS X and KDE Runtime. Changes --- Includes fixes for the remaining open issues, and adds a generic Debugger::backendValueForParameter method that is used to read an ExecInputFile from lldbrc. With that parameter set to %tempfile, there is no more need to redirect from /dev/null . I asked about post-mortem debugging on the lldb-dev ML, here's the feedback I got from Jason Molenda: ``` The short backtrace in that discussion is a tricky one -- _sigtramp followed by objc_msgSend. Both of these can be difficult for the unwinder to backtrace out of (_sigtramp because the register context is saved out-of-band by the kernel and we rely on accurate eh_frame instructions to find it) and objc_msgSend because it is hand-written assembly with some hand-written eh_frame instructions that are accurate at many -- but not all -- points in the function. I have seen some edge cases on Mavericks (Mac OS X 10.10) where _sigtramp unwinding is not completely accurate. It's on my todo list to figure out what's going on there. If your process was at a location in objc_msgSend that did not have accurate eh_frame unwind descriptions, that would also account for this. I think it will be difficult to hit this backtrace again, it is likely to be rare. Your process of attaching and collecting information looks reasonable to me. I gather you're scraping the output of lldb for information about the crash. This can be a problem as the debugger output changes over time ... if I were writing a tool like this, I would probably write it in Python using the SB API that lldb supports. lldb is actually a debugger *library* and the lldb command line program is one client of that library (Xcode is another). You can write a Python script (or C++ program) that uses the library to attach to the process, iterate over the threads, print the backtrace information you want, etc. It's probably more work than you want to do right now but for long-term maintainability, it would be the way to go. ``` Repository: kde-runtime Description --- DrKonqi currently lacks support for lldb, which means KDE users on recent OS X versions cannot generate and submit post-mortem backtraces. The patches in this RR introduce simple logic (based on *compile-time* OS version detection) to select either gdb or lldb, as well as appropriate lldbrc files. This is the first step to be taken: determine when lldb should be launched, and how (to obtain a backtrace). Diffs (updated) - drkonqi/data/debuggers/external/lldbrc PRE-CREATION drkonqi/data/debuggers/internal/lldbrc PRE-CREATION drkonqi/debugger.h 1451397 drkonqi/backtracegenerator.cpp 1107e11 drkonqi/parser/backtraceparserlldb.h PRE-CREATION drkonqi/debugger.cpp 26ca338 drkonqi/drkonqibackends.cpp 064d07d drkonqi/parser/CMakeLists.txt d08d0d7 drkonqi/parser/backtraceparser.cpp 7f62c97 drkonqi/parser/backtraceparserlldb.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121286/diff/ Testing --- On OS X 10.9.4 with kdelibs git/4.14 . Launching lldb works, as does the BatchCommand to obtain a backtrace; parsing of that information will be tackled later. The backtrace isn't particularly useful though, because it doesn't (always/never/...?) display the location of the crash and steps leading up to it, *presumably* because of an issue in the interaction between KDE's crash reporter and lldb. This will need work... ``` Application: Kate (kate), signal: Segmentation fault: 11 (lldb) process attach --pid 88853 Process 88853 stopped Executable module set to /opt/local/bin/kate. Architecture set to: x86_64-apple-macosx. (lldb) command source -s 0 '/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiB88857.tmp' Executing commands in '/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiB88857.tmp'. (lldb) set set term-width 200 (lldb) set set interpreter.prompt-on-quit false (lldb) thread info thread #1: tid = 0x1bda48, 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP (lldb) bt all * thread #1: tid = 0x1bda48, 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8 frame #1: 0x00010272bc8e libkdeui.5.dylib`KCrash::startProcess(int, char const**, bool) [inlined] startProcessInternal(argc=unavailable, directly=unavailable) + 265 at kcrash.cpp:556 frame #2: 0x00010272bb85 libkdeui.5.dylib`KCrash::startProcess(argc=unavailable, argv=unavailable, waitAndExit=unavailable) + 21
Re: Review Request 121286: Adding support for lldb in DrKonqi (step 1)
On Nov. 29, 2014, 10:20 nachm., Pino Toscano wrote: drkonqi/drkonqibackends.cpp, line 175 https://git.reviewboard.kde.org/r/121286/diff/3/?file=331101#file331101line175 This macros won't be defined outside Mac, so please check for its existency as well. René J.V. Bertin wrote: On the compilers I have experience with this evaluates to false f the token isn't defined... undefined vars get a value of 0, so it's ok in *this* case, but testing undefined variables can of course lead to unexpected results (notably if you test whether it's 0 ;-) http://stackoverflow.com/questions/5085392/what-is-the-value-of-an-undefined-constant-used-in-if-c - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121286/#review71100 --- On Nov. 30, 2014, 7:53 nachm., René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121286/ --- (Updated Nov. 30, 2014, 7:53 nachm.) Review request for KDE Software on Mac OS X and KDE Runtime. Repository: kde-runtime Description --- DrKonqi currently lacks support for lldb, which means KDE users on recent OS X versions cannot generate and submit post-mortem backtraces. The patches in this RR introduce simple logic (based on *compile-time* OS version detection) to select either gdb or lldb, as well as appropriate lldbrc files. This is the first step to be taken: determine when lldb should be launched, and how (to obtain a backtrace). Diffs - drkonqi/data/debuggers/external/lldbrc PRE-CREATION drkonqi/data/debuggers/internal/lldbrc PRE-CREATION drkonqi/debugger.h 1451397 drkonqi/backtracegenerator.cpp 1107e11 drkonqi/parser/backtraceparserlldb.h PRE-CREATION drkonqi/debugger.cpp 26ca338 drkonqi/drkonqibackends.cpp 064d07d drkonqi/parser/CMakeLists.txt d08d0d7 drkonqi/parser/backtraceparser.cpp 7f62c97 drkonqi/parser/backtraceparserlldb.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121286/diff/ Testing --- On OS X 10.9.4 with kdelibs git/4.14 . Launching lldb works, as does the BatchCommand to obtain a backtrace; parsing of that information will be tackled later. The backtrace isn't particularly useful though, because it doesn't (always/never/...?) display the location of the crash and steps leading up to it, *presumably* because of an issue in the interaction between KDE's crash reporter and lldb. This will need work... ``` Application: Kate (kate), signal: Segmentation fault: 11 (lldb) process attach --pid 88853 Process 88853 stopped Executable module set to /opt/local/bin/kate. Architecture set to: x86_64-apple-macosx. (lldb) command source -s 0 '/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiB88857.tmp' Executing commands in '/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiB88857.tmp'. (lldb) set set term-width 200 (lldb) set set interpreter.prompt-on-quit false (lldb) thread info thread #1: tid = 0x1bda48, 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP (lldb) bt all * thread #1: tid = 0x1bda48, 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8 frame #1: 0x00010272bc8e libkdeui.5.dylib`KCrash::startProcess(int, char const**, bool) [inlined] startProcessInternal(argc=unavailable, directly=unavailable) + 265 at kcrash.cpp:556 frame #2: 0x00010272bb85 libkdeui.5.dylib`KCrash::startProcess(argc=unavailable, argv=unavailable, waitAndExit=unavailable) + 21 at kcrash.cpp:538 frame #3: 0x00010272adb9 libkdeui.5.dylib`KCrash::defaultCrashHandler(sig=unavailable) + 1209 at kcrash.cpp:441 frame #4: 0x7fff8fe965aa libsystem_platform.dylib`_sigtramp + 26 frame #5: 0x7fff8a55c098 libobjc.A.dylib`objc_msgSend + 24 thread #2: tid = 0x1bda4b, 0x7fff8cb86662 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager' frame #0: 0x7fff8cb86662 libsystem_kernel.dylib`kevent64 + 10 frame #1: 0x7fff905a1421 libdispatch.dylib`_dispatch_mgr_invoke + 239 frame #2: 0x7fff905a1136 libdispatch.dylib`_dispatch_mgr_thread + 52 thread #3: tid = 0x1bda4c, 0x7fff8cb85e6a libsystem_kernel.dylib`__workq_kernreturn + 10 frame #0: 0x7fff8cb85e6a libsystem_kernel.dylib`__workq_kernreturn + 10 frame #1: 0x7fff8f5d6f08 libsystem_pthread.dylib`_pthread_wqthread + 330 frame #2: 0x7fff8f5d9fb9
Re: Review Request 121286: Adding support for lldb in DrKonqi (step 1)
On Nov. 30, 2014, 1:43 p.m., Thomas Lübking wrote: drkonqi/backtracegenerator.cpp, line 99 https://git.reviewboard.kde.org/r/121286/diff/3/?file=331098#file331098line99 -setOpenMode(QIODevice::ReadOnly|.)? Why is this required, btw.? Does lldb wet itself if DrKonqi writes into it? I think this already came up: lldb in its current version fails to exit at the end of a batch file (despite the quit command!) unless its stdin is closed or redirected from /dev/null. - René J.V. --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121286/#review71117 --- On Nov. 30, 2014, 8:53 p.m., René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121286/ --- (Updated Nov. 30, 2014, 8:53 p.m.) Review request for KDE Software on Mac OS X and KDE Runtime. Repository: kde-runtime Description --- DrKonqi currently lacks support for lldb, which means KDE users on recent OS X versions cannot generate and submit post-mortem backtraces. The patches in this RR introduce simple logic (based on *compile-time* OS version detection) to select either gdb or lldb, as well as appropriate lldbrc files. This is the first step to be taken: determine when lldb should be launched, and how (to obtain a backtrace). Diffs - drkonqi/data/debuggers/external/lldbrc PRE-CREATION drkonqi/data/debuggers/internal/lldbrc PRE-CREATION drkonqi/debugger.h 1451397 drkonqi/backtracegenerator.cpp 1107e11 drkonqi/parser/backtraceparserlldb.h PRE-CREATION drkonqi/debugger.cpp 26ca338 drkonqi/drkonqibackends.cpp 064d07d drkonqi/parser/CMakeLists.txt d08d0d7 drkonqi/parser/backtraceparser.cpp 7f62c97 drkonqi/parser/backtraceparserlldb.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121286/diff/ Testing --- On OS X 10.9.4 with kdelibs git/4.14 . Launching lldb works, as does the BatchCommand to obtain a backtrace; parsing of that information will be tackled later. The backtrace isn't particularly useful though, because it doesn't (always/never/...?) display the location of the crash and steps leading up to it, *presumably* because of an issue in the interaction between KDE's crash reporter and lldb. This will need work... ``` Application: Kate (kate), signal: Segmentation fault: 11 (lldb) process attach --pid 88853 Process 88853 stopped Executable module set to /opt/local/bin/kate. Architecture set to: x86_64-apple-macosx. (lldb) command source -s 0 '/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiB88857.tmp' Executing commands in '/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiB88857.tmp'. (lldb) set set term-width 200 (lldb) set set interpreter.prompt-on-quit false (lldb) thread info thread #1: tid = 0x1bda48, 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP (lldb) bt all * thread #1: tid = 0x1bda48, 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8 frame #1: 0x00010272bc8e libkdeui.5.dylib`KCrash::startProcess(int, char const**, bool) [inlined] startProcessInternal(argc=unavailable, directly=unavailable) + 265 at kcrash.cpp:556 frame #2: 0x00010272bb85 libkdeui.5.dylib`KCrash::startProcess(argc=unavailable, argv=unavailable, waitAndExit=unavailable) + 21 at kcrash.cpp:538 frame #3: 0x00010272adb9 libkdeui.5.dylib`KCrash::defaultCrashHandler(sig=unavailable) + 1209 at kcrash.cpp:441 frame #4: 0x7fff8fe965aa libsystem_platform.dylib`_sigtramp + 26 frame #5: 0x7fff8a55c098 libobjc.A.dylib`objc_msgSend + 24 thread #2: tid = 0x1bda4b, 0x7fff8cb86662 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager' frame #0: 0x7fff8cb86662 libsystem_kernel.dylib`kevent64 + 10 frame #1: 0x7fff905a1421 libdispatch.dylib`_dispatch_mgr_invoke + 239 frame #2: 0x7fff905a1136 libdispatch.dylib`_dispatch_mgr_thread + 52 thread #3: tid = 0x1bda4c, 0x7fff8cb85e6a libsystem_kernel.dylib`__workq_kernreturn + 10 frame #0: 0x7fff8cb85e6a libsystem_kernel.dylib`__workq_kernreturn + 10 frame #1: 0x7fff8f5d6f08 libsystem_pthread.dylib`_pthread_wqthread + 330 frame #2: 0x7fff8f5d9fb9 libsystem_pthread.dylib`start_wqthread + 13 thread #4: tid = 0x1bda52, 0x7fff8cb85e6a libsystem_kernel.dylib`__workq_kernreturn + 10 frame #0: 0x7fff8cb85e6a
Re: Review Request 121286: Adding support for lldb in DrKonqi (step 1)
On Nov. 29, 2014, 11:20 p.m., Pino Toscano wrote: drkonqi/drkonqibackends.cpp, line 175 https://git.reviewboard.kde.org/r/121286/diff/3/?file=331101#file331101line175 This macros won't be defined outside Mac, so please check for its existency as well. René J.V. Bertin wrote: On the compilers I have experience with this evaluates to false f the token isn't defined... Thomas Lübking wrote: undefined vars get a value of 0, so it's ok in *this* case, but testing undefined variables can of course lead to unexpected results (notably if you test whether it's 0 ;-) http://stackoverflow.com/questions/5085392/what-is-the-value-of-an-undefined-constant-used-in-if-c You're right of course ... - René J.V. --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121286/#review71100 --- On Nov. 30, 2014, 8:53 p.m., René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121286/ --- (Updated Nov. 30, 2014, 8:53 p.m.) Review request for KDE Software on Mac OS X and KDE Runtime. Repository: kde-runtime Description --- DrKonqi currently lacks support for lldb, which means KDE users on recent OS X versions cannot generate and submit post-mortem backtraces. The patches in this RR introduce simple logic (based on *compile-time* OS version detection) to select either gdb or lldb, as well as appropriate lldbrc files. This is the first step to be taken: determine when lldb should be launched, and how (to obtain a backtrace). Diffs - drkonqi/data/debuggers/external/lldbrc PRE-CREATION drkonqi/data/debuggers/internal/lldbrc PRE-CREATION drkonqi/debugger.h 1451397 drkonqi/backtracegenerator.cpp 1107e11 drkonqi/parser/backtraceparserlldb.h PRE-CREATION drkonqi/debugger.cpp 26ca338 drkonqi/drkonqibackends.cpp 064d07d drkonqi/parser/CMakeLists.txt d08d0d7 drkonqi/parser/backtraceparser.cpp 7f62c97 drkonqi/parser/backtraceparserlldb.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121286/diff/ Testing --- On OS X 10.9.4 with kdelibs git/4.14 . Launching lldb works, as does the BatchCommand to obtain a backtrace; parsing of that information will be tackled later. The backtrace isn't particularly useful though, because it doesn't (always/never/...?) display the location of the crash and steps leading up to it, *presumably* because of an issue in the interaction between KDE's crash reporter and lldb. This will need work... ``` Application: Kate (kate), signal: Segmentation fault: 11 (lldb) process attach --pid 88853 Process 88853 stopped Executable module set to /opt/local/bin/kate. Architecture set to: x86_64-apple-macosx. (lldb) command source -s 0 '/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiB88857.tmp' Executing commands in '/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiB88857.tmp'. (lldb) set set term-width 200 (lldb) set set interpreter.prompt-on-quit false (lldb) thread info thread #1: tid = 0x1bda48, 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP (lldb) bt all * thread #1: tid = 0x1bda48, 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8 frame #1: 0x00010272bc8e libkdeui.5.dylib`KCrash::startProcess(int, char const**, bool) [inlined] startProcessInternal(argc=unavailable, directly=unavailable) + 265 at kcrash.cpp:556 frame #2: 0x00010272bb85 libkdeui.5.dylib`KCrash::startProcess(argc=unavailable, argv=unavailable, waitAndExit=unavailable) + 21 at kcrash.cpp:538 frame #3: 0x00010272adb9 libkdeui.5.dylib`KCrash::defaultCrashHandler(sig=unavailable) + 1209 at kcrash.cpp:441 frame #4: 0x7fff8fe965aa libsystem_platform.dylib`_sigtramp + 26 frame #5: 0x7fff8a55c098 libobjc.A.dylib`objc_msgSend + 24 thread #2: tid = 0x1bda4b, 0x7fff8cb86662 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager' frame #0: 0x7fff8cb86662 libsystem_kernel.dylib`kevent64 + 10 frame #1: 0x7fff905a1421 libdispatch.dylib`_dispatch_mgr_invoke + 239 frame #2: 0x7fff905a1136 libdispatch.dylib`_dispatch_mgr_thread + 52 thread #3: tid = 0x1bda4c, 0x7fff8cb85e6a libsystem_kernel.dylib`__workq_kernreturn + 10 frame #0: 0x7fff8cb85e6a libsystem_kernel.dylib`__workq_kernreturn + 10 frame #1: 0x7fff8f5d6f08
Re: Review Request 121286: Adding support for lldb in DrKonqi (step 1)
On Nov. 29, 2014, 12:09 a.m., Pino Toscano wrote: drkonqi/backtracegenerator.cpp, lines 97-100 https://git.reviewboard.kde.org/r/121286/diff/1/?file=331014#file331014line97 Shouldn't this rather be some attribute in the rc file, instead of hardcoding the lldb behaviour in the code? René J.V. Bertin wrote: I tried that, but a redirection from /dev/null in the Exec line had no effect (or rather, gave a warning from lldb that arguments after -p %pid were ignored). Is there a way to redirect stdin in this kind of rc file? Pino Toscano wrote: I meant rather have a new configuration key for this behaviour. That'd be nicer, indeed, but that'd mean extending the Debugger class, right? Any suggestions/advice? Something like a boolean key to redirect stdin from /dev/null, or rather a field to specify an input filename (which could be %tempfile)? - René J.V. --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121286/#review71066 --- On Nov. 29, 2014, 1:26 a.m., René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121286/ --- (Updated Nov. 29, 2014, 1:26 a.m.) Review request for KDE Software on Mac OS X and KDE Runtime. Repository: kde-runtime Description --- DrKonqi currently lacks support for lldb, which means KDE users on recent OS X versions cannot generate and submit post-mortem backtraces. The patches in this RR introduce simple logic (based on *compile-time* OS version detection) to select either gdb or lldb, as well as appropriate lldbrc files. This is the first step to be taken: determine when lldb should be launched, and how (to obtain a backtrace). Diffs - drkonqi/backtracegenerator.cpp 1107e11 drkonqi/data/debuggers/external/lldbrc PRE-CREATION drkonqi/data/debuggers/internal/lldbrc PRE-CREATION drkonqi/drkonqibackends.cpp 064d07d Diff: https://git.reviewboard.kde.org/r/121286/diff/ Testing --- On OS X 10.9.4 with kdelibs git/4.14 . Launching lldb works, as does the BatchCommand to obtain a backtrace; parsing of that information will be tackled later. The backtrace isn't particularly useful though, because it doesn't (always/never/...?) display the location of the crash and steps leading up to it, *presumably* because of an issue in the interaction between KDE's crash reporter and lldb. This will need work... ``` Application: Kate (kate), signal: Segmentation fault: 11 (lldb) process attach --pid 88853 Process 88853 stopped Executable module set to /opt/local/bin/kate. Architecture set to: x86_64-apple-macosx. (lldb) command source -s 0 '/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiB88857.tmp' Executing commands in '/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiB88857.tmp'. (lldb) set set term-width 200 (lldb) set set interpreter.prompt-on-quit false (lldb) thread info thread #1: tid = 0x1bda48, 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP (lldb) bt all * thread #1: tid = 0x1bda48, 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8 frame #1: 0x00010272bc8e libkdeui.5.dylib`KCrash::startProcess(int, char const**, bool) [inlined] startProcessInternal(argc=unavailable, directly=unavailable) + 265 at kcrash.cpp:556 frame #2: 0x00010272bb85 libkdeui.5.dylib`KCrash::startProcess(argc=unavailable, argv=unavailable, waitAndExit=unavailable) + 21 at kcrash.cpp:538 frame #3: 0x00010272adb9 libkdeui.5.dylib`KCrash::defaultCrashHandler(sig=unavailable) + 1209 at kcrash.cpp:441 frame #4: 0x7fff8fe965aa libsystem_platform.dylib`_sigtramp + 26 frame #5: 0x7fff8a55c098 libobjc.A.dylib`objc_msgSend + 24 thread #2: tid = 0x1bda4b, 0x7fff8cb86662 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager' frame #0: 0x7fff8cb86662 libsystem_kernel.dylib`kevent64 + 10 frame #1: 0x7fff905a1421 libdispatch.dylib`_dispatch_mgr_invoke + 239 frame #2: 0x7fff905a1136 libdispatch.dylib`_dispatch_mgr_thread + 52 thread #3: tid = 0x1bda4c, 0x7fff8cb85e6a libsystem_kernel.dylib`__workq_kernreturn + 10 frame #0: 0x7fff8cb85e6a libsystem_kernel.dylib`__workq_kernreturn + 10 frame #1: 0x7fff8f5d6f08 libsystem_pthread.dylib`_pthread_wqthread + 330 frame #2: 0x7fff8f5d9fb9 libsystem_pthread.dylib`start_wqthread + 13
Re: Review Request 121286: Adding support for lldb in DrKonqi (step 1)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121286/ --- (Updated Nov. 29, 2014, 11:03 p.m.) Review request for KDE Software on Mac OS X and KDE Runtime. Changes --- I've added a very timid first step to providing a dedicated lldb parser. For now it's just a version of the null parser that doesn't pretend that all lines are `MissingEverything`. I've also added a couple of regexps to filter out system libraries. Those are platform-specific, so I put them in a conditional block. I'd suggest to do the same for the Linux and MS Windows filters, BTW. I don't know what went awry yesterday, but today I'm getting complete backtraces: ``` Application: Kate (kate), signal: Segmentation fault: 11 (lldb) process attach --pid 95958 Process 95958 stopped Executable module set to /opt/local/bin/kate. Architecture set to: x86_64-apple-macosx. (lldb) command source -s 0 '/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiR95962.tmp' Executing commands in '/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiR95962.tmp'. (lldb) set set term-width 200 (lldb) thread info thread #1: tid = 0x24d59a, 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP (lldb) bt all * thread #1: tid = 0x24d59a, 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8 frame #1: 0x00010210cc8e libkdeui.5.dylib`KCrash::startProcess(int, char const**, bool) [inlined] startProcessInternal(argc=unavailable, directly=unavailable) + 265 at kcrash.cpp:556 frame #2: 0x00010210cb85 libkdeui.5.dylib`KCrash::startProcess(argc=unavailable, argv=unavailable, waitAndExit=unavailable) + 21 at kcrash.cpp:538 frame #3: 0x00010210bdb9 libkdeui.5.dylib`KCrash::defaultCrashHandler(sig=unavailable) + 1209 at kcrash.cpp:441 frame #4: 0x7fff8fe965aa libsystem_platform.dylib`_sigtramp + 26 frame #5: 0x000102785431 QtGui`qt_mac_create_imagemask(pixmap=unavailable, sr=0x7fff5e718c30) + 753 at qpixmap_mac.cpp:1090 frame #6: 0x00010289fafb QtGui`qt_mac_draw_pattern(info=0x7f9964ef3290, c=0x7f9964ef8b90) + 907 at qpaintengine_mac.cpp:494 frame #7: 0x7fff93e1ca6f CoreGraphics`CGPatternDelegateDrawPattern + 66 frame #8: 0x0001081db75a libPDFRIP.A.dylib`PDFPatternEmitDefinition + 1299 frame #9: 0x0001081db9c6 libPDFRIP.A.dylib`emitPatternDefinition + 14 frame #10: 0x7fff8b0d1382 CoreFoundation`__CFSetApplyFunction_block_invoke + 18 frame #11: 0x7fff8b0b58fc CoreFoundation`CFBasicHashApply + 124 frame #12: 0x7fff8b0d133d CoreFoundation`CFSetApplyFunction + 173 frame #13: 0x0001081db993 libPDFRIP.A.dylib`PDFPatternSetEmitDefinitions + 71 frame #14: 0x0001081d1a0c libPDFRIP.A.dylib`emit_page_resources(PDFDocument*) + 59 frame #15: 0x0001081d19b0 libPDFRIP.A.dylib`PDFDocumentEndPage + 73 frame #16: 0x0001081d0570 libPDFRIP.A.dylib`pdf_EndPage + 17 frame #17: 0x7fff8f7e7ea3 PrintCore`pdfSpoolingEndPage(void*, void*) + 345 frame #18: 0x7fff8f7df835 PrintCore`PJCEndPage(OpaquePMPrintSession*) + 40 frame #19: 0x7fff8f7bd3b6 PrintCore`PMSessionEndPageNoDialog + 80 frame #20: 0x0001026832c7 QtGui`QMacPrintEngine::end() + 103 frame #21: 0x0001027dcd0e QtGui`QPainter::end(this=unavailable) + 142 at qpainter.cpp:1963 frame #22: 0x00010ca59159 libkatepartinterfaces.4.dylib`KatePrinter::print(doc=unavailable) + 17097 at kateprinter.cpp:669 frame #23: 0x00010c8ad33a libkatepartinterfaces.4.dylib`KateDocument::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) [inlined] KateDocument::print() + 1994 at katedocument.cpp:1855 frame #24: 0x00010c8ad332 libkatepartinterfaces.4.dylib`KateDocument::qt_static_metacall(_o=0x7f996246a920, _c=unavailable, _id=unavailable, _a=0x7fff5e719d80) + 1986 at katedocument.moc:267 frame #25: 0x000103c7c3fd QtCore`QMetaObject::activate(sender=0x7f9964d38d40, m=unavailable, local_signal_index=unavailable, argv=unavailable) + 1693 at qobject.cpp:3567 frame #26: 0x0001026bf419 QtGui`QAction::activate(QAction::ActionEvent) [inlined] QAction::triggered(this=0x7f9964d38d40, _t1=false) + 233 at moc_qaction.cpp:277 frame #27: 0x0001026bf3f1 QtGui`QAction::activate(this=0x7f9964d38d40, event=unavailable) + 193 at qaction.cpp:1257 frame #28: 0x000102673c91 QtGui`-[QCocoaMenuLoader qtDispatcherToQAction:] + 65 frame #29: 0x7fff8e38b260 AppKit`-[NSApplication sendAction:to:from:] + 327 frame #30: 0x7fff8e3a61c8 AppKit`-[NSMenuItem _corePerformAction]
Re: Review Request 121286: Adding support for lldb in DrKonqi (step 1)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121286/#review71100 --- drkonqi/backtracegenerator.cpp https://git.reviewboard.kde.org/r/121286/#comment49666 Still hardcodes the debugger name; I'm not a drkonqui developer, so I cannot tell you exactly what to do -- surely, not hardcoding a particular debugger behaviour will be better anyway. drkonqi/drkonqibackends.cpp https://git.reviewboard.kde.org/r/121286/#comment49667 This macros won't be defined outside Mac, so please check for its existency as well. drkonqi/parser/backtraceparser.cpp https://git.reviewboard.kde.org/r/121286/#comment49663 Most probably not needed? drkonqi/parser/backtraceparser.cpp https://git.reviewboard.kde.org/r/121286/#comment49664 startsWith(libsystem_) endsWith(.dynlib) drkonqi/parser/backtraceparser.cpp https://git.reviewboard.kde.org/r/121286/#comment49665 This does not need a regexp. - Pino Toscano On Nov. 29, 2014, 10:03 p.m., René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121286/ --- (Updated Nov. 29, 2014, 10:03 p.m.) Review request for KDE Software on Mac OS X and KDE Runtime. Repository: kde-runtime Description --- DrKonqi currently lacks support for lldb, which means KDE users on recent OS X versions cannot generate and submit post-mortem backtraces. The patches in this RR introduce simple logic (based on *compile-time* OS version detection) to select either gdb or lldb, as well as appropriate lldbrc files. This is the first step to be taken: determine when lldb should be launched, and how (to obtain a backtrace). Diffs - drkonqi/backtracegenerator.cpp 1107e11 drkonqi/data/debuggers/external/lldbrc PRE-CREATION drkonqi/data/debuggers/internal/lldbrc PRE-CREATION drkonqi/drkonqibackends.cpp 064d07d drkonqi/parser/CMakeLists.txt d08d0d7 drkonqi/parser/backtraceparser.cpp 7f62c97 drkonqi/parser/backtraceparserlldb.h PRE-CREATION drkonqi/parser/backtraceparserlldb.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121286/diff/ Testing --- On OS X 10.9.4 with kdelibs git/4.14 . Launching lldb works, as does the BatchCommand to obtain a backtrace; parsing of that information will be tackled later. The backtrace isn't particularly useful though, because it doesn't (always/never/...?) display the location of the crash and steps leading up to it, *presumably* because of an issue in the interaction between KDE's crash reporter and lldb. This will need work... ``` Application: Kate (kate), signal: Segmentation fault: 11 (lldb) process attach --pid 88853 Process 88853 stopped Executable module set to /opt/local/bin/kate. Architecture set to: x86_64-apple-macosx. (lldb) command source -s 0 '/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiB88857.tmp' Executing commands in '/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiB88857.tmp'. (lldb) set set term-width 200 (lldb) set set interpreter.prompt-on-quit false (lldb) thread info thread #1: tid = 0x1bda48, 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP (lldb) bt all * thread #1: tid = 0x1bda48, 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8 frame #1: 0x00010272bc8e libkdeui.5.dylib`KCrash::startProcess(int, char const**, bool) [inlined] startProcessInternal(argc=unavailable, directly=unavailable) + 265 at kcrash.cpp:556 frame #2: 0x00010272bb85 libkdeui.5.dylib`KCrash::startProcess(argc=unavailable, argv=unavailable, waitAndExit=unavailable) + 21 at kcrash.cpp:538 frame #3: 0x00010272adb9 libkdeui.5.dylib`KCrash::defaultCrashHandler(sig=unavailable) + 1209 at kcrash.cpp:441 frame #4: 0x7fff8fe965aa libsystem_platform.dylib`_sigtramp + 26 frame #5: 0x7fff8a55c098 libobjc.A.dylib`objc_msgSend + 24 thread #2: tid = 0x1bda4b, 0x7fff8cb86662 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager' frame #0: 0x7fff8cb86662 libsystem_kernel.dylib`kevent64 + 10 frame #1: 0x7fff905a1421 libdispatch.dylib`_dispatch_mgr_invoke + 239 frame #2: 0x7fff905a1136 libdispatch.dylib`_dispatch_mgr_thread + 52 thread #3: tid = 0x1bda4c, 0x7fff8cb85e6a libsystem_kernel.dylib`__workq_kernreturn + 10 frame #0: 0x7fff8cb85e6a libsystem_kernel.dylib`__workq_kernreturn + 10
Re: Review Request 121286: Adding support for lldb in DrKonqi (step 1)
On Nov. 29, 2014, 10:20 p.m., Pino Toscano wrote: drkonqi/backtracegenerator.cpp, line 97 https://git.reviewboard.kde.org/r/121286/diff/3/?file=331098#file331098line97 Still hardcodes the debugger name; I'm not a drkonqui developer, so I cannot tell you exactly what to do -- surely, not hardcoding a particular debugger behaviour will be better anyway. a) I think codeName() would be the appropriate method (see drkonqi/debugger.h). The name() method gives you the translated name, possibly in non-Latin characters. b) FWIW there are at least two other places in this patch where lldb is used, but gdb and kdbgwin are also already used at those places... :-) So what is wrong with continuing the tradition? c) Would adding something to the file drkonqi_globals.h be of any use? d) I agree that adding a config file entry just for this case and an extra method in debugger.* to access it would be an overkill. - Ian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121286/#review71100 --- On Nov. 29, 2014, 10:03 p.m., René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121286/ --- (Updated Nov. 29, 2014, 10:03 p.m.) Review request for KDE Software on Mac OS X and KDE Runtime. Repository: kde-runtime Description --- DrKonqi currently lacks support for lldb, which means KDE users on recent OS X versions cannot generate and submit post-mortem backtraces. The patches in this RR introduce simple logic (based on *compile-time* OS version detection) to select either gdb or lldb, as well as appropriate lldbrc files. This is the first step to be taken: determine when lldb should be launched, and how (to obtain a backtrace). Diffs - drkonqi/backtracegenerator.cpp 1107e11 drkonqi/data/debuggers/external/lldbrc PRE-CREATION drkonqi/data/debuggers/internal/lldbrc PRE-CREATION drkonqi/drkonqibackends.cpp 064d07d drkonqi/parser/CMakeLists.txt d08d0d7 drkonqi/parser/backtraceparser.cpp 7f62c97 drkonqi/parser/backtraceparserlldb.h PRE-CREATION drkonqi/parser/backtraceparserlldb.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121286/diff/ Testing --- On OS X 10.9.4 with kdelibs git/4.14 . Launching lldb works, as does the BatchCommand to obtain a backtrace; parsing of that information will be tackled later. The backtrace isn't particularly useful though, because it doesn't (always/never/...?) display the location of the crash and steps leading up to it, *presumably* because of an issue in the interaction between KDE's crash reporter and lldb. This will need work... ``` Application: Kate (kate), signal: Segmentation fault: 11 (lldb) process attach --pid 88853 Process 88853 stopped Executable module set to /opt/local/bin/kate. Architecture set to: x86_64-apple-macosx. (lldb) command source -s 0 '/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiB88857.tmp' Executing commands in '/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiB88857.tmp'. (lldb) set set term-width 200 (lldb) set set interpreter.prompt-on-quit false (lldb) thread info thread #1: tid = 0x1bda48, 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP (lldb) bt all * thread #1: tid = 0x1bda48, 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8 frame #1: 0x00010272bc8e libkdeui.5.dylib`KCrash::startProcess(int, char const**, bool) [inlined] startProcessInternal(argc=unavailable, directly=unavailable) + 265 at kcrash.cpp:556 frame #2: 0x00010272bb85 libkdeui.5.dylib`KCrash::startProcess(argc=unavailable, argv=unavailable, waitAndExit=unavailable) + 21 at kcrash.cpp:538 frame #3: 0x00010272adb9 libkdeui.5.dylib`KCrash::defaultCrashHandler(sig=unavailable) + 1209 at kcrash.cpp:441 frame #4: 0x7fff8fe965aa libsystem_platform.dylib`_sigtramp + 26 frame #5: 0x7fff8a55c098 libobjc.A.dylib`objc_msgSend + 24 thread #2: tid = 0x1bda4b, 0x7fff8cb86662 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager' frame #0: 0x7fff8cb86662 libsystem_kernel.dylib`kevent64 + 10 frame #1: 0x7fff905a1421 libdispatch.dylib`_dispatch_mgr_invoke + 239 frame #2: 0x7fff905a1136 libdispatch.dylib`_dispatch_mgr_thread + 52 thread #3: tid = 0x1bda4c, 0x7fff8cb85e6a libsystem_kernel.dylib`__workq_kernreturn + 10
Re: Review Request 121286: Adding support for lldb in DrKonqi (step 1)
On Nov. 28, 2014, 11:09 p.m., Pino Toscano wrote: drkonqi/backtracegenerator.cpp, lines 97-100 https://git.reviewboard.kde.org/r/121286/diff/1/?file=331014#file331014line97 Shouldn't this rather be some attribute in the rc file, instead of hardcoding the lldb behaviour in the code? René J.V. Bertin wrote: I tried that, but a redirection from /dev/null in the Exec line had no effect (or rather, gave a warning from lldb that arguments after -p %pid were ignored). Is there a way to redirect stdin in this kind of rc file? I meant rather have a new configuration key for this behaviour. - Pino --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121286/#review71066 --- On Nov. 29, 2014, 12:26 a.m., René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121286/ --- (Updated Nov. 29, 2014, 12:26 a.m.) Review request for KDE Software on Mac OS X and KDE Runtime. Repository: kde-runtime Description --- DrKonqi currently lacks support for lldb, which means KDE users on recent OS X versions cannot generate and submit post-mortem backtraces. The patches in this RR introduce simple logic (based on *compile-time* OS version detection) to select either gdb or lldb, as well as appropriate lldbrc files. This is the first step to be taken: determine when lldb should be launched, and how (to obtain a backtrace). Diffs - drkonqi/backtracegenerator.cpp 1107e11 drkonqi/data/debuggers/external/lldbrc PRE-CREATION drkonqi/data/debuggers/internal/lldbrc PRE-CREATION drkonqi/drkonqibackends.cpp 064d07d Diff: https://git.reviewboard.kde.org/r/121286/diff/ Testing --- On OS X 10.9.4 with kdelibs git/4.14 . Launching lldb works, as does the BatchCommand to obtain a backtrace; parsing of that information will be tackled later. The backtrace isn't particularly useful though, because it doesn't (always/never/...?) display the location of the crash and steps leading up to it, *presumably* because of an issue in the interaction between KDE's crash reporter and lldb. This will need work... ``` Application: Kate (kate), signal: Segmentation fault: 11 (lldb) process attach --pid 88853 Process 88853 stopped Executable module set to /opt/local/bin/kate. Architecture set to: x86_64-apple-macosx. (lldb) command source -s 0 '/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiB88857.tmp' Executing commands in '/private/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/kde-bertin/drkonqiB88857.tmp'. (lldb) set set term-width 200 (lldb) set set interpreter.prompt-on-quit false (lldb) thread info thread #1: tid = 0x1bda48, 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP (lldb) bt all * thread #1: tid = 0x1bda48, 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x7fff8cb85e20 libsystem_kernel.dylib`__wait4 + 8 frame #1: 0x00010272bc8e libkdeui.5.dylib`KCrash::startProcess(int, char const**, bool) [inlined] startProcessInternal(argc=unavailable, directly=unavailable) + 265 at kcrash.cpp:556 frame #2: 0x00010272bb85 libkdeui.5.dylib`KCrash::startProcess(argc=unavailable, argv=unavailable, waitAndExit=unavailable) + 21 at kcrash.cpp:538 frame #3: 0x00010272adb9 libkdeui.5.dylib`KCrash::defaultCrashHandler(sig=unavailable) + 1209 at kcrash.cpp:441 frame #4: 0x7fff8fe965aa libsystem_platform.dylib`_sigtramp + 26 frame #5: 0x7fff8a55c098 libobjc.A.dylib`objc_msgSend + 24 thread #2: tid = 0x1bda4b, 0x7fff8cb86662 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager' frame #0: 0x7fff8cb86662 libsystem_kernel.dylib`kevent64 + 10 frame #1: 0x7fff905a1421 libdispatch.dylib`_dispatch_mgr_invoke + 239 frame #2: 0x7fff905a1136 libdispatch.dylib`_dispatch_mgr_thread + 52 thread #3: tid = 0x1bda4c, 0x7fff8cb85e6a libsystem_kernel.dylib`__workq_kernreturn + 10 frame #0: 0x7fff8cb85e6a libsystem_kernel.dylib`__workq_kernreturn + 10 frame #1: 0x7fff8f5d6f08 libsystem_pthread.dylib`_pthread_wqthread + 330 frame #2: 0x7fff8f5d9fb9 libsystem_pthread.dylib`start_wqthread + 13 thread #4: tid = 0x1bda52, 0x7fff8cb85e6a libsystem_kernel.dylib`__workq_kernreturn + 10 frame #0: 0x7fff8cb85e6a libsystem_kernel.dylib`__workq_kernreturn + 10 frame #1: 0x7fff8f5d6f08 libsystem_pthread.dylib`_pthread_wqthread + 330
