I'm really lost in here. Maybe some of you can point me to a right direction.
I'm developing a tool in ANSI C using GCC over MinGW. The tool is to be run only from command line. Probably only on windows machine. It elaborates some data locally and generates files for use by other programs. Basically it does a lot of math and a few file handling. Nothing really fancy. I didn't find it necessary posting the whole 1000+ lines here for examination...
I compile it with GCC -ansi making sure not even a single warning is present. Everything worked always well as the development evolved. But recently I started getting (almost) random segfaults. I checked for the last changes made, but found nothing. I removed the last changes completely coming back to when it perfectly worked. Still segfaults. I traced line by line. I went back to read and re-read the whole code searching for possible pointers/malloc errors. I simply can't find the reason for it to fail so often and so randomly.
So here is the strange thing - I compiled it with -g and run through GDB.
start MSYS
change dir where the program resides
$ gdb generatore.exe (the one compiled -g that fails)
$ run
And it perfectly works inside GDB. I went step by step. Line by line. Perfect. I tried stressing it with huge amounts of data. All works. Can't reproduce the error. But if the same executable is run from command line, it fails.
I suspect an unpredictable behavior with some pointer but I cannot find it anywhere.
Has anyone ever encountered anything similar? Where should I be checking? Also, I am not as familiar with GDB, since it runs smoothly, can I enforce the control somehow to find the reason it fails? Are any other free debugging solutions for windows you can advise me? How can I debug for unpredictable behaviors?
Thanks a lot for your attention,
maxim
There is a great free tool for catching all kind of runtime errors to do with pointers, memory allocations, deallocations, etc., which cannot be caught at compile time, so your compiler will not warn you about them: valgrind http://valgrind.org/. The problem is, AFAIK it doesn't run on Windows. However, if your program is pure ANSI C you should be able to build it and run it with valgrind on a Linux box.
I'm not 100% sure about it, but it should run OK in a virtual machine, so if you don't have a separate Linux computer you can try installing e.g. Ubuntu in Virtual Box or VmWare and try running your program with valgrind in it.
Related
Hello everyone I have finally decided to learn to code, even if it is just a hobby, I once picked it up years ago and I am gong through the tutorials on codeacademy, I have a question for everyone.
Tonight I downloaded Codeblocks with Ming compiler, the programs work fine, the ones I have tried to rewrite from memory from my lessons, but I am missing something that became second nature during my lessongs. After writing the code required for the challenge, I would go into a folder with the extension .cpp and add the command g++ temperature.cpp(for example) -o temperature and then once the a.out file was created I would go into that and do the ./temperature command to execute the program.
I like being able to manually compile and than executre my code, and would like to be able to do this in codeblocks. I know it may sound stupid, and I know Codeblocks does it for me, but is there any way, I can do it for myself? Is there any way I can write my code and have the terminal on the right side of the screen like codeacademy has it?
Or should I just forgot about the g++ and ./ commands? I figure that I can do it throug the command prompt but that would require getting to the folder etc, and have not yet fully familiarized myself with the command prompt.
Thank you in advance for the help.
I first commented, then I decided to make it a full answer, since I kind of answered the heart of the question in the comments by accident anyway.
Yes, you can absolutely do this yourself. Using an IDE (Integrated Development Environment) like Codeblocks will make things easier for you, but there is no harm in learning how to do it under the hood if that interests you--especially if you're doing this for a hobby and not a work situation with time constraints.
To understand what g++ is fully capable of, I recommend consulting the official documentation. That will explain how to properly use it better than me and probably anyone else could.
While you're at it, I would also recommend learning how to use make if your platform supports it. It is a tool that can make compiling easier than working with the compiler directly, but offers more control than your IDE might (though this depends on the IDE).
You mentioned that you used the Ming compiler for Codeblocks, so I'm assuming that you're on Windows. To use the g++ command here, you'll have to
Add it to path, in order to make the g++ commands available for you throughout the system. This video explains adding the ming compiler to the path pretty well.
Call the command (from the command prompt, or some other kind of terminal)
You will have to get just the basic commands down for the command prompt, but it's not that daunting. cd to change directory and dir to list directory, and navigate to your project directory in codeblocks.
Finally, keep in mind that because you're on windows, when you compile with g++ you'll get an .exe file. .out files are produced when you compile on linux. If you want to get a linux shell on windows, I'd recommend looking into either Cygwin or WSL.
IDEs make compiling and executing much more convenient, but it's not a bad idea to learn how it all works through the command line. Best of luck!
I am using Plato IDE from Silverfrost FTN95 to run programs on Fortran as well as C++. But for the last 2-3 months, I was busy and could not use them. So, yesterday when I opened the IDE and viewed some earlier written programs, I saw that the programs were not running properly.
The compiler was working and each time, the compilation was completed with no errors.
The executable was also built successfully but it just showed the following:
Also, on clicking "Run to Cursor" on any line of the program, it mentioned the following error.
What is wrong? And how do I make things work right? Do I need to uninstall and reinstall?
I could not realise what was wrong, in any way possible. So I uninstalled it and then performed re-installation. Things are working so fine now.
I need to run a rather large software package on a new machine for work. The application is written in C and C++ and I am running on CentOS 6.5.
The program builds fine, but segfaults when I go to run it. Using valgrind, I see the following error reported at the location of the segfault:
==23843== Invalid read of size 4
[stack trace here]
==23843== Address 0x642e7464 is not stack'd, malloc'd or (recently) free'd
So for some reason we are reading from memory we aren't supposed to and are invoking undefined behaviour. When I tar up my source files, take them to another CentOS 6.5 machine (w/ same kernel) and compile them (with same makefiles and same GCC version) the program seems to run fine.
I ran valgrind on that machine as well and expected to see the invalid read again. My thought was that the invalid read would always be present, yet because the behaviour is undefined things just happened to work correctly on one machine and not on the other.
What I found, however, was that valgrind reports no read errors on the second machine. How could this be possible?
Valgrind makes the running environment more deterministic, but it does not eliminate all randomness. Maybe the other machine has bit different versions of libraries installed, or anything external it is using (files, network..) is different, the code execution does not have to be exactly the same.
You should look at the stack trace and analyze the code where the error happens. If it is not obvious from the stack trace alone, you can start valgrind with --vgdb=full parameter. It will pause the execution once the error happens and print out instructions how to attach gdb. Or you can just run the program under debugger directly - you wrote that it crashes even without valgrind.
Different library versions are the best guess, judging from the sparse information you gave. Things to try:
1) Bring both machines up to date via package manager and try again
2) Run ldd [binary] to see all libraries used by the program in question. Run something like md5sum on them on both machines to find out if there are differences.
In general I made the experience that valgrind is really bad at detecting invalid memory access on the stack, so this might be a hidden root cause. If all else fails, you might want to try using clang and address sanitizer. It might find things valgrind doesn't catch, and vice versa.
This could be caused by using different versions of Valgrind.
Some common false positive errors get removed in newer versions. Which would explain why one machine complains about it (older version) and another one doesn't (newer version).
I have a program that I have written in C++ under linux (Ubuntu 10.10).
The programming and debugging worked perfectly until the moment I added the following lines to the code:
mapfile = fopen(map_filename,"wb");
fwrite(map_header,1,20,mapfile); // <-- this is the problem line
fclose(mapfile);
After I added those, the program compiles ok, but the debugger now won't start. It immediately fails with this message:
Program completed, Exit code 0x177
error while loading shared libraries: unexpected PLT reloc type 0xcc
And if I remove the line with the "fwrite", the debugger will start normally.
This problem only happends inside Netbeans.
When I debug it using the command-line "gdb" it also works ok without any problems.
Anyone have idea why its happening and how to fix it?
P.S: Those problems started recently so I assume maybe it has to do something with system updates, I'm not sure.
Found the problem:
Not long ago, I removed some old C++ projects from netbeans. It figures out that netbeans (at least v7.0) remembers all the breakpoints that I put on old projects that don't even exist in the IDE anymore.
I found this by looking at the Debugger Console (Window->Debugging->Debugging Console) and seeing that when "gdb" starts, it tries to setup all these breakpoints from other projects or from projects that do not exists (this is a bug in netbeans, btw)
The solution: I simply cleaned all the breakpoints (inside Window->Debugging->Breakpoints) and now the program can be debugged properly.
Hope this will help to anyone out there who has the similar problem.
I'm running a c++ program from R using Rcpp and RcppArmadillo. My OS is windows 8. I use the cxxfunction to compile my code (Later I'll make a package directly instead, but for now I'm clueless about how to make a package). The issue is that R often crash while running my c++ code. There must be some segmentation faults because often it doesn't exactly crash at the same spot even with the same seed. Currently, I'm printing out stuff to the prompt but I feel like this is not the most efficient way to debug my program.
So I read a bit about how to debug c++ code in R and it seems that gdb is a good way to do it. So I downloaded mingwin32 which contains gdb for windows. When I run R using gdb it works fine and I can run all my code fine but when R crash gdb backtrace function returns 'no trace'. I have no idea why. I heard people say to add the option -g -Oo in the compilation, but I'm using cxxfunction to compile my c++ program and I don't know how to compile manually things in R. I also heard some people talk about changing cxxflags but I don't really understand what that is and how to change it.
So my questions are :
Should I use gdb or something else?
How do I get gdb to work with my R program?
Should I install linux on a separate partition to make everything simpler?
Thanks for the help.