===========
for (int h=0;h<FUT;h++) {
int link=theset->getCurrentPattern(i,posz,h);
if (link!=-1) {
double labweight=thenode->getLabelWeight(L+h);
==> double nodeout=myLayer->getContextualStoredOutput(j,posz,link,
which);
net+=(labweight*nodeout);
}
}//
See the ==>? I call the getContextualStoredOutput funcion many times
and it works flawlessly.
Inside it works like this:
double myClass::getContextualStoredOutput(int node, int x, int y, int
which) {
return nodeVector.at(node)->getContextualOutput(x,y,which);
}
The actual trouble is given by getContextualOutput. In particular when
I pass (0,9,6,2) as parameters, it segfaults.
double myOtherClass::getContextualOutput(const int x, const int y,
const int which)
{
double res=0.0;
if (which==1)
res=trainOutV[x][y];
else
res=testOutV[x][y];
return res;
}
Checking with the debugger, it happens that (0,9,6,2) has become
(13087774 (!),2,2,2) inside the function! And of cours the testOutV
vector raises an out of bounds exception. I guess there should be some
kind of heap corruption somewhere, but I'm really stuck since it all
works through local variables which shouldn't be altered somewhere
else. I hate it since it doesn't happen every time but after a few
repetitions. I really don't know how to fix it...
Thanks in advance!
There are two errors here: an out of bounds exception and a segmentation
fault. Which of the two happens? Is the segfault perhaps a result of buggy
cleanup/stack unrolling after the exception?
Further, you say you checked with the debugger. This only works reliably
when you turn off optimizations. To get a second opinion, e.g. write the
parameters to std::cerr.
> I guess there should be some kind of heap corruption somewhere, but
> I'm really stuck since it all works through local variables which
> shouldn't be altered somewhere else. I hate it since it doesn't
> happen every time but after a few repetitions.
Parameters to functions are rather on the stack than on the heap, just FYI.
That said, you will have to find out how to reproduce the problem. Once you
can reliably trigger the fault, try reducing the code until you have the
bare minimum. Also helpful is tracing function parameters (writing to
std::cout) or inspecting them in the debugger to check if they make sense.
Another thing you can and should do is document assumptions. In a few cases,
you were dereferencing pointers without checking for NULL. If you think to
know that the pointer can never be null, just add the line
assert(ptr);
This is not a function but a macro that checks the value and signals an
error when it is not 'true' in a boolean context. It can be completely
turned off by defining NDEBUG while compiling, so you can also add more
expensive validations there that can be deactivated when you need
performance. Note that this is only for programming errors, not for failures
like e.g. a missing file or an invalid user input.
Otherwise, Francis already said it, it is not possible to work with your
description of the problem as it is.
Good luck!
Uli
What is the value of posz here? Where does it come from?
<snip>
--
Fred K