Crash when I pass a unique_ptr or shared_ptr to a thrid party function that takes a reference to the pointed to object

Question

I am not sure if I can produce a compile-able example because my issue is a call to a third party library so its difficult to see what is happening (unless you have RTI DDS installed). But I will try to make it as complete an example as I can:

I am using RTI DDS library with C++11. Here is a code snippet that would work:

#include <dds/dds.hpp> // the RTI libs
int main()
{
    dds::domain::DomainParticipant participant(0); // 0 is domain_id
    dds::topic::Topic<MyTopic> topic(participant, "example");
    dds::sub::DataReader<MyTopic> *reader = new dds::sub::DataReader<MyTopic>(dds::sub::Subscriber(participant), topic);

    // Now pass the dereferenced reader pointer to the status condition c'tor
    dds::core::cond::StatusCondition condition(*reader);

    return 0;
}

So this is just a snippet that works, but I would like to have my status condition to be a member variable so that it lives within a class scope and I can use it in various places. I also want to use smart pointers for their auto-destruction properties.

But if I use a unique_ptr instead of a raw pointer I get an error - so I assumed this was because unique_ptr has some protection from being copied or such.

So I thought maybe a shared pointer might be useable here:

#include <dds/dds.hpp> // the RTI libs
int main()
{
    dds::domain::DomainParticipant participant(0); // 0 is domain_id
    dds::topic::Topic<MyTopic> topic(participant, "example");
    std::shared_ptr<dds::sub::DataReader<MyTopic>> shared_ptr_reader = std::shared_ptr<dds::sub::DataReader<MyTopic>>(new dds::sub::DataReader<MyTopic>(dds::sub::Subscriber(participant), topic));

    // Now pass the dereferenced reader pointer to the status condition c'tor
    dds::core::cond::StatusCondition condition(*shared_ptr_reader); // <-- Crashes here

    return 0;
}

This crashes - throws a low-level RTI exceptpion, the stack trace is really not helping me since its deep in the guts of the RTI library :(

The API for the constructor of StatusCondition is here:

dds::core::cond::StatusCondition::StatusCondition  ( const dds::core::Entity &  entity )  
 inline

Obtains a reference to the StatusCondition in an entity. Parameters.

entity The Entity whose status condition we're getting a reference to. There is exactly one StatusCondition per Entity and one Entity per StatusCondition. NoteThis constructor doesn't create a new Condition. It obtains a reference to the StatusCondition that each Entity owns. You can use this constructors as many times as needed to obtain a reference to the same StatusCondition.

So it looks like it is referencing some internal of the DataReader that is pointed to by the shared_ptr.

So my question is, is there any reason that a shared_ptr would not work in this case compared to a raw pointer?

Does your first version crash if after `dds::core::cond::StatusCondition condition(*reader);` you `delete reader;`? — melpomene, May 10 '18 at 07:13
@melpomene - I just tried that, but it (surprisingly to me) does not crash - are you thinking its a scope issue? — code_fodder, May 10 '18 at 07:15
Does anything change if you add braces? `{ dds::core::cond::StatusCondition condition(*reader); } delete reader;`? — melpomene, May 10 '18 at 07:17
Where does the stack trace *start*? What line in your code is provoking it? — Martin Bonner supports Monica, May 10 '18 at 07:17
@MartinBonner - I marked it `// <-- crashes here` in the code — code_fodder, May 10 '18 at 07:18
What we are getting at, is that the problem is probably your smart pointer is causing the object to be deleted when `dds` expects it to still be valid. I suspect you will need a smarter pointer which, as well as deleting the object deregisters it from `dds`. — Martin Bonner supports Monica, May 10 '18 at 07:19
You code would be easier to read with `auto shared_ptr_reader = std::_make_shared>(dds::sub::Subscriber(participant), topic);` — Martin Bonner supports Monica, May 10 '18 at 07:22
@melpomene - hat-in-hand... I think I was doing something really dumb, but your comments really helped me to debug it. Putting the braces around did not have any effect, but then both of my code examples started to work so I think I had made a type-o in my second example somewhere. In my larger project (the real one) I had found that (as you guys mentioned) that my reader was going out-of-scope. So thanks very much, comments where very useful : ) I assume this should also therefore work for a unique_ptr? ... please feel free to put something down as an answer, I will mark it up — code_fodder, May 10 '18 at 07:38
@MartinBonner - same comment for you as above (can only comment to one at a time) — code_fodder, May 10 '18 at 07:38
@SergeyA yup - i'll second that as well even! (though the feedback helped) — code_fodder, May 10 '18 at 09:23

Crash when I pass a unique_ptr or shared_ptr to a thrid party function that takes a reference to the pointed to object

0 Answers0