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.
Related
I have written a code in that at some point calls an external executable using the system command.
Here is how I do this:
First remove the output files of the external code.
boost::filesystem::remove("Results/CVground.bin");
boost::filesystem::remove("Results/CVground.BUD");
then write input files for the external code. The code is too long to paste here. It just writes few ascii files.
Then run the model. To make things even worse as you can see I'm calling a windows executable under linux using wine.
std::string sim_command = "/opt/wine-stable/bin/wine ";
sim_command.append(cvd.simulationExe()).append(" CVsimAqua.in >/dev/null");
int sys = system(sim_command.c_str());
Essentially the command I'm calling under system is the following
int sys = system("/opt/wine-stable/bin/wine Simulation3.02.exe CVsimAqua.in >/dev/null");
UPDATE:
Based on the suggestion I modified the above command so that it prints to a file as such
int sys = system("/opt/wine-stable/bin/wine Simulation3.02.exe CVsimAqua.in > log.dat");
This is usually takes a couple of minutes to complete.
Then I'm doing a check that the output files actually exists as follows:
if (!boost::filesystem::exists("Results/CVground.bin")) {
std::cout << "\t\tSys output from rank " << rank << " is " << sys << std::endl;
fun.clear();
fun.push_back(10000000);
fun.push_back(10000000);
boost::filesystem::current_path(main_dir);
return;
}
I have found that in some cases I do get the following print in my log file. The rank number is different in each run.
Sys output from rank 78 is 32512
What I don't understand is that the output of system is positive, which I believe it means that the system command was successful. Is there any way to capture more information from the system command?
UPDATE
After I changed the from /dev/null to log.dat I realized that when the system fails it doesn't even create the log.dat file, however I always check with system(NULL) that system is available before calling the system.
I have found extremely difficult to debug this because these errors occur only when I run the code on the cluster.
Is it possible that the system command returns before the execution code finishes? I have seen a definite NO answer to that question but I was wondering if things are getting trickier since I'm calling via wine.
Thank you
The system function returns the exit code from the command you run. By convention, processes return 0 on success and non-zero on failure. What a non-zero exit code means, depends on the application, wine in this case. If may be easier to debug if you don't redirect its output to /dev/null
There are some specific return values for when the system call itself fails: -1 is a process could not be created, and 127 if a shell could not be executed. See man 3 system for the details on those cases.
It's just plain luck my program is so simple, so I eventually found out what causes the mysterious log message. My program log looks like this:
Debugging starts
failed to start
Debugging has finished
Which happens after:
camera = new QCamera(QCameraInfo::defaultCamera());
// see http://omg-it.works/how-to-grab-video-frames-directly-from-qcamera/
camera->setViewfinder(frameGrabber = new CameraFrameGrabber());
camera->start();
The start() method causes this message in console. Now the meaning of the message is obvious, what it's not very helpful. What steps should I take to troubleshoot it?
Reasons for this might differ, but in my case it was simply because I provided invalid QCameraInfo. The culprit is that QCameraInfo::defaultCamera() might return invalid value if Qt fails to detect any cameras on your system, which unfortunately happens even if cameras are present.
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.
Hello I'm interested in learning a way to clear the screen. I'm using C++ but it seem that some possible code to use are only known to work with Windows compilers. I'm using Ubuntu with a "g++ compiler".
code i have research in order to use and have tried...
---This don't work with g++ compiler
system("cls"); error: sh: 1: cls: not found
system("clrscr"); sh: 1: clrscr: not found
I stumble upon this code that it works, i know it prints lot's of lines ...
cout << string(50, '\n');
any cleaner methods that I could possibly use ?
The Unix command for clearing the terminal is clear.
Alternatively, send the terminal codes for doing same (this varies by terminal, but this sequence works for most):
cout << "\033[H\033[2J";
(I got the sequence by simply running clear | less on my system. Try it and see if you get the same result.)
I run the following with Code::Blocks
#include <iostream>
using namespace std;
int main()
{
cout << "Hello, world !!!!!!!";
return 0;
}
Now, there were some questions last night about how I knew my return value. I don't know if it's my version or not, but after the program runs on my version it says "Process returned v (0xv) execution time..." and etc where "v" is the returned value.
Now, here is what I'm asking, and this is as clear as I can make it.
When I run this, it returns value 1993075819 instead of 0. Also, the program doesn't run, all it does is show me the returned value.
Two things worthy of note:
AVG pops up everytime I try and do this, and reports it as a trojan
If I run the code without
cout << "Hello, world!!!!";
It returns 0 like it should and AVG does not pop up
How can I fix this?
(Code::Blocks 12.11)
The problem is not with your code, but with a false positive produced by AVG. The return code 1993075819 is because AVG intercepts the program and does not let it run.
You can report the false positive to AVG. Virus vendors are actually very good at fixing false positives reported by users. When I used to work at a company that produced lots of false positives (security related code that did funky things that triggered false positives), the turn-around was usually about a week.
In the mean time, if you use different compiler switches (e.g. optimized compile if it is not currently optimized or vice versa) there's a decent chance that the code you generate will not trigger the false positive.
You can also add your compiled program to the AVG safe list:
http://www.ehow.com/how_8192066_add-exceptions-avg.html
Disable AVG or configure it not to complain about your executable. For some reason the heuristics are misinterpreting some bit pattern in your executable as if it was a trojan and killing it before it starts. The result code that you get is from the intercepted program call (i.e. the antivirus) not from your program that is not even running.