I know that there are a few topics around this subject, however none of them helped me.
I am trying to debug my application using GDB and I am obtaining the error
[debug]Cannot find new threads: generic error
[debug][Thread debugging using libthread_db enabled]
in the function dlopen("my_lib.so", RTLD_LAZY);
The strange fact about this is that it used to work before, when I was compiling under Ubuntu of 32bit architecture. Now, I have moved to a new machine, with 64bit ubuntu installed, HOWEVER, I am giving the compile option -m32 so that the application is still compiled under 32bits. Please don't tell me to try to compile it under 64bit because there are several reasons not to do so.
I have followed the instructions of this topic and still nothing.
Does anybody have a different suggestion?
EDIT: The version of GCC on 32bit machine is 4.4.4 and GDB is 7.2
On the 64bit machine the version of GCC is 4.6.1 and GDB is 7.3
May this have any influence?
Please setup this
LD_PRELOAD=/lib/x86_64-linux-gnu/libpthread.so.0 gdb --args ./app
Related
I upgrade my compiler version from GCC 7 to GCC 11.
When I try to run the process on the machine where I build the binary, I have no issue.
But when launching the process on the production machine I get a crash systemically in a std::list of boost shared ptrs
What's is going on with this machine (same linux distribution version) ?
Could you please help ?
I am attempting to port an application to an arm processor and have run into a roadblock. I don't get to change the source code and it uses a feature that is not available in the arm runtime on the arm host. I get the message on the arm host:
/usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version 'CXXABI_1.3.8' not found (required by MyDaemon);
I ran
strings libstdc++.so.6 | grep CXXABI and got the list with the last element as CXXABI_1.3.6.
Can I simply replace the toolchain/runtime on the arm machine or do I have to worry about other programs that link to it and will not run any longer?
g++ --version gives (Debian 4.6.3-14) 4.6.3
so maybe I can use a 4.9 toolchain and runtime?
The issue with that answer is that when the different libstdc++ is loaded it reports.
GLIBC_2.17 not found
The problem is that the environment on the machine where the application is compiled is different from the environment where the application is run and would like to know where to read to be able to solve this problem.
After making break point in NetBeans IDE, I am faced with problem which show the message <error reading variable: Could not find the frame base for "nn::Layer::Layer(unsigned int, unsigned int)".>.
screenshot
Because of it, I can't read values of variables even types of them.
Any help would be appreciated.
Edit:
I have tried several ways.
downgrade gdb from 7.9 to 7.7.
signing my gdb with codesign -s gdb-cert /usr/local/bin/gdb which did solve Unable to find Mach task port for process-id problem. But doesn't work for this issue.
Using lldb. However, using it even doesn't allow me to make a break point.
My MacOS version is OS X EI capitan 10.11.1.
Gdb is GNU gdb (GDB) 7.9.
NetBeans is 8.0.2.
If there is other version of gdb or NetBeans which works fine, tell me please.
I have written a simple C++ program that I am compiling using g++ in command prompt and also running it through command prompt. The code of my program is as follows:
#include<iostream>
int main()
{
std::cout<<"Hello world"<<std::endl;
return 0;
}
When I run this code. I get a "hello_world.exe has stopped working" kind of error on my office machine. But when I run the same portion of code at home it works fine. Any idea why this is happening? Also, if I remove std::endl it works fine.
I am using Notepad++ to code.
UPDATE: I am not running the same binary on both machines. I compile on both the machines separately. I am using windows 7 32-bit at both the locations. I am using mingw. For compiling I type "g++ hello_world.cpp -o hello_world.exe". For running I typed "hello_world.exe". I downloaded mingw from the site mingw.org and used the "mingw-get-setup.exe" to install. And I installed g++ and gcc through the command prompt using the command "mingw-get install gcc g++".
When you return from main(), your program stops working. In a gui-based environment, I wouldn't be surprised to see a pop-up message warning about a terminal-based application reaching completion where the user has to click "dismiss" before the terminal spawned to support the application is terminated as well. Windows 9x used to have such checkboxes in launcher preferences for MS-DOS programs.
Questions you should use to find out the issue are:
- Is it showing the same error message if you launch the shell yourself ?
- Do you use the very same binary on both machine, and if so, are your machines both capable of running it (e.g. not trying to launch a 64-bit binary on a 32-bit OS as one of the case)
It would help to see the exact text of the error message.
Your program depends on C and C++ runtime libraries. I suspect you have the libraries installed on the machine where it works and don't where it doesn't, probably because you installed Visual Studio on the machine where you wrote the code but not on the machine where you're trying to run it.
You can install the runtime libraries on the second machine by search Microsoft Download for vcredist for the version of Visual Studio that you compiled the program with.
Works fine for me on Windows 7 32-bit using MinGW. I suspect that you've not installed all the components you need to run the program. I would re-install MinGW and Msys and be sure you install all the necessary C and C++ components.
g++ --version
g++.exe (GCC) 4.6.2
a.exe
Hello World
I have used MinGW and Msys on Windows for many years (several different versions) and have never had issues compiling, linking or executing standard C and C++ programs.
For some reason I can't make valgrind work with my Cocoa apllication on OS X 10.6, compiled with Apple GCC 4.2.1... After googling this error I found out that valgrind doesn't work with 64-bit executables, however my application and all the frameworks it uses is being compiled with the -m32 flag and file commmand says ./MyAppName: Mach-O executable i386, Kernel is also i386.
Can somebody please tell me why won't valgrind work then?
By the way, I got valgrind from MacPorts...
Just a note that I had the same problem, but reinstalling with the +universal port option, as in
sudo port install valgrind +universal
made the MacPorts version work for me.
I am using the Homebrew build of valgrind and it works for me. After downloading valgrind it applies some patches, afaik the one discussed here. Additionally, it uses the flags --enable-only64bit --build=amd64-darwin when compiling on 64-bit darwin.
For me also neither the macports build worked, nor did the build that i created my self from the vanilla tar.gz file from the valgrind page. It seems that the provided autoconf script does not support newer macs running in 64-bit mode.
I downloaded latest valgrind v3.6.1 from valgrind.org and compiled it under OS X and it works without any issue.