I've crosscompiled qt using qtcreator. Debug works good, but when I try to step in (F11) a function defined in an external shared library (of mine), I see gdb hanging and finally fail with the following error:
115^error,msg="Reply contains invalid hex digit 116" COOKIE FOR TOKEN 115 ALREADY EATEN (InferiorStopOk). TWO RESPONSES FOR ONE COMMAND? Executable failed: Reply contains invalid hex digit 116
Any Ideas?
It could be:
A general gdb bug unrelated to the communications protocol,
A gdb bug in its gdb communications protocol implementation,
A Qt Creator bug in the gdb communications protocol implementation.
Since it is a bug in any case, you're after good information to put into the bug report. Examine Qt Creator's debugger log to see exactly when it happens. You can then try to reproduce the same command stream manually, from gdb's command line. If you succeed, then #1 is unlikely. You could use another IDE (say Eclipse) to differentiate between #2 and #3, but remember that the other IDE is unlikely to issue the same commands that Qt Creator would issue.
The only sure way of debugging it is interposing a small program between Qt Creator and gdb, dumping the commands that Qt creator has sent, then replaying them without Qt Creator. You then need to parse the responses and ascertain whether they are valid. If they are, then neither #1 nor #2 holds and it's very likely a Qt Creator bug, #3.
The 'error,msg=' is generated by GDB in response to a GDBserver message. Qt Creator's communication with GDB is not involved. So this is a mis-communication between GDB and GDBserver.
Is that a proper GDBserver, and a GDB for that target architecture?
Btw, one does not need a program to intercept what Qt Creator send to GDB, it's all listed in the left pane of the debugger log.
I've found that the problem is related to the use of "step-in" (F11) function.
Inexplicably, you can avoid this message toggling a breakpoint in the library and simply using play function (F5), in order to debug your library.
Thanks anyway for your response. I've done a lot of tests before focusing the real problem.
Related
I am attempting to use QTCreator's Memcheck tool to analyze the memory of a QT project, which is a dynamic library. It uses a QT Gui (QMainWindow) to allow the user to select a file, which is then processed, and then eventually returns to the mainwindow.
However, I cannot seem to use Memcheck properly.
When I select "Memcheck" and hit run, it instantly goes to "Analyzing memory" without ever letting the Gui pop up.
This is problematic. How can I get memcheck to work with this program?
I had two main issues:
1: Valgrind does not seem to play nice with QT Gui applications. It generates logs that are thousands of entries long for all the work QT is doing before it even gets to my application.
I had to make a separate, small non-GUI C++ program that would drive instead of the GUI application.
2: When trying to run from the command line, I needed to set an environment variable by using export. This needs to be the same as LD_LIBRARY_PATHS in QT Creator.
So I ran:
export LD_LIBRARY_PATH=X where X was the exact value I copied from LD_LIBRARY_PATHS in the variable from the QT Project.
Note: Running from the command line may have not be neccesary now that it isn't a GUI Application, memcheck might have passed just fine. Haven't tested since.
When running my Qt5 application on linux, I don't see any output from qDebug, qWarning, qCritical or qFatal. I know that I can use qInstallMsgHandler to install a message handler and see them, but this is rather heavyweight.
I just want to check the qWarning log to see if there is any signal that mis-connected. Is there a way to look at this log? A special command-line option, an environment variable?
I think I remember that in the past, everything was printed to stderr, perhaps that's a Qt5 change?
Please do not make the mistake of assuming that qDebug, qWarning, qCritical and qFatal always log on standard error. That's absolutely not the case.
The actual destination varies depending on the Qt configuration and the targeting OS. Plus, 5.4 and then 5.11 introduced some behavioural changes. See here and here for discussions.
TL;DR:
On Qt >= 5.11
If the process' stderr has a console attached, that's where the debug log will go.
If you want to always log on stderr, set QT_FORCE_STDERR_LOGGING to 1.
In alternative, set QT_ASSUME_STDERR_HAS_CONSOLE to 1. I suspect this one is meant to be used by a parent process that reads a child's stderr and shows it to the user somehow.
QT_LOGGING_TO_CONSOLE to 1 still works, but Qt will complain.
On Qt >= 5.4 and < 5.11
If you want to always log on stderr, set the QT_LOGGING_TO_CONSOLE environment variable to 1.
If you do not want to log on stderr, the QT_LOGGING_TO_CONSOLE environment variable to 0 (this will force logging through the native system logger).
If the QT_LOGGING_TO_CONSOLE environment variable is not set, then whether logging to the console or not depends on whether the application is running in a TTY (on UNIX) or whether there's a console window (on Windows).
On Qt < 5.4, the situation is more confusing.
If Qt has been built with support for a specific logging framework (e.g. SLOG2, journald, Android log, etc.) then logging always goes to that framework
Otherwise on UNIX it goes to stderr
Otherwise on Windows OutputDebugString or stderr is used depending whether the app is a console app.
The problem with the pre-5.4 approach was that, f.i., under Unix IDEs would not capture an application's debug output if Qt had been built with journald support. That's because the output went to journald, not to the IDE. In 5.4 the approach has been made more flexible and uniform across OSes.
If you happen to run Arch Linux, which compiles Qt with the -journald option, all debug output is per default directed to the systemd journal (display with journalctl).
You can override this behaviour by defining QT_LOGGING_TO_CONSOLE=1 as an environment variable.
They are still printed to standard error.
If you launch the application from the command line, it is usually printed there, or if using Qt Creator, it's displayed in the Application Output window.
If you are using visual studio, qDebug etc are printed to the output window in the IDE.
I understood that anything to standard out (System.out) would appear in the Java Console window (when it's enabled). I spotted somewhere though that there might be situations where this isn't try, for example, from Swing apps. Is that the case?
Basically, what situations or setups wouldn't I expect to see standard output in the console? Is there a difference in behavior running on the JDK rather than explicitly on the JRE for example? javaw.exe?
ps, I understand how to display the Console in the Java settings but I'm curious as I've managed to create an application, run as an executable jar, that doesn't start the console despite some calls to System.out) on Windows 7.
The only way you wouldn't see System.out output in the console is if the method System.setOut has been invoked. This method is invoked to redirect output to the graphical Java Console, but I don't know of any other realistic circumstance in which it would be redirected away from the Java Console unless you do so voluntarily.
Depending on terminal settings it can happen that the output is not written until a newline character is sent as well. So if you do System.out.print("test") it might not appear immediately.
On Windows this is usually not the case, but on Unix terminals this is quite common.
Perhaps you use javaw to start virtual machine, this version will not show console messages. You can use java to start the virtual machine, which will show the console message.
javaw is intended for apps with windows, java is intended for console apps.
Same thing happened to me. I could not get System.out.println or Logger.debug either on console.
If you are on a huge project in Eclipse or whatever, you can read below.
Solution: I realized that I had not committed jars and some java files to SubVersioN on network. thats all. Project had not been compiled.
One situation I can think of is to invoke System.setOut(null) (orSystem.setOut(any OutputStream other than System.out or System.err)) then the console, if exists, would show nothing.
I've recently had a horrible problem with QTCreator. After the first time of running the program, ALL debugging instances segfault upon constructing the MainWindow object. Even if i make a blank QTwidget project and run in debug (without editing a single bloody thing), i get a segfault.
This persists after dozens of reinstalls. I have tried both the SDK as well as the IDE and library seperately. The version of the library is irrelevant, i always get the seg fault and its only on my tower. My laptops work just fine.
Does anyone have any possible solutions? Any help will be appreciated.
I needed to run QtCreator in admin mode in order for GDB to function properly.
Without knowing more (please answer to cbamber85's comment), such issues are known to be caused by uberprotectious anti-virus solutions or other software that hooks into places where GDB would usually hook in (Vendor OS-'enhancement' tools are infamous for doing that). This is a known Problem with GDB.
You could try to disable your virus scanner or remove/unload/remove from autostart the vendor tools and try again.
If that doesn't work, the content of the debugger output log pane (Windows > Views > Debugger Log) would be interesting.
I have compiled my freebsd libc source with -g option, so that now I can step in into libc functions.
But I am having trouble stepping into system calls code. I have compiled the freebsd kernel source code with -g. On setting the breakpoint, gdb informs about breakpoint on .S files. On hitting the breakpoint, gdb is unable to step into the syscall source code.
Also, I have tried: gdb$catch syscall open
but this is also not working.
Can you please suggest something?
Thanks.
You appear to have fundamental lack of understanding of how UNIX systems work.
Think about it. Suppose you were able to step into the kernel function that implements a system call, say sys_open. So now you are looking at the kernel source for sys_open in the debugger. The question is: is the kernel running at that point, or is it stopped. Since you will want to do something like next in the debugger, let's assume the kernel is stopped.
So now you press the n key, and what happens?
Normally, the kernel will react to an interrupt raised by the keyboard, figure out which key was pressed, and send that key to the right process (the one that is blocked in read(2) from the terminal that has control of the keyboard).
But your kernel is stopped, so no key press for you.
Conclusion: debugging the kernel via debugger that is running on that same machine is impossible.
In fact, when people debug the kernel, they usually do it by running debugger on another machine (this is called remote debugging).
If you really want to step into kernel, the easiest way to do that is with UML.
After you've played with UML and understand how the userspace/kernel interface works and interacts, you can try kgdb, though the setup is usually a bit more complicated. You don't actually have to have a separate machine for this, you could use VMWare or VirtualPC, or VirtualBox.
As Employed Russian already stated, gdb being in userland cannot inspect anything running in the kernel.
However, nothing prevents to implement a debugger in the kernel itself. In such case, it is possible to set breakpoints and run kernel code step by step from a local debugging session (console). With FreeBSD, such a debugger is available as ddb.
Some limitations would be the lack of connection between your gdb and ddb sessions and I'm unsure source level debugging (-g) is available for kernel code under FreeBSD/ddb.
An alternate and much less intrusive way to 'debug' the kernel from userland would be to use dtrace.