In Qt Creator, Tools, Options, Build & Run, Default Build Properties I can see
Separate debug info (Use Project Default/Enable/Disable)
What that means?
I was guessing it will put debug/release build on separate folders but that seems to happen anyway.
Separate debug info in Qt is typically used when you compile in Profile mode.
Profile mode in Qt is used mainly for analyzing your application and profiling it. This mode creates an optimized binary file (as in Release Mode) with debug symbols in a different file (Debug mode, however, puts the symbols in the same file). This allows you to analyze the optimized application. So, this option in Qt tells the compiler to generate debug symbols in a separate file.
Don't worry. Sometimes Qt Documentation is a little dense and does not explain things in detail. You'll get used to it. Here are some useful links for understanding this:
How it works in gdb: https://guix.gnu.org/manual/en/html_node/Separate-Debug-Info.html
Specifying debug settings in Qt: https://doc.qt.io/qtcreator/creator-build-settings.html
Using performance analyzer in Qt: https://doc.qt.io/qtcreator/creator-cpu-usage-analyzer.html#using-the-performance-analyzer
Related
Currently I'm writing an extension for one proprietary software. Logs unfortunately are not fully available, so this is work in progress. Extension is compiled to DLL using Microsoft Visual Studio 2019, this DLL has dependency on Tensorflow 2.6 DLL. The extension basically loads Saved Model using
LoadSavedModel(session_options, run_options, m_modelDir, { tensorflow::kSavedModelTagServe }, &model_bundle_lite);
and performs inference on images using
model_bundle_lite.GetSession()->Run(inputs_, output_names, {}, &predictions);
Tensorflow DLL was built using bazel according to instructions.
Currently functionally there seems to be no problems, if I compile my extension with Release Configuration. We wanted to check some aspects compiling our Extension with Debug Configuration and utilizing the original Tensorflow.dll. Nothing changes, models are the same, images are the same. But the extension crashes at LoadSavedModel(session_options, run_options, m_modelDir, { tensorflow::kSavedModelTagServe }, &model_bundle_lite);
The errors are not catched with standard catch statements. I cannot debug the code that follows after the model loading.
What could be the reason for this behaviour? I wanted to check the functionality of our code only, I don't want to debug TF functions themselves.
Mixing up debug and release builds can cause serious issues based on the generated code. Debug builds could use some special debug allocators or something else which you do not know.
What you can try to do to get more information about the issue is to attach something like WinDbg and load the model again. This helped me quite often to see if any structured exceptions were thrown during the loading. To do this you have to:
Install Windb (just google for it)
Open it and attach the debugger to your application
Try to load the model
Check the logs and look for any thrown exception
In Visual Studio you can get debug information in "Release" configuration by disabling optimizations and enabling the debug-output; as long as you don't change run-time library and avoid changing preprocessor flags.
So a "Release" configuration can in fact be primarily a "Debug"-configuration.
This can be done on a per-project (and for some settings per-file) basis.
More details in:
https://learn.microsoft.com/en-us/cpp/build/how-to-debug-a-release-build?view=msvc-170
And the /Z7 debug-format may have advantages in your scenario.
But do not try to mix "Debug" and "Release" project configurations, and some library debug settings cannot be disabled in this way.
What software Qt/QML pieces are needed to compile in an app to be able to debug/profile QML?
My current app is build using cmake and runs on a embedded device. Furthermore, I'm starting to use Qt 4.8.3 (until now 4.7.0).
I would like to use these fancy/cool features (for an embedded developer):
http://doc.qt.digia.com/qtcreator/creator-qml-performance-monitor.html
I've searched trough qt-project looking for help, but I haven't got clear what are the steps needed when you want to debug/profile a remote app, with a customize build environment.
So, I would like to know if it is needed any of the following steps, and in positive case, what is in fact the needed code.
Qt libraries ./configure specific options.
QtCreator specific options to attach/launch to remote app.
Cmake includes and libraries needed in the final app executable .
Any help, link, etc is welcomed.
With Qt 4.8 this got pretty easy. All required libraries are now part of Qt itself and you don't have to build the debug library for your Qt version yourself.
I'm developing a Qt/QML desktop application also built with CMake. I had to complete the following steps to enable QML debugging:
Include the debugging enabler into my application's start-up code
#include <QtDeclarative/qdeclarativedebug.h>
/* [...] */
QDeclarativeDebuggingEnabler enabler;
Add QML_DISABLE_OPTIMIZER=1 to execution environment of my application
This can be done within Qt Creator in the execution tab of the projects page.
Tick the checkbox for QML debugging also found in the execution tab
This adds the required command line parameters for the communication between Qt Creator and the QML debugger component embedded in the application
If everything went fine the application greets you with the following output if started in debug mode:
Qml debugging is enabled. Only use this in a safe environment!
QDeclarativeDebugServer: Waiting for connection on port 3768...
QDeclarativeDebugServer: Connection established
After that I was able to set breakpoints and inspect variables. Also the profiler accessible via the analyze page just worked.
Your case is obviously a little bit more complicated as your developing an embedded application.
Qt creator has no support for deploying and executing CMake-based projects on embedded platforms. You will have to do that yourself. Don't forget to pass the required arguments to your application to configure the QML debugging:
$ your-app -qmljsdebugger=port:3768,block
To attach Qt Creator to a remotely running application for a profiling session use the corresponding "External" entries in the "Analyze" menu in the Qt Creator main menu. Where is a likewise option for debugging with "Connect to Debug-Server" under "Debug" > "Debug".
I'm using Qt 5, and it got even easier. Just this one step was required on my side to do QML profiling:
#include <QQmlDebuggingEnabler>
...
QQmlDebuggingEnabler enabler;
Checking the docs all given answers seem to be unnecessary. Further it hardcodes debug code in releases. I have no clue why QQmlDebuggingEnabler would be necessary, but if you check the code here and here, you will recognize, that the instatiation of QQmlDebuggingEnabler is not necessary. Just include QQmlDebuggingEnabler and set the QT_QML_DEBUG flag e.g. like this (CMake)
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -DQT_QML_DEBUG ")
However according to the docs QQmlDebuggingEnabler is not necessary.
Furtermore: profiling unoptimized code makes no sense.
For me setting QT_QML_DEBUG as flag and checking the checkbox for QML debugging is sufficient.
Here is a "cleaner" alternative to #sebasgo's answer, item 1.
If you are using Qt5 with QtQuick2, you only need to define QT_QML_DEBUG before including QtQuick in some file (it does not matter what file, as long as it is a part of the executable). For example, it is sufficient to start your main.cpp with lines:
#define QT_QML_DEBUG
#include <QtQuick>
It won't hurt if you instead use compiler's -DQT_QML_DEBUG flag (e.g. via qmake DEFINES or cmake add_definitions directives), possibly only in debug builds.
If you are stuck with legacy QtQuick1 (in either Qt5 or Qt4) use QT_DECLARATIVE_DEBUG macro instead, e.g.
#define QT_DECLARATIVE_DEBUG
#include <QtDeclarative>
For the curious, here is a relevant Qt source, short and self-explanatory:
QtQuick2
QtQuick1 in Qt5
QtQuick1 in Qt4.8
With Qt 5.1 the new function qInstallMessageHandler was added.
It will let you catch, and log, errors and warnings so you can deal with them as you like.
I am working on modifying a rather large program (NS2 network simulator), and it would be nice to be able to debug it with Eclipse. I configured the makefiles ( add -g to CFLAGS ) to make gcc generate the debugging symbols, and they are indeed generated, but Eclipse refuses to actually find the code associated with those symbols. I imported the HUGE folder of source code using the "Makefile Project with Existing Code", and when I hit "debug" it runs the program. When I tell the debugger to stop, it often stops in a method I recognize, but when i click on the method's name, it says "source not available" even though the source file where the method is defined is actually open in another tab. I do have all the sources imported into the project. Am I missing something in the make configuration?
^long confusing explanation, I know... see screenshot, :
http://imageshack.us/photo/my-images/651/zzz1fu.jpg/
Note that IPKTAgent::deBurst() from the above screenshot is declared in integrated_agent.h -- that is the file I have open in the other tab.
also, when I expand the entry for the executable I'm debugging in the project explorer, it only lists some of the files it is composed of. What gives? (see screenshot, there should be more files on the list, the ones I'm working with are missing).
screenshot: http://imageshack.us/photo/my-images/96/zzz2z.jpg/
Just tested it. Works for me. The only issue was that I forgot to add -O0 option to disable optimization; it can be an issue in your case too.
What I can suggest:
Try to disable optimization
Check that compiler options you use are really applied. You use CFLAGS, but I see c++ in tags, so it is possible that you should use CXXFLAGS (it can depend on build tools you use)
IPKTAgent::deBurst() is declared in integrated_agent.h. But where is it implemented? Check that it is implemented in header and/or you can access to the source file where it is implemented.
Check that you can debug your executable with gdb
Try to create simple automake/autoconf based project and check that you are able debug it in gdb and eclipse. You should be able.
I am an experienced Visual Studio developer who has recently taken on an OSX 10.6 project (a C++ server project with no UI).
I have been successfully debugging the application using the XCode debugger (setting breakpoints, etc.) for months, including debugging the source code for various static libraries that are linked into the final executable program.
However, tonight I was required to debug (with breakpoints) a DYLIB that is also built from our source code, but that is linked dynamically at runtime with the application (the name of the DYLIB is read from an .ini file by the main application).
Unfortunately, the usual method I use of debugging the application (right-clicking the custom executable and selecting "Debug with Breakpoints"), though it does successfully run the debugger and allow me to debug the application (along with its statically linked libraries), exhibits the following undesired behavior when I attempt to hit a breakpoint in the source code for the DYLIB:
-> The XCode debugger reports that the breakpoint was hit in the sense that I see the function and line number in the status bar at the bottom of the XCode windows (along with an indication that this is a gdb message), and the application halts execution. However, there is no stack trace, no variables, nothing - just a completely empty debugger window. The buttons to to "step over", "step into", etc, are disabled. No editor window appears in the debugger (and hence no visual indication that the debugger has stopped on the line indicated). Opening the file by hand does not reveal the debugger hitting the line.
Unfortunately, this is useless for me as far as my attempts to debug the DYLIB.
I have hunted far and wide tonight researching and attempting to find a way for the XCode debugger to successfully hit breakpoints in a meaningful way in the source code for this dynamically linked DYLIB. I have of course done a number of clean/rebuilds. I have made certain that "load symbols lazily" is unchecked and then cleaned/rebuilt. I have restarted, and I have also deleted the "build" directory and rebuilt. I also deleted the user-specific files in the .xcodeproj package. (Note also that I am of course building and running all code, including the DYLIB code, in Development mode with all optimizations off, and generating debug symbols for all.) However, my attempts have been unsuccessful. Nor can I find so much as a single mention of this problem on internet forums.
Any help in instructing me how to use XCode to successfully debug a DYLIB that is linked to my application would be appreciated.
Thanks,
Dan.
Update -
This problem is resolved. It was my lack of experience with OSX that caused me to fail to see this. Despite the fact that my DYLIB project was part of the same XCode project as the executable that calls it, and despite the fact that the DYLIB was built in the same directory as the executable, at runtime the debugged application was not accessing the DYLIB from this location. Instead, it was accessing it from a (different) install location. I have not as of this moment tracked down where the install location is "cooked" into the application, but by copying the final executable/DYLIB into the expected install location and creating a new custom executable that points to the executable in this location, debugging of both the DYLIB and the executable works.
Thanks,
Dan.
What are the 'best practices' when it comes to debugging core dumps using GDB?
Currently, I am facing a problem:
The release version of my application is compiled without the '-g' compiler flag.
The debug version of my application (compiled with '-g') is archived (along with the source code, and a copy of the release binary).
Recently, when a user gave me a core dump, I tried debugging it using
gdb --core=./core.pid ./my_app_debug-bin
The core was created by my_app_release-bin. There seems to be some kind of mismatch between the core file and the binary.
On the other hand, if I try
gdb --core=./core.pid ./my_app_release-bin
the core matches but I am unable to get source code line numbers (although I get the function names).
Is this what is practised? Because I feel I am missing something here.
It sounds like there are other differences between your release and debug build then simply the absence/presence of the -g flag. Assuming that's the case, there is nothing you can do right now, but you can adjust your build to handle this better:
Here's what we do at my place of work.
Include the -g flag when building the release version.
Archive that version.
run strip --strip-unneeded on the binary before shipping it to customers.
Now, when we get a crash we can use the archived version with symbols to do debugging.
One thing to note is that if your release version includes optimization, debugging may be difficult even with symbols. For example, the optimizer can reorder your code so even though the debugger will say you crashed on line N, you can't assume that the code actually executed line N-1.
You need to do some additional stuff to create binaries with stripped debug information that you can then debug from cores. Best description I could find is here
No, you don't miss anything. debug and release are just different binaries, so the core files of release don't match the debug binary. You have to look at machine code to get something from the release core dump.
You probably have to ask your user how the crash happened and collect additional log information or whatever you app produces.