8

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?

Zell Faze
  • 1,815
  • 2
  • 14
  • 16
  • 1
    Your code compiles fine and provides the expected output, 'Test', for me on Windows 10 using gcc 4.8.1. Are you experiencing the same problem with other C++-programs or is it in any way related to the code you provided? Also, which compiler flags are you using to compile the code? – JonatanE Nov 28 '15 at 09:07
  • I haven't played around with it too much, but I can get other code to compile. Declaring a string variable seems to be what causes the problem. I haven't tried declaring variables of any other classes so I'm not sure if it is an issue with string or classes in general. I am using GCC 5.2.0-1 on Win10 downloaded with the Cygwin installer. I'm not sure what flags I use, likely the default. I compiled it with g++ -g string.cpp -o string.exe – Zell Faze Nov 28 '15 at 09:15
  • I changed the installed version of GCC to 4.9.3 and my programs now compile and run properly. How strange... – Zell Faze Nov 28 '15 at 09:22
  • You might have updated the GCC but kept the libraries at version 4.9.something, they are separate packages. Binary compatibility is fragile. – Euri Pinhollow Feb 06 '17 at 23:41

5 Answers5

3

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.

Zell Faze
  • 1,815
  • 2
  • 14
  • 16
  • 4
    You may be able to use a tool like Dependency Walker (http://www.dependencywalker.com/) to diagnose problems with missing DLLs. – Michael Burr Nov 28 '15 at 09:52
  • I was running VS Code 1.68.1 from a Git Bash prompt ~v2.3 but not the latest which at this time is 2.37), and using MSYS Mingw64 GCC 12.1. I like running VS Code from the Git Bash prompt because then I can use git bash from within VS Code as the default shell with env vars. I had the gdb 0xc0000139 error as well when trying to debug a program. When I ran VS Code stand alone outside Git Bash it worked. Then I upgraded GitBash with the command "git update-git-for-windows". That took me to Git version 2.37.0.windows.1. Now I can run VS Code from Git Bash and use gdb successfully – Dave Guenther Jul 04 '22 at 02:50
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.

Itamar cohen
  • 59
  • 1
  • 5
0

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
PJ127
  • 986
  • 13
  • 23
  • I know that this thread is a little bit older, but I ran in the same error 2 days ago when compiling a wxWidgets application. The fact that it was running on one machine without problems, but not on the other, finally led to the solution: wrong entries in the PATH resulting in wrong dlls used. Simple cause, big effect... – Ultra Junkie May 29 '23 at 13:52
0

Answering because I don't have the rep to comment - to expand on @Ultra Junkie's comment, I had this issue with a newly-installed copy of MSYS2, just trying to compile helloworld in C++. I used Sysinternals' Process Monitor to look at all system call by my failing helloworld.exe, and discovered that it was finding a version of libstc++6 from an installation of QEMU, and not from C:\msys64\ucrt64\bin, which helloworld was expecting. I deleted QEMU, and helloworld immediately started to run correctly. Not sure what I'll do when I next need QEMU, but yes, the problem can be caused by a program finding an incompatible version of a DLL that it is searching for.

Dave Atkinson
  • 46
  • 1
  • 5
  • This does not provide an answer to the question. Once you have sufficient [reputation](https://stackoverflow.com/help/whats-reputation) you will be able to [comment on any post](https://stackoverflow.com/help/privileges/comment); instead, [provide answers that don't require clarification from the asker](https://meta.stackexchange.com/questions/214173/why-do-i-need-50-reputation-to-comment-what-can-i-do-instead). - [From Review](/review/late-answers/34691461) – Jesper Juhl Jul 21 '23 at 11:29
  • Um, okay, can you explain why this doesn't answer the question? Poster asked a question, I experienced the same problem and fixed it. So I detailed how I diagnosed the problem, what I diagnosed the problem to be, and how I fixed it. Please explain which which part of that isn't useful, and I'll willingly delete the post myself. – Dave Atkinson Jul 21 '23 at 16:14
0

This happened to me after an installation of git.
C:\Program Files\Git\mingw64\bin ended up having the highest priority in my environment variables.

Basically any test program would take the wrong lib libstdc++-6.dll, so moving my msys64 path C:\msys64\ucrt64\bin to the highest priority fixed the issue for me.

disservin
  • 83
  • 1
  • 6