I am trying to teach myself to program in C++ and am using Cygwin on Windows with g++ installed. Everything was going swimmingly until I started to declare string variables. Using string literals with cout causes no issues, but as soon as I declare a string variable the program will no longer run.
#include <iostream>
#include <string>
int main ()
{
std::string mystring = "Test";
std::cout << mystring;
return 0;
}
The preceding code compiles without issue, but when run produces no output. GDB provides me with the following:
(gdb) run
Starting program: /cygdrive/c/Projects/CPP Test/string.exe
[New Thread 8416.0x2548]
[New Thread 8416.0x2510]
[New Thread 8416.0x1694]
[New Thread 8416.0x14f4]
[Thread 8416.0x1694 exited with code 3221225785]
[Thread 8416.0x14f4 exited with code 3221225785]
During startup program exited with code 0xc0000139.
From what I have managed to gather this is some sort of entry point issue with a DLL, but I could be completely wrong.
Does anyone know what I have done wrong or what I have misconfigured and how to fix it?
Well I'm not sure what the problem was exactly (if anyone knows I'd be grateful!), but I was able to solve it for myself by downgrading from GCC 5.2.0 to GCC 4.9.3.
Error code 0xc0000139 is issued when windows is failing to load a dll file.
A possible cause is having several distinct versions of the compiler installed.
This may happen when you install on your PC several SWs that come with embedded mingw - e.g., Visual C, Vagrant, Omnet++.
For me, a simple workaround was to run the program in a different way: Instead of running my SW (Omnet++) from the GUI, I ran it from the mingwenv.cmd command line. This solved the problem.
A smarter solution may be found in the answer of Rudolf from Sep 18, 2017, 11:35:13 AM here. In short, he suggests carefully temporarily changing the system's environment variables; and thus, finding the conflicting erroneous dll's, and removing them.
In the answer of Tian Bin below it you can see Figs. explaining it.
I had the same problem while mixing up a Release and a Debug build, using Windows 10, mingw compilation and gcc-8.1.0.
I solved it by cleaning and recompiling everything:
cd ${MY_BUILD}
make clean
cmake ${MY_SOURCE} -DCMAKE_BUILD_TYPE=Debug
make -j4
gdb ./bin/my_program.exe # -> works
./bin/my_program.exe # -> no more problem
Related
I'm using vscode on Windows, and use mingw-w64 as compiler. my test code are as follows:
vector<string> words = {"SEND", "MORE"};
string result = "MONEY";
when I debug it, I can print 'words' and 'result' object correctly, but when I try to use subscript, something wrong occured:
print words[0] // gdb: Could not find operator[].
and more seriously, when I try print string's subscript, gdb just crashed:
print result[0]
// ERROR: GDB exited unexpectedly with exit code -1073741819 (0xC0000005). Debugging will now abort.
Those errors occurred samely whether debug with vscode or use gdb in cmd shell manually.
However, when I debug on linux platform using gdb, it works perfectly. That makes me confusing. I can't find if there's any bug in mingw, or maybe gdb doesn't support windows platform well. My g++ and gdb version are 8.1.0. I have tried some older version but all those have same problems. Is there any good solution, or shall I just give it up?
Clean your path environment and PY_HOME.
I am new to C++ and want to print out a double value. It is not that I actually need to print that value, I just want to know what is going wrong here.
This is my code (HelloWorld.cpp):
#include <iostream>
int main() {
double i = 5.5;
std::cout << i << std::endl;
return 0;
}
Executing this with the debugger attached results in the following error:
Thread 1 hit Breakpoint 1, main () at src/HelloWorld.cpp:4
4 double i = 5.5;
Thread 1 received signal SIGSEGV, Segmentation fault.
0x00000000929ba260 in ?? ()
When I put a breakpoint in there, creating and assigning the variable is no problem. The error only occurs once the program is supposed to print that value. Executing the exe without the debugger results in no output at all. The same happens when I replace the double with a long double or float. Printing anything else works fine (Strings, char, int, short, etc.).
I am using Visual Studio Code and MinGW (x86_64-8.1.0-posix-seh-rt_v6-rev0). VS Code is using following files for compilation / debugging:
c_cpp_properties.json
launch.json
tasks.json
And here you can see the complete output, in case that helps.
Any Idea what I am doing wrong here? Thank you.
EDIT:
When compiling manually using g++ -g .\src\HelloWorld.cpp -std=c++11 -o HelloWorld.exe (or just g++ .\src\HelloWorld.cpp -o HelloWorld.exe) and running that from the console, the same happens (no output).
I installed MinGW from here using the following settings:
Version: 8.1.0
Architecture: x86_64
Threads: posix
Exception: seh
Build revision: 0
EDIT 2:
Found the problem. There was an old version of gcc lurking in my PATH (maybe from Visual Studio or MSSQL Server?). I just move the current gcc to the top of PATH and now it's working fine. Thank you all for your help!
As many pointed out, this should usually work. The problem was with my setup: I had an old version of gcc somewhere in my PATH variable (version 4.1). Moving the path of the newer version to the beginning of PATH resolves the issue. Thank you all for helping.
To check weather the same happens to you you can do the following: execute g++ --version in your project directory. Compare this with the output of g++.exe --version when you are in the directory where gcc is installed (for me, this was C:\Program Files\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin).
I am trying to run the autoecho program that uses boost::asio and boost::fiber. I am using the following:
Ubuntu 16
cmake 3.9.1
boost 1_65_0
That program depends on a local copy of round_robin.hpp, yield.hpp and detail/yield.hpp. I have downloaded all of those and the program builds successfully. When I run the code, I get a segmentation fault at the line in main that does:
io_svc->run();
Does anyone know if I am doing something wrong, or if the code has an error in it?
I received an email from Oliver Kowalke #boost:
unfortunately, some fixes did not permission to merged into 1.65 (no permission because too late) - you could use branch develop (github) or you need to wait till 1.66is released.
So, until boost 1.66 is released, this code will not work unless you want to use the develop branch.
I'm using gcc 4.9.2 & gdb 7.2 in Solaris 10 on sparc. The following was tested after compiling/linking with -g, -ggdb, and -ggdb3.
When I attach to a process:
~ gdb
/snip/
(gdb) attach pid_goes_here
... it is not loading symbolic information. I started with netbeans which starts gdb without specifying the executable name until after the attach occurs, but I've eliminated netbeans as the cause.
I can force it to load the symbol table under netbeans if I do one of the following:
Attach to the process, then in the debugger console do one of the following:
(gdb) detach
(gdb) file /path/to/file
(gdb) attach the_pid_goes_here
or
(gdb) file /path/to/file
(gdb) sharedlibrary .
I want to know if there's a more automatic way I can force this behavior. So far googling has turned up zilch.
I want to know if there's a more automatic way I can force this behavior.
It looks like a bug.
Are you sure that the main executable symbols are loaded? This bug says that attach pid without giving the binary doesn't work on Solaris at all.
In any case, it's supposed to work automatically, so your best bet to make it work better is probably to file a bug, and wait for it to be fixed (or send a patch to fix it yourself :-)
I have c/gtk+ application and GList which filled three elements, when i try to run following code with gdb:
if (g_list_length(mw->img_list) > 0)
printf(">0");
else
printf("<0");
i see:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb73c4700 (LWP 7936)]
IA__g_list_length (list=0x6e6920) at glist.c:767
767 glist.c: No such file or directory.
in glist.c
What is it?
Thank you.
This is a crash in glib, probably because you're handing it a bad pointer to a list. The debugger tries to load the source code to show you where it crashed, but can't find it (probably because you just linked to the lib, without even having the source handy).
Use the gdb up command to step upwards in the call stack until you reach your code, and inspect the argument you passed to the g_list_length() function.
Your debugger is trying to find the source code for GList to help you to debug the problem. Typically, you won't have the source installed. You'll need to install debugging packages or source of some kind.
If you are on a Fedora system, debuginfo-install glib2 will do it. On Debian or Ubuntu, there may be a package for this, possibly ending in -dbg?
It looks as though its trying to find something(on your hard disk)that doesn't exist. Is that all of the code?