class SomeData{};
typedef boost::shared_ptr<SomeData> data_ptr;
class ABC {
public: ABC(){}
~ABC(){cached_ptr.reset(); }
data_ptr get_ptr() {data_ptr x; return x;} // it does work and returns a data_ptr
bool someWork(data_ptr& passed_ptr) {
if(cached_ptr == NULL) {
cached_ptr = get_ptr();
passed_ptr.reset(new SomeData(*cached_ptr));
}
return true;
}
data_ptr otherWork() {
if(cached_ptr == NULL) {
cached_ptr = get_ptr();
data_ptr local_ptr = boost::make_shared<SomeData>(*cached_ptr);
}
return data_ptr; // after some more work
}
private: data_ptr cached_ptr; // class member
};
The above is a simplification of some code that I am trying to get to work.
It did, until I added the "cached_ptr", the ability to cache data between successive calls to avoid calling get_ptr() every single time (it can be fairly big).
Note: I have boost::make_shared and reset() - I experimented with both to see if the error was caused by the copy. It didn't make a difference (As expected).
I already have google test unit tests in place - and when I added the cached_ptr, google test has been giving me errors of the "GTEST_HAS_SEH" kind.
"unknown file: error: SEH exception with code 0xc000005 thrown in the test body."
The error occurs on the destructor: cached_ptr.reset()
;
Visual Studio says:
"First-chance exception at 0x00ceba41 in myFile_gtest.exe: 0xC0000005:
Access violation reading location 0xfeeefeee."
It occurs without it as well (initially I didn't even place a reset(), I thought that a shared pointer kills itself when it runs out of scope.
What could be my problem ?
boost 1.47
Thank you.
void bool someWork(data_ptr& passed_ptr)
should return abool
, but does not return anything. That is undefined behavior. Could you post the real code, or something that represents it close enough for a meaningful analysis? – Andy Prowl May 7 '13 at 18:44SomeData
? – Andy Prowl May 7 '13 at 18:47ABC
. I guess you should prepare an SSCCE – Andy Prowl May 7 '13 at 18:49SomeData
does not respect the Rule of Three, for instance, copy-constructing it may lead to troubles like double deletions. I also see that you are holding child nodes through raw pointers, which suggests that you are doing some manual memory management withnew
anddelete
, and that's pretty error-prone – Andy Prowl May 7 '13 at 18:54