Help with infrequent segmentation fault in accessing struct
Posted
by Sarah
on Stack Overflow
See other posts from Stack Overflow
or by Sarah
Published on 2010-05-18T22:15:14Z
Indexed on
2010/05/18
22:20 UTC
Read the original article
Hit count: 357
I'm having trouble debugging a segmentation fault. I'd appreciate tips on how to go about narrowing in on the problem.
The error appears when an iterator tries to access an element of a struct Infection
, defined as:
struct Infection {
public:
explicit Infection( double it, double rt ) : infT( it ), recT( rt ) {}
double infT; // infection start time
double recT; // scheduled recovery time
};
These structs are kept in a special structure, InfectionMap
:
typedef boost::unordered_multimap< int, Infection > InfectionMap;
Every member of class Host
has an InfectionMap carriage
. Recovery times and associated host identifiers are kept in a priority queue. When a scheduled recovery event arises in the simulation for a particular strain s
in a particular host, the program searches through carriage
of that host to find the Infection
whose recT
matches the recovery time (double recoverTime
). (For reasons that aren't worth going into, it's not as expedient for me to use recT
as the key to InfectionMap
; the strain s
is more useful, and coinfections with the same strain are possible.)
assert( carriage.size() > 0 );
pair<InfectionMap::iterator,InfectionMap::iterator> ret = carriage.equal_range( s );
InfectionMap::iterator it;
for ( it = ret.first; it != ret.second; it++ ) {
if ( ((*it).second).recT == recoverTime ) { // produces seg fault
carriage.erase( it );
}
}
I get a "Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address..." on the line specified above. The recoverTime is fine, and the assert(...)
in the code is not tripped.
As I said, this seg fault appears 'randomly' after thousands of successful recovery events.
How would you go about figuring out what's going on? I'd love ideas about what could be wrong and how I can further investigate the problem.
© Stack Overflow or respective owner