Segmentation fault when not deleting files C++ - c++

I have a program written in C++ that uses a lot the "system" function to run things like i would run in Shell (using Ubuntu 12.04 32 bits).
The things done in the "system" function generate several files that will be processed. In a second part of the program i process those files.
When the program ends, it doesn't delete those files that was generated by the "system" functions.
When i run the program for the first time it runs fine, when i run in a second time it gives me Segmentation fault (core dumped) in a given loop of the second part. It does less iterations each time i try to run. For example : First run = ran fine. Second run = Segmentation fault(core dumped) in iteration 200. Third run = Segmentation fault(core dumped) in iteration 199. And goes on...
I resolved the problem deleting all files it had generated by "system" function in the end of each "run" of the program.
My question is...any one has any clue about why was it happening?
EDIT*
Below is a few pseudocode to exemplify.....unfortunately i cant put the entire code, its like 600 lines.
int main(void){
// Part 1 of the program.....severam "system" producing files
system("bash produceSeveralFiles.sh");
// Part 2 of the program......process files produced in part 1
processFiles();
// My Solution that i dont know why solves it
system("rm AllFiles");
return 0;
}
EDIT*
Way i checked that it goes until the loop...
for(int i = 0; i < 300 ; i++){
printf("\n%d",i);
...//a few code here
printf("\n%d",i);
}
Second run i see "i" goes until 200....third run i see "i" goes until 199....and go on...thats the way i checked where it was giving the Segmentation Core (dumped).
EDIT*
O well im ashamed now, just checked the old Script that was generating the files before the program and it gives the same problem....if i do the generation in a separated file and then only runs the "processFiles()" in the program, it gives the same error. The old Script has an "rm files" command in the end that wasnt concerned about. (thx to user #beta....just checked the old script cause your commentary)
Well....but anyway the question continue, but now i know its not only with the "system" function.

Related

What things can cause GDB to error before hitting main?

I have a program with a large codebase, so I can't share a minimal example. What I've done is removed everything from main so that it looks like this:
int main()
{
std::cout << "here" << std::endl;
return 0;
}
But I'm still including all of the header that I was including before. When I run the debugger (GDB 9.2) it breaks before hitting main (I've a breakpoint set on the std::cout) with the following:
Starting debugger: C:\GameDev\Tools\MSYS2-32\mingw32\bin\gdb.exe -nx -fullname -quiet -args C:/GameDev/Colony/bin/Colony.exe
done
Setting breakpoints
Debugger name and version: GNU gdb (GDB) 9.2
Child process PID: 6840
In ?? () ()
Which I understand means something has happened during initialisation? I looked at this question Debug error before main() using GDB and did as suggested, printed the info file info file and set a breakpoint manually on the entry point and running it again. That doesn't seem to give me any additional info (same as above); or maybe I don't know what I'm looking for and how to retrieve it.
I've tried running the program through Dr Memory but it seems to execute okay in there, up until shutdown at which point after leaving Dr Memory gives me no errors but 2 suspected false positives. Both of these look like they're pointing to MingW hashtable code, which I believe is from my use of std::unordered_map in a few places (the only place where that hashtable code would come in). But none of that code is invoked because main is effectively empty.
None of that code is statically initialised either.
So, what sort of things can cause this error? I can try and track down the offending code if I know what can do it.

Matlab system() running C++ Executable

I'm having some trouble getting Matlab to run an executable file. Essentially, I have a C++ code that does some calculations and outputs these calculations to a text file; then, Matlab reads these text files and uses the calculations to makes plots and stuff.
I've been trying to get Matlab to run the C++ exe file so that, when it runs it, the output files are automatically generated and Matlab can start doing its stuff. This just allows the user to run the program quicker. I am using the system() command Like so:
system('MyCppProgram.exe');
However, when I run that, although everything compiles, nothing is outputted from CPP and I even get back something that says "ans = -1" and I have no idea what that means.
Any help would be greatly appreciated. Thank you!
Update: Result from test command.
[status, cmdout] = system('MyCppProgram.exe', '-echo');
status = -1
cmdout = ''

Why does my C++ program crash with exit code 11 when I remove a cout statement?

In my C++ project, I encounter a very strange issue. It crashes with exit code 11 when I remove a certain log statement (cout).
This answer points to a source that explains exit code 11 (actually EAGAIN) with the following statement:
The system lacked the necessary resources to create another thread, or
the system-imposed limit on the total number of threads in a process
PTHREAD_THREADS_MAX would be exceeded.
But I am pretty sure don't create any additional threads in my code (at least not explicitly). So why does the error occur and why does it go away when I use the log statement?
For reference, I will post the code but it's of course completely out of context and basically the only relevant line is the one with the log statement.
PayloadRegionMapper(string mappingTechniqueName, string configPath = "")
: payload(PAYLOAD), config(Config(configPath)) {
cout << "construct PayloadRegionMapper" << endl; // if commented out, my program crashes....
frames = generateFrames();
setMappingTechnique(mappingTechniqueName);
}
Run the program using a debugger and then backtrace once the crash happens.
Using the bt and frame command you can get an idea about the behaviour of the program during the crashing situation.
gdb <executable>
.....<crash happened>
bt
<It will give you the stack frame >
frame <frame number>
Then look for the values and memory area there.

Print to locate the error code block

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.

C++ Error (202): Command token too long

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.