Stack Overflow is a community of 4.7 million programmers, just like you, helping each other.

Join them; it only takes a minute:

Sign up
Join the Stack Overflow community to:
  1. Ask programming questions
  2. Answer and help your peers
  3. Get recognized for your expertise
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.

share|improve this question
1  
Your function void bool someWork(data_ptr& passed_ptr) should return a bool, 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:44
    
Sorry about that. – Thalia May 7 '13 at 18:46
    
Also, what is the definition of SomeData? – Andy Prowl May 7 '13 at 18:47
1  
Another thing: the problem may be in the way you are creating or working with ABC. I guess you should prepare an SSCCE – Andy Prowl May 7 '13 at 18:49
1  
Well, if your SomeData 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 with new and delete, and that's pretty error-prone – Andy Prowl May 7 '13 at 18:54
typedef boost::shared_ptr<SomeData> data_ptr;

data_ptr get_ptr() { data_ptr x; return x; }

  cached_ptr = get_ptr();
  passed_ptr.reset(new SomeData(*cached_ptr));

get_ptr() returned a NULL pointer, and then you dereferenced it.

You never set cached_ptr to anything other than NULL, but that's a separate issue.

share|improve this answer
    
Sorry, I thought my comment explained that get_ptr() does a lot of work and then returns the results of that work. It is not null, and the code does work without the cached_ptr. The comments from Andy Prowl show that I did not have a copy constructor - the class I was using did not have one, and I thought I might not need it. The addition of a copy constructor solved the problem. – Thalia May 7 '13 at 22:23
    
@Thalia Ah, thanks for the clarification. I understand now. I thought you meant work (verb) but you actually meant work (noun). – Oktalist May 7 '13 at 22:27

you dereferences null pointer (*cached_ptr) in the following fragment:

cached_ptr = get_ptr();
passed_ptr.reset(new SomeData(*cached_ptr));

so your program becomes illformed. in this case you cannot do any expectation.

share|improve this answer
    
Sorry, I thought my comment explained that get_ptr() does a lot of work and then returns the results of that work (as a "data_ptr", created in that function). It is not null, and the code does work without the cached_ptr. The comments from Andy Prowl show that I did not have a copy constructor - the class I was using did not have one, and I thought I might not need it. The addition of a copy constructor solved the problem. – Thalia May 7 '13 at 22:25
up vote 0 down vote accepted

As Andy Prowl noticed (in comments to my question), the class the pointer was pointing at did not contained a copy constructor.

boost::make_shared requires a copy constructor in order to make a copy...

In its absence it pointed at the same data, so when the original pointer went out of scope, the cached one lost its point (even though, when debugging, it looked like it still had it...)

Adding a copy constructor for SomeData solved the problem.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.