My workspaces are located in my home directory.
I am currently trying to debug python code which loads a shared C++ library, using Eclipse Oxygen and PyDev. I can debug the Python files just fine.
I run the program (pytest unit test if that matters) with a breakpoint somewhere in the test before the shared library is called (but after it is loaded) and then run a C/C++ Attach to Application debug and attach to the paused python thread. I then set a breakpoint in my C++ code and resume python, and get this from the GDB console output:
No source file named /home/myname/.../models/sourcefile.cpp
Doing an ls /home/myname/.../models clearly shows that that file exists.
I'm not sure if this matters but my library was compiled with CMake where the source and build directory are siblings. E.g. workspace is ~/dev and source is in ~/dev/sourceFolder and build files are in ~/dev/buildFolder
Update:
I was able to attach to the running Python debug thread manually in the console using gdb python <thread_number>. This works and finds my source files just fine, allowing me to debug manually in the console. It would still be much faster and less cumbersome if I were able to get it to work in Eclipse.
Things I've tried in the C++ debug config settings:
In preferences, changing C/C++ -> Debug -> Source Lookup to have
absolute file path first, profile first, and relative file path
first
In CppDebug settings debugger tab, manually added build and source directory to shared libraries
In CppDebug settings source tab, manually added source directory in source lookup path
None of these seemed to do much.
For cmake projects:
The launch configuration can default to the wrong executable, so go to launch configuration => main and check the "C/C++ Application"
Change it from this: build/default/
to this: build/cmake.debug.linux.x86_64/
(you can do this with the "Search Project" button.
This will then pick up the correct debug version and all your source will be found when you debug.
Related
I'm trying to debug an application compiled with Ninja.
I have my source code /usr/local/...project-src/
I have my build output located at /usr/local/...project-src/out/Debug/build
The compiled output includes debug information
file out/Debug/build includes:
ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, with debug_info, not stripped
I'm able to add breakpoints when using relative paths:
cd /usr/local/...project-src
gdb
file out/Debug/build
b x/y.cc:34
# success
Breakpoint 1 at <mem-loc>: file ../../x/y.cc, line 34.
But when I use absolute paths, it fails
cd /usr/local/...project-src
gdb
file out/Debug/build
b /usr/local/...project-src/x/y.cc
# failure
No source file named /usr/local/...project/x/y.cc.
info source prints No current source file.
dir prints Source directories searched: /usr/local/...project-src/out/Debug:$cdir:$cwd
I've also tried:
b ../../x/y.cc, I tried this since that's what the successful command outputs. Surprisingly, it didn't work which is really confusing me.
running gdb from the root directory and other directories.
doing cd to various directories after starting gdb
messing around with set substitute-path and adding directories using dir
I'm hoping the solution is simple, since breakpoints, and variable values, and everything else works, just not with absolute paths.
Also worth noting, once I've successfully added a breakpoint to a file (using the relative path), the other paths also work (both the absolute path and the ../../x/y.cc path).
Lastly, as to why I want absolute paths to work, I'm using CLion's remote-gdb configuration to connect to a gdbserver, and CLion is using absolute paths for whatever reason. Perhaps there is a way to configure CLion to just use the x/y.cc instead? I'm running the gdbserver with gdbserver :2000 out/Debug/build and configured CLion's target remote, symbol file, and sysroot. I've also tried setting the path mappings in CLion.
Edit, testing on a dummy HelloWorld project using g++ -g instead of ninja to build, I'm able to add breakpoints using absolute paths e.g. b /usr/local/...untitled/main.cpp:4. So it seems to be, for some reason, gdb supports full paths for the HelloWorld project built with g++, but not for the real project built with Ninja.
tldr, resolved using gdb --readnow.
Per the comment suggestion I began digging into my build config. 2 things I noticed:
1) The issue disappeared if I built with less debug details. But then I wouldn't be able to inspect expressions & variables. So I thought the issue may somehow related to gdb not having enough memory or cache to load all the debug info. This sounds reasonable since the project source code contains 100,000's of files.
2) As I mentioned earlier, I could add breakpoints using absolute paths after I had added a breakpoint using a relative path to the same file.
I learnt of the info, info set, and info sources commands. Although the outputs were the same between the light-weight debug build and the full debug built (step 1), I noticed that the output of info sources changed in step 2. Before I had added the breakpoint using a relative path, `info sources would list all source files under 'Source files for which symbols will be read in on demand'. But after adding a relative breakpoint, a few of the files (I think the files on the current frame) would be added to the loaded source files.
So I went looking for a way to tell gdb to load all the source files and discovered the gdb --readnow flag (or file <built-file> -readnow with 1 dash -) and though it prints a bunch of warning messages, it seems to resolve my issue.
That being said, I never discovered how to configure CLion to use the readnow flag. The newest EAP (2019.3) release supposedly supports configuring .gdbinit files individual per project, though I haven't tried this. I also don't know if readnow can be configured in a .gdbinit file since it's not a setting. I kind of circumvented the entire configuring CLion issue when I figured how to correctly configure custom build targets and applications in CLion during this investigation.
Edit,
Yet another workaround. If I cd into /usr/local/...project-src/out/Debug which contains the build file (as opposed to /usr/local/...project-src/), then absolute paths work even without readnow.
How can I configure CLion to debug an executable not referenced in a CMakelLists.txt file? OR
How can I configure CLion to debug an executable created using the Makefile plugin?
I am working with CLion 18.2.3 without a CMakeLists.txt file.
I created a configuration from the Application template and named the configuration “Execute”. In the Execute configuration, I specify the executable (main) and the target as All targets. The executable exists (having been built earlier using the Makefile Plugin).
When I attempt to debug or run the Execute configuration, Clion reports,
Error running Execute: Cannot run Execute on <default>.
I am not sure how to get CLion to debug an executable that is in the project directory that is not referenced in a CMakeLists.txt file.
I have a large project which uses the Makefile plugin. This compiles the desired executable beautifully. However, I am not able to debug the executable, set breakpoints, or otherwise use debugging with the executable. I have run this on Ubuntu 18.04 and on Mac OSX High Sierra.
So, either
1. How can I configure CLion to debug an executable not referenced in a CMakelLists.txt file? OR
2. How can I configure CLion to debug an executable created using the Makefile plugin?
Thank you,
John
Here is a copy of the configuration that is being run:
The first image shows the output when this configuration is run, "Error running'Execute': Cannot run 'Execute' on ''"
If you open the drop down menu in the top right of clion and click edit configuration you are able to create custom configurations. There you can add the executable and parameters if required. Now you should be able to run and also debug this executable.
Another option is to run the executable and attach the debugger over the menu entry run->attach to local process (Ctrl+Alt+5) and then select you executable.
I am using a custom build system (not CMake or qmake) with QtCreator 4.6.0 IDE on Linux, though I have both of these plugins installed.
My project is cross-compiled for an embedded Linux device, which I have set up the kit for. It builds fine, but the trouble is in the deployment step, where the custom build system does not tell it the executable file, so it does not know which files to deploy to the device. I have been referring to this page:
http://doc.qt.io/qtcreator/creator-deployment-embedded-linux.html
In my Run Settings page, I have the Deployment section to "Upload files via SFTP", but the "Files to deploy" list is empty (see the first screenshot in the above link). When I attempt to deploy/run, it confirms no files were deployed, as it outputs:
No deployment action necessary. Skipping.
Deploy step finished.
The documentation link first says to "Edit the qmake INSTALLS variable in the project .pro file to add the missing files.", however, my project has no .pro file at all. I created one for fun, and QtCreator has no idea it exists to be able to look at the INSTALLS line anyway, so that doesn't work.
In the "Deploying CMake Projects to Embedded Linux Devices" section at the bottom, it then says "You must specify all other files in the QtCreatorDeployment.txt file that you create and place in either the root directory of the CMake project or the build directory of the active build configuration." So I created such a file in the main project directory, as well as the build directory:
/home/root
build/test:.
The file makes no difference to the "Files to deploy" list, even after restarting. It seems to suggest this method is for CMake anyway. However, I have not even explicitly turned off the CMake building in the Build&Run > Kits, so I would not even know how to start making it build with CMake (and there is no insight from the documentation page: https://doc.qt.io/qtcreator/creator-project-cmake.html). The one thing I did change on the Build Settings page was in the "Build Steps" to do "Custom Process Step" instead of the usual Make step.
How do I add files to the "Files to deploy" list?
QtCreator 4.9 now supports specifying the QtCreatorDeployment.txt file for generic (non-CMake) projects to achieve this.
https://doc.qt.io/qtcreator/creator-deployment-embedded-linux.html#deploying-cmake-projects-to-embedded-linux-devices
https://blog.qt.io/blog/2019/02/21/qt-creator-4-9-beta-released/
I crack my head already, I need to deploy a project. I tried to use InstallShield, it create an msi file, and local installation has no errors, but then when I tried to launch the program it output "debug error". In my settings code generator -> runtime library set for Multi-threaded Debug DLL(/MDd). If I'll set it to Multi-threaded (/MT) it would not compile: "Please use the /MD switch for _AFXDLL builds"
Then I tried to use VS Installer project extension. It creates the msi and setup file, but after I install it, I can't find the .exe file and launch program. What I am doing wrong?
Folder with project files
![enter image description here][3]
Folder with exe file
![enter image description here][4]
At the stage of creating the installer for your program, you have to put all the external files, libraries and resources, that your program needs in order to run correctly, in your program's working directory. When you run the program via Visual Studio, everything works fine since it can find the files, because, as you've mentioned, they are in the project folder, and the project folder is where Visual Studio is looking for them.
When you launch your program outside VS, the program can't find these files since it by default tries to locate them in the folder in which the .exe file being run is located. So, if you wan't to run program outside VS, you need to put all the files needed to your .exe's directory.
For the same reason, while creating your installer, you need to include all the files necessary in the installation target directory together with your .exe. Every installer creator lets you do that.
In general, if you cannot run your program outside any IDE, and you can run it within that IDE, it is a rule of thumb that you should first check if you have included all the necessary files/libraries/dll's/etc. in your program's working directory.
I solved it!!!!!!!!
1)Help to run .exe file, helped updating .uld file in the same directory as a exe file.
2)I used Dependency Walker (http://www.dependencywalker.com/) to find all dll that it's need. And then I create a Setup Project using Wizard at the "Choose file to include" step I add every file and every library that it's depend on! Build->Install-> Then magic, and my application installed and running! Thank you all for your help
On Ubuntu, I have a C++ app in Eclipse. The application compiles fine and I can run the app from the command line.
But when I try to debug it or run it with Eclipse, the error :
"Cannot open shared object file: No such file or directory" is thrown on a shared library.
I've set LD_LIBRARY_PATH in my bashrc file and also set an LD_LIBRARY_PATH environment variable in both the Run Configuration and Debug Configuration to :
/home/behlingb/Documents/api_libs/FileGDB_API/lib
What else am I missing here to get Eclipse to run this?
UPDATE
There is only one shared object file this application requires, and that file is from a 3rd party API download. I just found that if I place the shared object inside the directory the executable is in, it will debug in Eclipse. Is there a way to specify a different directory so I dont have to copy the file for every project?
I'm using the Kepler version of Eclipse.
In Eclipse click on Run then Debug Configurations
Click on the Environment Tab
Click on New
Add LD_LIBRARY_PATH and set its value to the directory containing the library
restart Eclipse
If you have set LD_LIBRARY_PATH and it doesn't work. Close Eclipes and run it from command terminal. I accidentally found that this could make it work. Not sure about the reason, but probably have something to do with Eclipes initialization.
you can use strace utility (and then grep for open and/or stat calls) to get list of .so files required to run smth, then use locate (or find among packages) to find out the actual placement of required lib
According to what #zuafi suggested , you do not have to grep for the libraries and `locate' to find them.
Instead save strace's output to a file:
strace -o my_output_file.txt /path/to/my_executable_file
then open the file, where you can see
open("/a/path/to/some/library.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
scroll down those lines until you hit
open("/real/path/to/some/library.so", O_RDONLY|O_CLOEXEC) = 3 (any value here)
this means before finding /real/path/to/some/library.so there have been several trials to find library.so in different paths. but finally the library has been found in /real/path/to/some/.
Just copy and paste this into your Eclipse!
This is valid with Eclipse Kepler (I have not looked into older versions).
To enable the debugger to load your shared libraries, trying to set LD_LIBRARY_PATH will fail. However the CDT plugin provides a Shared Libraries list for this purpose
Run menu -> Debug Configurations ...
then in the configuration dialog
C/C++ Application -> your project -> Debugger tab -> Shared Libraries tab