I am trying to set up the lldb debugger to work on a Raspberry Pi and I faced several issues here. The first issue was unable to run the debugger, as I was shown
error: process launch failed: Lost debug server connection, as shown here.
After following the comments on this thread: LLDB: process launch failed: Lost debug server connection, I managed to get it to run on lldb-6.0
However, after setting a breakpoint at the main function and running it using run, it bypassed the breakpoint set and ended the program, as shown in the figure below.
I did not have this problem running on my desktop, but I can't seem to solve the issue on my Raspberry Pi. I have tried this with other programs as well, and it did not seem to work. Is there any solution for this?
Related
I'm following a tutorial on using lldb. I tried typing process attach -p and I got error: attach failed: Error 1. However in the tutorial a screen pops up asking for "developer tools access needs to take control of another process for debugging to continue". I think this is why it won't work. Why does it not pop up?
What were you trying to debug? On Darwin systems, only processes that opt into being debugged can be, and most shipping apps (including all the system ones) do not opt into being debugged.
Since this isn't an issue with the general permission to debug, but rather the target proces rejecting your attach attempt, you wouldn't see the "Developer Tools" dialog box. You machine is configured to debug, just not this process...
You can test this by building something yourself and then attaching to it.
I'm building a React Native app. Everything was working fine but now when I try to run on Android it gets to the task :app:transformClassesWithDexForDebug, it hangs for 30-60 seconds and then Windows shuts down.
I tried to setup multidex as mentioned here: https://stackoverflow.com/a/56875424 but the result is the same.
I'm not getting any error message, the computer just shuts down abruptly and I have to turn it on again.
Any advice is much appreciated.
In the end, it was two problems mixed:
I was using the new Windows Terminal which is still in beta so I guess the shutdown problem was something to do with it, because I changed to normal good ol' cmd and the shutdown problem disappeared.
The actual error in the compilation process was actually the setup of multidex. I was not extending the MultiDexApplication class.
Thank you all.
Environment
Qt 5.6.1
Qt Creator 4.0.1
gdb 7.11
Ubuntu 16.04 LTS
Scenario
C: A client application to communicate with M.
M: A manager process to notify L to launch a new process T.
L: A Launcher process to launch new T by forking itself.
T: A new process running in the background.
I am able to run test application and debug the process C in Qt with gdb. But I am not able to debug the T.
Here is the way I tried to debug the T:
Set breakpoints in both C and T;
When the breakpoint is hit. I use Qt menu option "Debug"->"Start Debugging"->"Attach to running application". To try to attach the debugger to the T process.
This is the problem I am having
Instead of hitting the breakpoints that I set in the T. The gdb always hit an invisible breakpoint in function epoll_wait(). After that, if I continue (F5). The application will keep hanging without hitting any further breakpoints in T. Unless I force stop by using the Qt debug option "Stop Debugger". The application is keep waiting. After I stopped the debugger, the C still breaks in the original breakpoint.
The problem with the debugger in Qt
It seems that Qt uses two different debuggers for different processes. I am thinking it might be caused by the C is hanging. So the T process is keep waiting. But I did not set any breakpoints in wrap_epoll_wait() function I am not sure why gdb breaks there. And in the Qt Debugger. I cannot find a way to switch back to C process to let the process to continue to run. (The Qt debugger component "Threads" drop list is disabled by some reason, I can not select a different thread).
The things I tried
Modified the /etc/sysctl.d/10-ptrace.conf set kernel.yama.ptrace_scope value to 0
Turned the debugger option "Tools->Options->Debugger->GDB Extended->Debug all children" on and off in the Qt.
None of above things changed the fact that the debugger is hanging after the debugger breaks in the function wrap_epoll_wait().
My Question
Anyone at good gdb and Qt knowledge could help me? And let me know how the gdb debug multiple processes works in Qt? How to switch the debugger between different processes and why gdb breaks on somewhere I did not set the breakpoint?
Thank you very much,
Rong
Since T created by forking from L. The gdb settings 'set follow-fork-mode' needs to be set to 'child' in Qt creator.
reference:
https://sourceware.org/gdb/onlinedocs/gdb/Forks.html
I'm trying to debug for the first time a gtk code and actually, I want to debug a callback function for key-press-event so I set a breakpoint with gdb and when it hits the breakpoint, the whole desktop evirement is freezing (I'm running under gnome-shell) it seems that the graphic envirement is waiting for the event to finish.
I got some idea that didn't worked :
The first attempts was to assign some gdb commands to the breakpoint :
(gdb) break on_key_press_callback
(gdb) commands
> back trace
> next
> next
> next
> continue
> end
but I don't know why, only the back trace command is executed, and then freeze.
The second attempt was to debug remotely using gdbserver and gdb on tty1 (no graphigs to freeze :) ) I was able to send commands like next and step after the breakpoint but there was nothing to see (can't list code, inspect the stack, ect ...)
So any good tips to be able to debug in such situations ?
Thanks
It's typical to have lockups when debugging an X program running on the same server that you're using to debug. For example, if the inferior (gdb terminology for the program being debugged) does a server grab -- whoops, the gdb GUI (or terminal or emacs etc) is locked out.
Your idea of doing more programmatic debugging is a good one, but it's hard to make it all work nicely. As you found, some gdb commands (basically those related to inferior control) don't work in commands. Also, it just isn't nearly as convenient.
You can go further that direction. For example you could use SystemTap to probe the program instead.
However there are also nicer approaches.
One way is to run the inferior using a virtual X server -- a nested one, or one running in a VM. Then you can escape to the "outer" X server for debugging. This will be much nicer.
Another way is to have two computers, and run the debugger on one and the inferior on the other. In a way this is really the same answer, just using a real machine rather than a virtual one.
The question is old, but for anyone that may be struggling with this issue, there is a way to stop the freezing behaviour from happening by disabling the X server grab.
You have to change the config in your IDE to run the program with the following system property:
-Dsun.awt.disablegrab=true
If you are using javaws (Java Web Start) to run the application use:
-J-Dsun.awt.disablegrab=true
instead.
Using gdb, I am trying to trace the function calls of a web server. I set breakpoints on every function call and when I tell gdb to 'run' it breaks at all the right places while the server starts up. Then gdb says 'Program ended with code 01' and doesn't stop at breakpoints anymore (obviously). However, the web server is still running.
I want to be able to trace the function calls made on an incoming HTTP request, so just breaking during server startup is useless to me.
Is there some trick to using gdb when tracing a daemon server so that it doesn't just end like above?
You didn't say which server you are trying to trace, but likely it is Apache.
Detailed instructions are here. Note the -X command line argument, which prevents httpd from forking children.
Also note that the instructions are the first result for this search.
set follow-fork-mode child
see https://sourceware.org/gdb/onlinedocs/gdb/Forks.html for example