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
This scenario has come up before and I'm wondering if there is any way I can determine where the actively running form is executing within code? The problem is when I inherit a very large application which I'm not totally familiar with yet and I have it running through VS.NET 2010. I might have a particular screen up and go "geeze it would be nice if I could start debugging when I do 'x'".
If this was a simple form with some buttons I wouldn't even bother asking here; I'm not that novice. But the time consuming task is when I look at a tabbed screen in a large multi-project solution with drag and drop capabilities, right click options, etc. and have to spend 5-10 minutes tracking down where to place a breakpoint to debug.
What I'm wondering is if there is a way to have the WinForms app running via IDE and do 'something' that tells VS.NET on the next action break into the code (obviously without a breakpoint because I don't know where to place one yet). This would save me a ton of time trying to track down which event is occurring in a not so simple form or series of forms.
I hope this makes sense...
Thanks!
Yes, that's somewhat possible. When you use Debug + Break All then the 99.9% odds are that you don't break into code that's part of the project. A Winforms app is normally idle, pumping the message loop and waiting for Windows to tell it that something happened. You'll break at the Application.Run() statement.
The trick to then use Debug + Step Over. The program resumes running like normal. Then give a UI command (do 'x' in your question) and the debugger will break at the first statement of real code, typically at the start of the event handler for that command. It isn't exactly guaranteed that that code would be relevant, you might break at a MouseMove event handler for example. So YMMV.
I recently downloaded MI library and executed / read some examples code. In all the examples that I saw the implementation was via a separate program like below:
Main Program
Interact with GDB
exec another program
Gather Debug info of the another program
My question is how can we invoke / implement GDB within current thread/program itself i.e. attach this self-execution process.
how can we invoke / implement GDB MI within current thread/program itself i.e. attach this self-execution/ running process to GDB and then tell it to execute step by step
You can't.
Think about it: the very first thing GDB will do after attaching is stop your program, and wait for instructions on what to do next. At that point your program should send GDB the continue command, except it can't because it has been stopped.
Now, if your program is multi-threaded, and you ask GDB to execute in non-stop mode, and you carefully arrange things such that your thread that performs GDB interaction itself is never stopped, then perhaps this could work. I doubt it will work reliably though.
I'm trying to debug an issue that happens on service startup. Trying to attach while things are running is failing, windbg times out with an error about a link lock. I think that the error occurs before I have a chance to attach. A sleep might let me attach, but is there a more elegant solution?
I'd like to start up the debugger first thing as the service starts. C# has a Debugger.Launch() method to start a debugger at runtime. Is there an equivalent C call that can be used without .net? Something I could just drop in the start routine.
I can't call DebugBreak because at the time the service has started I'm not under a debugger.
Sleep is certainly a viable approach. It's crude yet effective. Somewhat less crude is to use a good logging framework to output diagnostics. With a sufficiently capable logging framework this can be very effective.
How exactly would one go about getting an OpenGL app to run fullscreen straight from the terminal (Ubuntu Server 9.04)? I've developed an application for visual diagnostics on my server, but, I'm not totally sure the best way to get it to run in a windowless environment.
Ideally, I would run my program:
./visualdiagnostics
and have that launch the OpenGL app. Then, via a simple Ctrl+X key binding, I'll kill the app and go back to the terminal.
Do I need to install X11 and then somehow launch it from within the program? What would be the best way to detect if it's already running and, start/stop it if necessary?
And FYI: No, I'm not trying to get this to run over Putty or anything... I have a monitor hooked straight up to the server. The server has proper video drivers installed.
There are several parts to your task. Keep in mind that some of this can be very distro-specific; but since you said Ubuntu we'll talk Ubuntu!
Also you tagged this question C however I am starting off with a common Linux pattern: a native application with a Bash shell script wrapper. Perhaps once you get things working well you might fold that functionality into C if you have to.
Detecting whether X is running
Being root can help a lot. Some things that work.
pgrep Xorg
Check whether /var/lib/gdm/:0.Xauth exists. This will be there even if nobody has logged in but GDM is running.
ls -l /home/*/.Xauthority (Even if you're not root you can at least confirm whether you are running X.
Piggybacking an existing X session
You did not specifically mention it but if you are root at the console, or if you want to run the app as the same user who is already logged in, it's pretty easy.
You have to get the DISPLAY and XAUTHORITY environment variables right, and once you do you can use the existing X display.
For DISPLAY you might just assume :0 or you could find an existing X program (x-session-manager is the GNOME standard) and read its environment from /proc/PID/environ. Variables are in key=value format delimited by a null byte. For example, if its PID is 12345:
cat /proc/12345/environ \
| ruby -ne 'puts $_.split("\0").select {|e| e.starts_with? "DISPLAY=" }'
For XAUTHORITY you could get it the same way. Or if you prefer guessing, it's almost always /home/whoever/.Xauthority
Once you have those two variables, running X code is easy, for example:
env DISPLAY=:0 XAUTHORITY=/home/brian/.Xauthority ./visualdiagnostics
Stopping X
This one is easy if you're root: /etc/init.d/gdm stop. killall Xorg will work too.
If you are a user, kill your own Xorg or x-session-manager process. (I'd welcome input from others for the canonical way to do this. Maybe some dbus-send message?)
Starting X
I would recommend xinit whose goal in life is to fire X and run exactly one program.
For example: xinit ./visualdiagnostics
You can also tell xinit what resolution to run X at which may or may not be important to you. (This becomes important in the full-screen section below.)
The problem with this is you will have no window manager— no maximize and minimize buttons. It's not just cosmetic. Usually an app is useless because a popup window cannot be moved or you cannot focus on the right input field. However if you have a special app it could be sufficient (see full-screen below).
The next step would be my answer to everything: another shell script wrapper! Something simple that starts the window manager and then becomes your program should work.
#!/bin/bash
#
# Start visualdiagnostics once xinit calls me.
/usr/bin/metacity& # Or ratpoison, or fluxbox, or compiz, etc.
exec ./visualdiagnostics
It's important to exec (become) the main program because once that first program exits, X will shut down.
Running fullscreen
I am not 100% certain on this. Some ideas:
Try the standard X -geometry parameters to set 0,0 as the upper-left corner and +x+y for your horizontal and vertical size. How do you know the size? Either you hard-coded it when you launched xinit or you could ask the X server. xwininfo -root will tell you and there is an xlib API call that would do that too—check the xwininfo source I guess.
Your app itself can request maximization and/or resizing to fill the screen. I'm not familiar but it is definitely in the X API.
Some of the more configurable window managers can be pre-configured to run you maximized already. This is probably what I personally would check first. Your wrapper script could create a $HOME/.fluxboxrc just by echoing some hard-coded configs > the file.
Summary
The others are right. X is not strictly necessary sine OpenGL can run against a framebuffer. However considering how ubiquitous X is and how much work has gone into automating it for distributions, I would probably invest my effort into the X route as it might be easier long-term even though it's a little convoluted.
(By the way, I sincerely hope when you say "terminal" you mean you are at the text console, not gnome-terminal that would be awful! :)
Well I am clearly not sure my answer might help you out.
Long ago when I was student, I manage to do so (launching an openGL app from a terminal only linux installation) by installing frame buffer. As long as I remember I needed to recompile my kernel (as framebuffer was/is a kernel module).
This was maybe 5 years ago on a debian distrib, and I don't know how does it work now for up-to-date debian distrib as Ubuntu. Maybe framebuffer is compiled statically in the binary kernel provided by default with Ubuntu. May be not. Maybe framebuffer is irrelevant now... Or I may be totally wrong and not remembering every details of my own adventure 5 years ago now ..
Have a look on Google ! ;-)
Hope it will help...
**
Update:
**
What is frame buffer ?
How to install it? Here or there
As yves pointed out, you can avoid running the X server if you use the framebuffer. Actually, the framebuffer modules are often yet available (for example, they are used to have the tux logo during the kernel start or a text terminal with fancy images in the background), this anyway depends on the distribution and the settings you are using.
The kernel side is quite primitive so I'd suggest to use some higher level library such as DirectFB. The framebuffer is usable without problems but don't expect the same maturity level than a full blown X server.
Are you trying to have the video be on the monitor connected directly to the computer?
Is X running on the server?
If X is running, you can do
export DISPLAY=:0.0
which tells X apps to connect to the X server at localhost, rather than where' you're coming from.
If you're actually logging in locally (from a direct terminal) ... yes, you need X installed and running.