I'm trying to debug C++ code using gdb. Particularly, I want to check if a certain variable (viscosities[j]) is not NAN and within certain bounds (eta_min and eta_max). I'm doing it using the following code:
if (!crash)
{
if (viscosities[j]>=eta_min && viscosities[j]<=eta_max)
{}
else
{
std::cout<<"viscosities[j]: "<<viscosities[j]<<" ";
crash = true;
}
}
(I need the variable crash because the code part of a loop, it's initialized to 0 before the loop starts).
In gdb, I'm trying to set the breakpoint using the following command:
break nz.cc:238
(line 238 is one with the cout statement)
However, the breakpoint is instead set to line 246:
Breakpoint 3 at 0xaeeb09: file /home/lev/aspect/aspect/source/material_model/nz.cc, line 246. (2 locations)
and the compiler never stops at line 238. I verified the line number through vi and made sure to rebuild the executable. Can anyone please give me an idea of why this might be happening? Thanks in advance!
UPD: solved by disabling optimization during executable compilation
Related
Alright Stack Overflow, I am running into a decently persistent problem in my C++ code. I'm sure this is one of those dumb mistake moments, but I have tried everything and cannot seem to squish this bug.
I have a bit of code here, and it's behavior is very odd. I have a main function that opens a file containing text I want to read in. I was taught in programming fundamentals class at my university that I could use getline() as a condition for the while loop, which is nice since it automatically terminates when it reaches the end of the file.
#include <iostream>
#include <fstream>
using namespace std;
int main()
{
fstream input_mem_traces("gcc.txt");
string trace_to_parse = "";
while(getline(input_mem_traces, trace_to_parse))
{
cout << trace_to_parse << endl;
}
}
When I compile and run it, it works just fine. It reads out every single line of the file I pass it, and returns with no problems.
However, when I try to use gdb, and set a breakpoint at the line
cout << trace_to_parse << endl;
it didn't hit the breakpoint. Curious as to why that was, I broke above the loop, and tried single stepping through the code. When I got to the while loop, and tried to step, it simply skipped to the line after it, which happened to be the end of the program.
This behavior occurs both using the VSCode GUI front end for gdb, as well as straight gdb from the command line. I am running this on Windows using Ubuntu under WSL2, and VSCode as my IDE with the Remote - WSL extension enabled.
Turns out there was some weirdness going on with the working directory with GDB. For some reason, my working directory was changing under the VSCode GUI, thus the file was not able to be opened, and the while loop condition performed as expected for that circumstance by not entering the loop. Upon the recommendation by Retired Ninja in the comments, I used an absolute path in the fstream object constructor, and that solved the issue.
Unfortunately a program I wrote in C++ has a bug (or bugs), yet I can't deduce what it is since only a single output line doesn't match the expected output (the input file has 3K lines of input). I know which input line is the problematic, yet it's over 2K lines into the input file so debugging it manually isn't very efficient.
Is there any way to let the debugger run "alone" with the first 2K lines and stop exactly before trying to execute the problematic input line? I use Windows and eclipse but don't mind switching the IDE or switch to Linux if necessary.
Thanks in advance!
Don't reinvent the wheel!
Eclipse has powerfull feature Enable condition for breakpoint.
Set breakpoint in your code
Right-click on breakpoint - "Breakpoint properties"
Check "Conditional"
Write your condition when breakpoint should be stopped (you have access to scope and global variables)
Here is Eclipse help page. Breakpoint Enable Condition
(with screenshot)
Well, eclipse may well have advanced debugging features, and to tell the truth I do not know the first thing about eclipse, but FWIW you can easily simulate what you want.
What you have is:
for(i = 0; i < lineCount; ++i)
process one line
Add a condition to check the line number and place a breakpoint inside it!:
for(i = 0; i < lineCount; ++i)
if(i == 2000)
{
int x = i*i; //random line, just add your breakpoint here!
}
process one line
Since you know exactly what line is problematic, just a dummy if statement which would check the contents of the line, and if mathces your problem line, do nothing - and put a breakoint at this line.
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.
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.
I am debugging code that looks like this:
while (true){
// do something ...
size_t i = foo(); // <- bp set here
if (flag_set) break;
}
// More code follows here ...
I want to break at the foo() function call, invoke it a few times and then jump out of the while loop completely (lets assume that we are guaranteed that the flag will be set - so we can break out of the loop.
How do I break out of the loop completely?. finish simply runs to the next iteration. What I want to do is to exit the current "code chunk" (in this case, the while loop)
You want the advance command, which takes the same arguments as the break command. Using your code as an example (but with line numbers added):
10 while (true){
11 // do something ...
12 size_t i = foo(); // <- bp set here
13 if (flag_set) break;
14 }
15
16 // More code follows here ...
17 someFunction();
Say your original breakpoint on line 12 was breakpoint 1, and after breaking a few times you wanted to skip to line 17, you would type something like:
disable 1
advance 17
which would disable breakpoint 1 (so it doesn't get hit for the rest of the loop) and then keep executing the program until it hit line 17.
Set a breakpoint before the loop. Then cursor to the foo() call, and use Debug|Run to Line. This is so useful that I have dedicated a function key to it.
Set a second breakpoint after the loop. disable the breakpoint inside the loop. cont. enable the breakpoint again.
I don't know of any easier way.
Try using the jump command. Per gdb help, on this system at least:
jump -- Continue program being debugged at specified line or address
What you need is until command. This is the easiest way to avoid stepping through the loop. From gdb manual:
Continue running until a source line past the current line, in the current stack frame, is reached. This command is used to avoid single stepping through a loop more than once. It is like the next command, except that when until encounters a jump, it automatically continues execution until the program counter is greater than the address of the jump.