I have some C++ code and try to debug it.
main.cpp:
#include <iostream>
using namespace std;
int main() {
graph<int> a;
a.add(1);
a.addEdge(1,2);
std::vector<int> answ = a.getAdjacent(1);
for (unsigned int i = 0; i < answ.size(); i++)
std::cout<<answ[i]<<std::endl;
return 0;
}
I have a breakpoint on "graph a;". But when I start debugging, I get:
The target endianness is set automatically (currently little endian)
No source file named C:\Users\home\workspace\graphcpp\main.cpp.
[New Thread 3552.0xdc8]
What's the problem?
This seems to be a relatively frequent reoccurring issue when using eclipse +cdt with gdb. Changing the default launcher from GDB (DSF) Create Process to Standard Create Process seems to solve the issue most of the time.
You can find this option under Preferences->Run/Debug->Launching->Default Launchers:
Also make sure you are compiling with -g debug info enabled.
It seems that only with adding the standard parameters to your 'main()' function is enough (I noticed that you're not using parameters in your 'main()':
check this link
I also see this problem. The folks at LinuxQuestions.org helped me make some progress... http://www.linuxquestions.org/questions/showthread.php?t=518283
It appears that gcc 4.1.0 (ie. that in SUSE 10.1, 32-bit) has an optimization where if you don't use argc and argv in the body of main() those symbols are not present in the binary (even with -g and without any special optimization turned on). The 64-bit compiler doesn't do this incidentally.
You get the "Cannot access memory at address 0x0" from the gdb command line if you simply "break main" and print argc in a program that doesn't use argc/argv (and was compiled with gcc 4.1.0). I note your example doesn't use argc/argv.
This is true for C or C++ compilation.
Eclipse is presumably confused by this error in some way when it hits the first break. I was also getting the inability to stop at further breakpoints until I added code to reference argc/argv, or re-declare main (in C++) as "int main(int, char *[])" so that Eclipse wasn't expecting those symbols.
There is still an error in the gdb output window (no symbol "new" in the current context?), but breakpoints can be set.
HTH,
-nick
Related
This code will run on your machine, but not on mine:
#include <iostream>
#include <vector>
using namespace std;
int main(){
vector<int> vv;
vv.push_back(1); //<--- without this, everything works
cout << "X\n";
return 0;
}
The reason, is that it appears my windows machine is missing a (or has a conflicting) specific DLL related to Vectors which is causing my other projects to crash without a report if I use vectors.
However, what's even more entertaining is:
If I comment the push back line, it executes normally without a crash.
Other programs work completely fine as long as they avoid vector, as in using list or an array.
GDB Reports "During startup program exited with code 0xc0000139." Which means it couldn't find the dll it wants. Looking through the dependencies of my executable with Dependency Walker is rather inconclusive, I can't tell what is wrongly missing and what is normally missing among the dlls.
It could also be that there is a second dll that is conflicting with it (like I downloaded two different compilers). Investigating with Process Monitor informs me that instead of using the MinGw64 files located in the MSYS2 folder, the process uses the dlls inside of my ProgramFiles/Git/mingw64/bin location.
So it could be an issue? But Process Monitor doesn't tell me why or what is causing the process to exit unsuccessfully...
How would I get Windows to use the dlls in MSYS2 instead of the Git location? The solution that the post I linked above says is to remove the "erroneous dlls." But I can't just remove dlls that git uses?
Also, how am I guaranteed that switching to the dlls within MSYS2 is going to fix my problem? I just want to use vectors lol, how hard does this have to be?
Other solutions include leaving this spyware infested OS and enter the world of Linux, but that's a huge change.
My C++ Setup INFO :
OS - Windows 10,
IDE - VS Code,
compiler - MinGw
ISSUE :
I recently found sanitizers for C++ to catch some runtime errors like out of bound array access with -fsanitize=address and -fsanitize=undefined in my VS Code environment.
This is a simple program for out of bound array access :
in VS Code terminal being used is CMD when i tried to compile the program with this line g++ -fsanitize=address check.cpp -o main.exe
On hitting enter I got this error ( cannot find -lasan ) :
here is the c++ code ->
// Program to demonstrate
// accessing array out of bounds
#include <iostream>
using namespace std ;
int main()
{
int arr[] = {1,2,3,4,5};
cout<<arr[0]<<endl;
// arr[10] is out of bound
cout<<arr[10]<<endl;
return 0;
}
Cause(s)/Solution(s) for this issue
How to fix cannot find -lasan ?
Does MinGW not support these sanitizers, if so, shall I use cygwin ?
Can I install clang on windows machine (if possible) to use this
whole bunch of sanitizers ?
What are the other options to use besides using Visual Studio
instead of VS Code ??
Any other suggestions
NOTE : kindly suggest me suitable tags for this post (if I have used a wrong one or missed a crucial one)
I am working on implementing a user level thread library in C++ using setcontext(), makecontext(), getcontext(), and swapcontext() on a Linux system.
I am using a wrapper function to wrap the function the user wants to run as a thread. For example, the user calls newthread(funcPtr), and within the thread library funcPtr is passed to a wrapper function that runs it.
The error occurs differently depending on whether or not I initiate an unused string within the function. If I include the line string s = "a"; the program will run to completion, but gdb reveals that context is switching to somewhere within the string library. Without this line, the program segfaults after leaving the function wrapper.
The gdb output shows the corruption of the parameters to function().
I ran valgrind but did not see anything particularly out of the ordinary in the output, just many "Invalid read of size 4" and "Invalid write of size 4" warnings, usually within the C++ standard map.
You could try also AddressSanitizer for debugging. It can detect stack buffer overflows. Here's how to use it on Linux:
At least gcc 4.8 is needed for AddressSanitizer and libasan must be installed (e.g. on Fedora yum install libasan as root). Compile and link with -g -fsanitize=address and run the generated executable. AddressSanitizer stops and emits information if it detects the first error, no long log files have to be analyzed. Solve the reported problem, compile and run again until AddressSanitizer doesn't stop the program anymore. Unfortunately there might be false positives because you use swapcontext in your program, but it's worth a try. Instrumentation can be turned off for a specific function by adding the attribute no_sanitize_address: extern int func(void) __attribute__((no_sanitize_address));
I recently started using CodeBlocks and began encountering odd runtime errors which I have traced back to printing strings using cout <<. For example, even the following..
#include <string>
#include <iostream>
int main()
{
std::string str;
str = "Hi!";
std::cout << str << std::endl;
return 0;
}
results in an error. It will compile fine (using Borland) but when I run it I get a pop up window saying 'test.exe has stopped working' and in the console I get the message:
Process returned -1073741819 (0xC0000005) execution time : 1.526 s
Press any key to continue.
It compiles and runs fine in MS Visual C++ and with G++ in Ubuntu.. any thoughts would be greatly appreciated!
Cheers,
Weatherwax
My one-off comment ended up helping solve the problem so here it is packaged up as an answer for future users:
This guy had a similar issue and it ended up being a linker issue which he
fixed. The fix is the last post in the thread, although reading the
whole thread could be useful for you.
Long Story short: Borland compiler is a bit dated and annoying to use. Ended up being a linker issue within borland. Better off using a different compiler like GCC/G++ or Visual Studio compiler.
This answer is here to elaborate on the root cause of the issue.
The reason for your crashing program is because the wrong runtime library is being linked. Specifically, your example is compiled as a single threaded object file(the default) but the linking step is using the multithreaded cw32mt.lib runtime -- the "mt" suffix at the end means multithreaded.
The solution is to make sure the runtime your program is compiled to use matches with the runtime you're linking against. A few ways to do this.
Important bcc32 compile switches:
-tW Windows GUI program. WinMain() is expected
-tWC Windows Console program. main() is expected. default.
-tWR Use dynamically linked runtime. Absence implies static runtime linkage.
-tWM Use multithreaded runtime. Absence implies single thread.
Compiling your example program as single threaded like this works:
bcc32 -oexample.obj -c example.cpp
ilink32 -ap example.obj c0x32, example.exe,, cw32.lib import32.lib,,
or you can compile it as multithreaded like this(note the -tWM switch matching up with cw32mt.lib):
bcc32 -tWM -oexample.obj -c example.cpp
ilink32 -ap example.obj c0x32, example.exe,, cw32mt.lib import32.lib,,
A third approach that is easier and less error prone is to not call the linker yourself. Instead, let the compiler drive the linker indirectly(similar to gcc):
bcc32 -tWM -oexample.obj -c example.cpp
bcc32 -tWM example.obj -eexample.exe
For your simple example, it can even be shortened to:
bcc32 -eexample.exe example.cpp
Lastly, you can pass the -tW switch multiple times. For example, this command compiles your example as a console program with multithread support and dynamic runtime linkage:
bcc32 -tWM -tWR -tWC -eexample.exe example.cpp
The produced example.exe executable is much smaller and its import table has an entry for CC3250MT.DLL confirming that the borland runtime is dynamically linked.
We should not assume that a non-functioning program is caused by nonconformity to the standard or a bug in the tool we're using without first investigating user error as a potential cause (even though in this case it's tempting to do so). In the OP's case, the code::block IDE didn't have the right commands setup for the toolchain being used.
I am running a very simple C++ program:
#include <list>
#include <vector>
int main(int argc, char **args) {
}
I go to the command prompt and compile and run:
g++ whatever.cpp
a.exe
Normally this works just fine. It compiles fine, but when I run it it says Access Denied and AVG pops up telling me that a threat has been detected Trojan Horse Generic 17.CKZT. I tried compiling again using the Microsoft Compiler (cl.exe) and it runs fines. So I went back, and added:
#include <iostream>
compiled using g++ and ran. This time it worked fine.
So can anyone tell me why AVG would report an empty main method as a trojan horse but if the iostream header is included it doesn't?
UPDATE:
I added a return statement to the main method and now I find that I only get the error if I return 0. Any other return value and it seems to work fine.
What's going on here?
You're not the first person to encounter false positives by antivirus software.
What probably happened is that the antivirus heuristics tripped up on the standard runtime libraries present in your programs, since malware uses them as well. Of course, legitimate software uses them too! The fact that it didn't trip up on iostream probably means that iostream isn't very popular among malware writers.
If you only want to overcome the problem as fast as possible,
just put the folder of the executables into AVG's whitelist.
My preferred steps:
For safety's sake, you should send your executable
to an online virus/malware scanner like these:
www.virustotal.com : VirusTotal - Free Online Virus and Malware Scan
virusscan.jotti.org/en : Jotti's malware scan
if they report 'false positive', then insert the path of the compiled executables
into AVG's whitelist,
so it doesn't scan that folder.
I'm not conversant with AVG, but every antivirus
has an option to exclude files from scan.
If you're brave enough, debug the executable and find the causing call.
An alternative solution may be to virtualize a lightweight linux system,
install gcc (with g++, of course) on it, and use that "g++ dedicated environment"
to
develop your commandline apps.
// The 1st step is a sum-up of this conversation.
// If you send me the source and the 'infected' executable that you compiled, then I'll check it.
// The missing return statement in the (C++) main function means returns 0.