Hi great C++ programmers,
I've been in this situation many times, but I still don't know how to solve it.
I am programming in C++ in Rstudio, and my program runs into a fatal error which needs me to restart. I want to locate where the mistake is in my code. What I often do is adding some detection lines like:
int main()
{
...code block;
std::cout<<"1.1\n";
...code block;
std::cout<<"1.2\n";
...code block;
std::cout<<"1.3\n";
...code block;
std::cout<<"1.4\n";
return 1;
}
Then I run the code.
The weird thing is, before it runs into "fatal error", sometimes I got "1.1" printed on the console, sometimes I got "1.1" and "1.2", sometimes I got "1.1", "1.2" and "1.3, and sometimes I got nothing.
I guess it has something to do with the operating system because it is the operating system that got the order to print something which would take some time, but meanwhile the CPU was executing forward the code and met the fatal error.
Or, maybe it's the way the codes were compiled that results in such thing?
Is there anyway to solve it? I just want the program to print out everything I asked before it runs into "fatal error".
Thanks!
The compiler optimization could reorder the code, making the printouts unreliable. You are coding C++ in the R environment, and the default g++ compiler optimization is set to -O2. Go to your R directory, search for a file named "Makeconf". Open it with a text editor, locate command "CXX11FLAGS = -O2 ...", erase "-O2", save the file and rebuild your program. Other commands like "CXXFLAGS = -O2 ..." may also need to be modified. Code will run in strictly sequential order by then.
You are using std::cout which is not what R uses, and you get caught up in two different buffering schemes.
Easy solution: use Rcpp::Rcout instead which redirects into R's output stream.
Related
I am making a small system and I want to be able to toggle "verbose" text output in the whole system.
I have made a file called globals.h:
namespace REBr{
extern bool console_verbose = false;
}
If this is true I want all my classes to print a message to the console when they are constructing, destructing, copying or doing pretty much anything.
For example:
window(string title="",int width=1280,int height=720):
Width(width),Height(height),title(title)
{
if(console_verbose){
std::cout<<"Generating window #"<<this->instanceCounter;
std::cout<<"-";
}
this->window=SDL_CreateWindow(title.c_str(),0,0,width,height,SDL_WINDOW_OPENGL);
if(console_verbose)
std::cout<<"-";
if(this->window)
{
this->glcontext = SDL_GL_CreateContext(window);
if(console_verbose)
std::cout<<".";
if(this->glcontext==NULL)
{
std::cout<<"FATAL ERROR IN REBr::WINDOW::CONSTR_OPENGLCONTEXT: "<<SDL_GetError()<<std::endl;
}
}
else std::cout<<"FATAL ERROR IN REBr::WINDOW::CONSTR_WINDOW: "<<SDL_GetError()<<std::endl;
if(console_verbose)
std::cout<<">done!"<<endl;
}
Now as you can see I have a lot of ifs in that constructor. And I REALLY dont want that since that will slow down my application. I need this to be as fast as possible without removing the "loading bar" (this helps me determine at which function the program stopped functioning).
What is the best/fastest way to accomplish this?
Everying in my system is under the namespace REBr
Some variants to achieve that:
Use some logger library. It is the best option as it gives you maximum flexibility and some useful experience ;) And you haven't to devise something. For example, look at Google GLOG.
Define some macro, allowing you to turn on/off all these logs by changing only the macro. But it isn't so easy to write such marco correctly.
Mark your conditional flag as constexpr. That way you may switch the flag and, depending on its value, compiler will optimise ifs in compiled program. But ifs will still be in code, so it looks kinda bulky.
Anyway, all these options require program recompilation. W/o recompilation it is impossible to achieve the maximum speed.
I often use a Logger class that supports debug levels. A call might look like:
logger->Log(debugLevel, "%s %s %d %d", timestamp, msg, value1, value2);
The Logger class supports multiple debug levels so that I can fine tune the debug output. This can be set at any time through the command line or with a debugger. The Log statement uses a variable length argument list much like printf.
Google's logging module is widely used in the industry and supports logging levels that you can set from the command line. For example (taken from their documentation)
VLOG(1) << "I'm printed when you run the program with --v=1 or higher";
VLOG(2) << "I'm printed when you run the program with --v=2 or higher";
You can find the code here https://github.com/google/glog and the documentation in the doc/ folder.
I have a C++ program which works well when I compile with no additional options. However, whenever I use cmake -DCMAKE_BUILD_TYPE=Release there is a very specific part of the code which stops working.
Concretely, I have an interface for a Boost Fibonacci Heap. I am calling this function:
narrow_band_.push(myObject);
And this function does the following:
inline void myHeap::push (myStruct & c) {
handles_[c.getIndex()] = heap_.push(c);
}
where heap_ is:
boost::heap::fibonacci_heap<myStruct, boost::heap::compare<compare_func>> heap_;
For some reason the heap_size is not being modified, therefore the rest of the code does not work because the next step is to extract the minimum from the heap and it is always empty.
In Debug mode it works ok. Thank you for your help.
EDIT - Additional info
I have also found this problem: I have a set of code which do simple math operations. In Release mode the results are incorrect. If I just do cout of a couple of variables to check their values, the result changes, which is still incorrect but quite strange.
I solved the problem. It was funny but in this case it was not initialization/timing issues common in the Release mode. It was that the return statement was missing in a couple of functions. In debug mode the output was perfect but in the release mode that failed. I had warnings deactivated, that is why I did not see it before.
So if I write the following code:
MessageBoxA(0, "Yo, wazzup!", "A Greeting From Earth", 0);
the program crashes with an access violation when it exits. When I write the code like this:
int a;
a = MessageBoxA(0, "Yo, wazzup!", "A Greeting From Earth", 0);
it doesn't crash. Now I know why it crashes when it crashes thanks to another question I asked, also regarding argument-mismatching, but I don't know why it crashes.
So why does this cause an APPCRASH? I was always under the impression that calling a function that had a return-type, without actually giving one was safe, example:
int SomeFunction (void) {
std::cout << "Hello ya'll!\n";
return 42;
}
int main (void) {
int a;
// "Correct" ?
a = SomeFunction();
a = MessageBoxA(0, "Yo, wazzup!", "A Greeting From Earth", 0);
// "Incorrect" ?
SomeFunction();
MessageBoxA(0, "Yo, wazzup!", "A Greeting From Earth", 0);
}
When I run this kind of test "clean" (in a new file) I don't get any errors. It only seems to give an error with MessageBox/MessageBoxA when run in my program. Knowing the possible causes would help me pinpoint the error as the project code is too big to post (and I would need my friend's permission to post his code anyway).
Additional Info:Compiler = GCCPlatform = Windows
EDIT:
UpdateThanks everyone for your feedback so far. So I decided to run it through a debugger... Now Code::Blocks doesn't debug a project unless it is loaded from a project file (*.cbp) - AFAIK. So I created an actual project and copy-pasted our project's main file into the projects. Then I ran in debug mode and didn't get so much as a warning. I then compiled in build mode and it ran fine.Next, I decided to open a new file in Dev-C++ and run it through the debugging and later the final build process and again I got no errors for either build or debug. I cannot reproduce this error in Dev-C++, even with our main file (as in the one that causes the error in Code::Blocks).
ConclusionThe fault must lie in Code::Blocks. AFAIK, they both use GCC so I am pretty confused. The only thing I can think of is a version difference or perhaps my compiler settings or something equally obscure. Could optimizer settings or any other compiler settings somehow cause this kind of error?
The version with the return value does not crash because it had one int more on the stack. Your erroneous code reads over the bounds of the stack and then runs into an access violation. But if you have more on the stack you will not hit the guard page, because that is just enough extra stack. If the the erroneous code only reads it is sort of OK, but still broken.
We had one bit of WTF inducing code that was like so:
char dummy[52];
some_function();
There was thankfully a longish comment explaining that removing dummy, makes some_function crash. It was in a very old application so nobody dared touch it and the some_function was totally different module we had no control over. Oh yea and that application was running smoothly in the field for over 20 years in industrial installations, like refineries or nuclear power plants... ^_^
I have a "black box" question about an error I get when I run a discrete event simulation for about a minute. Everything works fine, and it completes successfully, but the system prints the following message once at some point during the simulation:
Error (202): Command token too long
I've never seen anything like it. I wonder what "command" it's referring to. Perhaps it's system("...") call that I make several times in the program in order to plot and visualize the data it generates.
I'm sorry I can't provide any code as I'm not sure where the error is coming from. Is there an efficient way to discover at which point the system generates this message? Or in any case, have you encountered such an error in your own C++ programming experience, and thus suggest where it could possibly be coming from?
I'm using Ubuntu 11.04 and compiling with GCC. The error appears at run-time during the simulation for simulations that are especially long (30+ seconds), and doesn't appear in shorter cases. I should emphasize that the "error" doesn't stop the execution of the code and doesn't actually cause any visible errors in the visual output of the simulation data.
write a program similar to the following:
int trials 10000;
string str("ls ");
while( trials--)
{
system( str.c_str() );
str += "a";
cout << "chars in cmd = " << trials << endl;
}
It will successively run commands like
ls, ls a, ls aa, ls aaa, while simultaneously printing to the console what trial # it's on.
and if you're right about where the error is coming from, eventually it will get the same error message about "token too long", and if so, tell you how many characters the cmd may be. Then code this limit into your real C++ program so that it doesn't emit the error.
If it doesn't reproduce the error, try making # trials bigger, say up to 100k. If it still doesn't happen, the error is probably coming from somewhere else.
It's coming from a lexer, telling you that one of the tokens (identifiers/preproc tokens/etc.) in your program is rather lengthy. Look through your code to see if there are any ridiculously long strings or preprocessor tokens.
I do some image processing work in C++. For this i use CImg.h library which i feel is good for my work.
Here is small piece of code written by me which just reads an image and displays it.
#include "../CImg.h"
#include "iostream"
using namespace std;
using namespace cimg_library;
int main(int argc,char**argv)
{
CImg<unsigned char> img(argv[1]);
img.display();
return 0;
}
When i give lena.pgm as input this code it displays the image. Where as if i give some other image, for example ddnl.pgm which i present in the same directory i get "Segmentation Fault".
When i ran the code using gdb i get the output as follows:
Program received signal SIGSEGV, Segmentation fault.
0x009823a3 in strlen () from /lib/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.9-2.i686 libX11-1.1.4-5.fc10.i386 libXau-1.0.4-1.fc10.i386 libXdmcp-1.0.2-6.fc10.i386 libgcc-4.3.2-7.i386 libstdc++-4.3.2-7.i386 libxcb-1.1.91-5.fc10.i386
Can some one please tell me what the problem is? and how to solve it.
Thank you all
Segfault comes when you are trying to access memrory which you are not allowed to access.
So please check that out in the code.
The code itself looks just fine. I can suggest some ways to go ahead with debugging -
Try removing the display() call. Does the problem still occur? (I'd assume it does).
Try finding out where in the CImg code is the strlen() that causes the segmentation fault (by using a debugger). This may give additional hints.
If it is in the PGM file processing, maybe the provided PGM file is invalid in some way, and the library doesn't do error detection - try opening it in some other viewer, and saving it again (as PGM). If the new one works, comparing the two may reveal something.
Once you have more information, more can be said.
EDIT -
Looking at the extra information you provided, and consulting the code itself, it appears that CImg is failing when trying to check what kind of file you are opening.
The relevant line of code is -
if (!cimg::strcmp(ftype,"pnm")) load_pnm(filename);
This is the first time 'ftype' is used, which brings me to the conclusion that it has an invalid value.
'ftype' is being given a value just a few lines above -
const char *const ftype = cimg::file_type(0,filename);
The file_type() function itself tries to guess what file to open based on its header, probably because opening it based on the extension - failed. There is only one sane way for it to return an invalid value, which would later cause strcmp() to fail - when it fails to identify the file as anything it is familiar with, it returns NULL (0, actually).
So, I reiterate my suggestion that you try to verify that this is indeed a valid file. I can't point you at any tools that are capable of opening/saving PGM files, but I'm guessing a simple Google search would help. Try to open the file and re-save it as PGM.
Another "fun to track down" cause of segmentation faults is compilier mismatches between libraries - this is especially prevalent when using C++ libraries.
Things to check are:
Are you compiling with the same compiler as was used to compile the CImg library?
Are you using the same compiler flags?
Were there any defines that were set when compiling the library that you're not setting now?
Each of these has bitten me in subtle ways before.