What steps will reproduce the problem?
1. Start a DDS application that specifies non-default QoS settings for a topic.
2. Start a SimD application that creates a reader for the topic that doesnt
specify consistent QoS.
3. Get an assertion failure (attempting to access a boost::shared_ptr that is
pointing to NULL)
This appears to occur because the result of calling sub_->create_datareader is
not checked in reader_impl.hpp before assigning to the shared_ptr. Could this
be handled more gracefully? perhaps throw a dds::Exception?
Original issue reported on code.google.com by nick.gl...@lycos.com on 22 Jul 2010 at 8:50
Original issue reported on code.google.com by
nick.gl...@lycos.com
on 22 Jul 2010 at 8:50