I'm writing a program that takes 2 command line arguments: a and b respectively.
Everything is good as long as a <= 17.5
As soon as a > 17.5 the program throws the following error:
incorrect checksum for freed object - object was probably modified after being freed
I've narrowed down the problem down to the following piece of code:
for(int a=0; a < viBrickWall.size(); a++) {
vector<int64_t> viTmp(iK-i);
fill(viTmp.begin(),viTmp.end(),2);
for(int b = 0; b < viBrickWall[a].size(); b++) {
viTmp[viBrickWall[a][b]] = 3;
}
viResult.push_back(viTmp);
viTmp.clear();
}
Removing the latter piece of code, gets rid of the error.
I'm also using valgrind to debug the memory, but I haven't been able to find any solution.
Here it is a copy of valgrind's report:
Report hosted in pastebin
EDIT
I compiled the program with debugging flags:
g++ -g -O0 -fno-inline program.cpp
and ran it with valgrind as follows:
` valgrind --leak-check=full --show-reachable=yes --dsymutil=yes ./a.out 48 10 ``
I noticed the following line:
==15318== Invalid write of size 8
==15318== at 0x100001719: iTileBricks(int) (test.cpp:74)
==15318== by 0x100001D7D: main (test.cpp:40)
Line 74 is:
viTmp[viBrickWall[a][b]] = 3;
and Line 40 is:
viBrickWall = iTileBricks(iPanelWidth);
You're causing an invalid write to heap memory with this line:
viTmp[viBrickWall[a][b]] = 3;
this implies that viBrickWall[a][b] is indexing outside of viTmp at that time. Add
int i = viBrickWall[a][b];
assert(0 <= i && i < viTmp.size());
before the store to viTmp[i] = 3.
HINT: maybe increasing the size of viTmp by one would fix it:
-vector<int64_t> viTmp(iK-i);
+vector<int64_t> viTmp(iK - i + 1);
I don't know the content of viBrickWall so this is just an educated guess from the Valgrind output.
I'm not sure if you're using GNU libstdc++ or libc++ on Mac OSX. If you're using libstdc++ or have a Linux box handy, declare viTmp to be a std::__debug::vector would catch this problem quickly.
Related
I'm trying to use valgrind --tool=callgrind to profile my C++ program on Ubuntu. Here is my code:
#include <iostream>
int main()
{
std::cout<<"hello world"<<std::endl;
return 0;
}
Compile it: g++ main.cpp -g
valgrind: valgrind --tool=callgrind ./a.out
Then I get a file named callgrind.out.1153.
Then I use the tool gprof2dot and the command dot:
python gprof2dot.py -f callgrind -n10 -s callgrind.out.1153 > valgrind.dot
dot -Tpng valgrind.dot -o valgrind.png
However, this png is like this:
For me this is really hard to read.
So is it possible to make callgrind more human readable? For example, can it show me only the execution time of each function of my code or the execution time of my code line by line?
It's not super user-friendly, but I think this does what the OP wants:
callgrind_annotate --tree=both --inclusive=yes --auto=yes --show-percs=yes callgrind.out.${pid} > tree.${pid}
This creates a text file with two sections. The first section is a summary of profiled functions, sorted by the time spent in each. Example of one function:
3,090,761,742,907 (22.39%) < /home/me/proj/src/dir0/file0.cpp:caller0() (79,173,695x) [/home/me/proj/build/reldbg/lib/libzero.so]
768,380,030,255 ( 5.57%) < /home/me/proj/src/dir0/file1.cpp:caller1(unsigned int) (19,814,000x) [/home/me/proj/build/reldbg/lib/libzero.so]
3,861,537,817,283 (27.97%) * /home/me/proj/src/dir0/Abc.cpp:Abc::Abc() [/home/me/proj/build/reldbg/lib/libzero.so]
2,458,035,862,297 (17.80%) > /home/me/proj/src/dir1/file2.h:callee0() (99,049,427x) [/home/me/proj/build/reldbg/lib/libone.so]
1,378,046,252,252 ( 9.98%) > /home/me/proj/src/dir0/file3.cpp:callee1() (99,049,427x) [/home/me/proj/build/reldbg/lib/libzero.so]
The profiled function has the asterisk, its callers have less-than, the functions it calls have greater-than.
The second section is annotated source code, with the amount of time allocated on each line. For example:
--------------------------------------------------------------------------------
-- Auto-annotated source: /home/me/proj/src/dir0/file1.cpp
--------------------------------------------------------------------------------
Ir
-- line 37 ----------------------------------------
7,822,093,316 ( 0.06%) for (uint32 i = 0; i < VEC_SIZE; i++)
. {
21,018,143,872 ( 0.15%) data[i].reset();
110,822,940,416 ( 0.80%) => /home/me/proj/src/dir0/abc.cpp:Abc::reset() (1,910,740,352x)
. }
My code includes the loop that appends two vectors and discards one of them.
Code:
for (int j = 0; j < superpixels[orgIndex].size(); j++)
{
superpixels[dstIndex].push_back(superpixels[orgIndex][j]);
}
superpixels[orgIndex].clear();
std::vector<int>().swap(superpixels[orgIndex]);
However, the Eclipse debugger reads that superpixels[dstIndex].size() is still unchanged after push_back().
In the first case before the code is executed, I have orgIndex = 1, dstIndex = 287, superpixels[1].size() = 191, superpixels[287].size() = 1.
After the loop executed once, I see that the 191 values of superpixels[1] has been successfully appended to superpixels[287] (that is, superpixels[287][191] is not a garbage and equals the former value of superpixels[1][190])
However, the 'Expression' tab in Eclipse debugger still reads superpixels[1].size() = 191 and superpixels[287].size() = 1 (which should be 0, 192 respectively)
The Eclipse debugger console reads:
Name : superpixels[1].size()
Details:0
Default:191
Decimal:191
Hex:0xbf
Binary:10111111
Octal:0277
Name : superpixels[287].size()
Details:192
Default:1
Decimal:192
Hex:0xc0
Binary:11000000
Octal:0300
Why this happens? What should I do to update them correctly?
My Eclipse version is:
Version: Oxygen Release (4.7.0)
Build id: 20170620-1800
Build flag: -c -fmessage-length=0 -std=c++11 -pthread
Please create a Minimal, Complete, and Verifiable example
I am trying to understand possible sources for "stack smashing" errors in GCC, but not Clang.
Specifically, when I compile a piece of code with just debug symbols
set(CMAKE_CXX_FLAGS_DEBUG "-g")
and use the GCC C++ compiler (GNU 5.4.0), the application crashes with
*** stack smashing detected ***: ./testprogram terminated
Aborted (core dumped)
However, when I use Clang 3.8.0, the program completes without error.
My first thought was that perhaps the canaries of GCC are catching a buffer overrun that Clang isn't. So I added the additional debug flag
set(CMAKE_CXX_FLAGS_DEBUG "-g -fstack-protector-all")
But Clang still compiles a program that runs without errors. To me this suggests that the issue likely is not a buffer overrun (as you commonly see with stack smashing errors), but an allocation issue.
In any case, when I add in the ASAN flags:
set(CMAKE_CXX_FLAGS_DEBUG "-g -fsanitize=address")
Both compilers yield a program that crashes with an identical error. Specifically,
GCC 5.4.0:
==1143==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12)
==1143==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes. Perhaps you're using ulimit -v
Aborted (core dumped)
Clang 3.8.0:
==1387==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12)
==1387==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes. Perhaps you're using ulimit -v
Aborted (core dumped)
Can somebody give me some hints on the likely source of this error? I am having an awefully hard time tracing down the line where this is occurring, as it is in a very large code base.
EDIT
The issue is unresolved, but is isolated to the following function:
void get_sparsity(Data & data) {
T x[n_vars] = {};
T g[n_constraints] = {};
for (Index j = 0; j < n_vars; j++) {
const T x_j = x[j];
x[j] = NAN;
eval_g(n_vars, x, TRUE, n_constraints, g, &data);
x[j] = x_j;
std::vector<Index> nonzero_entries;
for (Index i = 0; i < n_constraints; i++) {
if (isnan(g[i])) {
data.flattened_nonzero_rows.push_back(i);
data.flattened_nonzero_cols.push_back(j);
nonzero_entries.push_back(i);
}
}
data.nonzeros.push_back(nonzero_entries);
}
int internal_debug_point = 5;
}
which is called like this:
get_sparsity(data);
int external_debug_point= 6;
However, when I put a debug point on the last line of the get_sparsity function, internal_debug_point = 5, it reaches that line without issue. However, when exiting the function, and before it hits the external debug point external_debug_point = 6, it crashes with the error
received signal SIGABRT, Aborted.
0x00007ffffe315428 in __GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
My guess is that GCC is only checking the canaries when exiting that function, and hence the error is actually occurring inside the function. Does that sound reasonable? If so, then is there a way to get GCC or clang to do more frequent canary checks?
I suspect ASan is running out of memory.
I don't think the ASan errors mean your program is trying to allocate that memory, it means ASan is trying to allocate it for itself (it says "shadow memory" which is what ASan uses to keep track of the memory your program allocates).
If the number of iterations (and size of array) n_vars is large, then the function will use extra memory for a new std::vector in every loop, forcing ASan to track more and more memory.
You could try moving the local vector out of the loop (which will likely increase the performance of the function anyway):
std::vector<Index> nonzero_entries;
for (Index j = 0; j < n_vars; j++) {
// ...
for (Index i = 0; i < n_constraints; i++) {
if (isnan(g[i])) {
data.flattened_nonzero_rows.push_back(i);
data.flattened_nonzero_cols.push_back(j);
nonzero_entries.push_back(i);
}
}
data.nonzeros.push_back(nonzero_entries);
nonzero_entries.clear();
}
This will reuse the same memory for nonzero_entries instead of allocating and deallcoating memory for a new vector every iteration.
Trying to figure out the source of the stack problems was getting nowhere. So I tried a different approach. Through debugging, I narrowed down the above function get_sparsity as the culprit. The debugger wasn't giving me any hints exactly WHERE the problem was occurring, but it was somewhere inside that function. With that information, I switched the only two stack variables in that function x and g to heap variables so that valgrind could help me find the error (sgcheck was coming up empty). Specifically, I modified the above code to
void get_sparsity(Data & data) {
std::vector<T> x(n_vars, 0);
std::vector<T> g(n_constraints, 0);
/* However, for our purposes, it is easier to make an std::vector of Eigen
* vectors, where the ith entry of "nonzero_entries" contains a vector of
* indices in g for which g(indices) are nonzero when perturbing x(i).
* If that sounds complicated, just look at the code and compare to
* the code where we use the sparsity structure.
*/
for (Index j = 0; j < n_vars; j++) {
const T x_j = x[j];
x[j] = NAN;
Bool val = eval_g(n_vars, x.data(), TRUE, n_constraints, g.data(), &data);
x[j] = x_j;
std::vector<Index> nonzero_entries;
for (Index i = 0; i < n_constraints; i++) {
if (isnan(g[i])) {
data.flattened_nonzero_rows.push_back(i);
data.flattened_nonzero_cols.push_back(j);
nonzero_entries.push_back(i);
}
}
data.nonzeros.push_back(nonzero_entries);
}
int bob = 5;
return;
}
and then valgrinded it to find the offending line. Now that I know where the problem is occurring, I can fix the problem.
I have been searching all over and cannot find anything like this. Now, I won't bore you with my whole program. It's incredibly long. But, here's your basic overview:
int main()
{
int i=0;
int h=5;
cout << "h(IS) = " << h << endl;
cout << "testing comment.";
while(i < 10)
{
cout << "I'm in the loop!";
i++;
}
return 0;
}
Looks great, right? Okay, so here's the problem. I run it, and I get a segmentation fault. The weirdest part is where I'm getting it. That testing comment doesn't even print. Oh, and if I comment out all the lines before the loop, I still get the fault.
So, here's my output, so you understand:
h(IS) = 5
Segmentation fault
I am completely, and utterly, perplexed. In my program, h calls a function - but commenting out both the line that prints h and the function call have no effect, in fact, all it does is give the segmentation fault where the line ABOVE the printing h line used to be.
What is causing this fault? Anything I can do to test where it's coming from?
Keep your answers simple please, I'm only a beginner compared to most people here :)
Note: I can provide my full code upon request, but it's 600 lines long.
EDIT: I have pasted the real code here: http://pastebin.com/FGNbQ2Ka
Forgive the weird comments all over the place - and the arrays. It's a school assignment and we have to use them, not pointers. The goal is to print out solutions to the 15-Puzzle. And it's 1 AM, so I'm not going to fix my annoyed comments throughout the thing.
I most recently got irritated and commented out the whole first printing just because I thought it was something in there...but no...it's not. I still get the fault. Just with nothing printed.
For those interested, my input information is 0 6 2 4 1 10 3 7 5 9 14 8 13 15 11 12
THANK YOU SO MUCH, EVERYONE WHO'S HELPING! :)
You slip over array boundaries, causing the corruption:
for (i=0; i<=4; i++)
{
for (j=0; j<=4; j++)
{
if (cur[i][j] == 0)
{
row = i;
col = j;
}
}
}
Your i and j indices must not reach 4.
valgrind is a great tool for debugging memory access problems. It's very easy to use on Linux. Just install G++ and valgrind, and then run (without the $ signs):
$ g++ -g -o prog prog.cpp
$ valgrind ./prog
It will print very detailed error messages about memory access problems, with source code line numbers. If those still don't make sense to you, please post the full source code (prog.cpp) and the full output of valgrind.
I've run valgrind for you, its output is here: http://pastebin.com/J13dSCjw
It seems that you use some values which you don't initialize:
==21408== Conditional jump or move depends on uninitialised value(s)
==21408== at 0x8048E9E: main (prog.cpp:61)
...
==21408== Conditional jump or move depends on uninitialised value(s)
==21408== at 0x804A809: zero(int (*) [4], int (*) [4], int*, int, int, int, int, int, int) (prog.cpp:410)
==21408== by 0x804A609: lowest(int (*) [4], int (*) [4], int, int, int, int, int, int) (prog.cpp:354)
==21408== by 0x804932C: main (prog.cpp:125)
...
To fix these problems, add code which initializes the variables depicted in the error lines above (e.g. line 61, 410), then recompile, and rerun with valgrind again, until all errors disappear.
If your program behaves weirdly even after fixing all problems reported by valgrind, please let us know.
Lines 57 - 67:
for (i=0; i<=4; i++)
{
for (j=0; j<=4; j++)
{
if (cur[i][j] == 0)
{
row = i;
col = j;
}
}
}
at least one of your errors is in this code, cur is declared int cur[4][4]; this means then when j==4 (and when i==4) you are not within the bounds of your array (well you are within the memory for some of them, but not all) valid values will be 0 - 3.
I have been writing a code for a neural network using back propagation algorithm and for propagating inputs I have written the following code,but just for two inputs,its displaying segmentation fault.Is there any wrong withe code.I wan not able to figure it out....
void propagateInput(int cur,int next)
{
cout<<"propagating input"<<cur<<" "<<next<<endl;
cout<<"Number of nerons : "<<neuronsInLayer[cur]<<" "<<neuronsInLayer[next]<<endl;
for(int i = 0;i < neuronsInLayer[next];i++)
{
neuron[next][i].output = 0;
for(int j = 0;j < neuronsInLayer[cur];j++)
{
cout<<neuron[cur][j].output<<" ";
cout<<neuron[next][i].weight[j]<<"\n";
neuron[next][i].output += neuron[next][i].weight[j] * neuron[cur][j].output;
}
cout<<"out["<<i<<"] = "<<neuron[next][i].output<<endl;
}
cout<<"completed propagating input.\n";
}
for(int i = 0;i < neuronsInLayer[next];i++)...
neuronsInLayer[next] is a pointer. perhaps if i knew the type of neuronsInLayer i could assist you more.
That is not anywhere near enough information to debug your code. No info about line numbers or how the structures are laid out in memory or which ones are valid, etc.
So let me tell you how you can find this yourself. If you're using a Unix/Mac then use the GDB debugger on your executable, a.out:
$ gdb a.out
> run
*segfault*
> where
Visual Studio has a great debugger as well, just run it in Debug mode and it'll tell you where the segfault is and let you inspect memory.