Proper initialization of a boost::shared_ptr<> in a constructor
I am attempting to hunt down why I am getting a segmentation fault from the boost::shared_ptr class. I know that it has to do with how I am managing my shared pointers. That is creating and using them in functions. I am reading the best practices web page and I have a question about the best way to initialize a shared_ptr. Normally I have a class like the following: class A { public: typedef boost::shared_ptr<A> ptr_t; A ( int input_value ) : value ( input_value ) {} private: int value; }; Which I will use in another place: class A_User { public: A_User () : m_a_ptr ( new A() ) {} private: A::ptr_t m_a_ptr; }; Is this the correct way to initialize the A::ptr_t held in the A_User class in its constructor? Stephen
Stephen Torri wrote:
I am attempting to hunt down why I am getting a segmentation fault from the boost::shared_ptr class.
You could try #defining BOOST_SP_ENABLE_DEBUG_HOOKS and adding libs/smart_ptr/src/sp_debug_hooks.cpp to your project, which is a simple checker that tries to catch common problems. You might also wish to verify that you aren't mixing single-threaded and multithreaded code or libraries in the same program.
I know that it has to do with how I am managing my shared pointers. That is creating and using them in functions. I am reading the best practices web page and I have a question about the best way to initialize a shared_ptr.
Normally I have a class like the following:
class A { public:
typedef boost::shared_ptr<A> ptr_t;
A ( int input_value ) : value ( input_value ) {}
private: int value; };
Which I will use in another place:
class A_User { public:
A_User () : m_a_ptr ( new A() ) {}
private:
A::ptr_t m_a_ptr; };
Is this the correct way to initialize the A::ptr_t held in the A_User class in its constructor?
Yes, this is correct.
On Fri, 2007-03-23 at 01:30 +0200, Peter Dimov wrote:
Stephen Torri wrote:
I am attempting to hunt down why I am getting a segmentation fault from the boost::shared_ptr class.
You could try #defining BOOST_SP_ENABLE_DEBUG_HOOKS and adding libs/smart_ptr/src/sp_debug_hooks.cpp to your project, which is a simple checker that tries to catch common problems.
You might also wish to verify that you aren't mixing single-threaded and multithreaded code or libraries in the same program.
As far as I know I have a single-threaded library I am creating. I put the BOOST_SP_ENABLE_DEBUG_HOOKS into the compile time flags for g++. I added the source file, sp_debug_hooks.cpp, into the build. I take it the checks are done when the library code is executed? Stephen
Stephen Torri wrote:
On Fri, 2007-03-23 at 01:30 +0200, Peter Dimov wrote:
Stephen Torri wrote:
I am attempting to hunt down why I am getting a segmentation fault from the boost::shared_ptr class.
You could try #defining BOOST_SP_ENABLE_DEBUG_HOOKS and adding libs/smart_ptr/src/sp_debug_hooks.cpp to your project, which is a simple checker that tries to catch common problems.
You might also wish to verify that you aren't mixing single-threaded and multithreaded code or libraries in the same program.
As far as I know I have a single-threaded library I am creating. I put the BOOST_SP_ENABLE_DEBUG_HOOKS into the compile time flags for g++. I added the source file, sp_debug_hooks.cpp, into the build. I take it the checks are done when the library code is executed?
Yes, there are a bunch of assertions in sp_debug_hooks that attempt to catch heap- and shared_ptr-related errors. Make sure you don't #define NDEBUG, though. If the asserts don't trigger, your problem might be deeper than a simple invalid use of shared_ptr. If you post a backtrace/call stack of one of your crashes, we may be able to help.
On Fri, 2007-03-23 at 02:46 +0200, Peter Dimov wrote:
Yes, there are a bunch of assertions in sp_debug_hooks that attempt to catch heap- and shared_ptr-related errors. Make sure you don't #define NDEBUG, though.
I have a personal define called DEBUG will that be a problem?
If the asserts don't trigger, your problem might be deeper than a simple invalid use of shared_ptr. If you post a backtrace/call stack of one of your crashes, we may be able to help.
Ok. Here is one crash that occurs pretty much immediately after a
function is called in the library. The crash is occurring when the
library is trying to parse a XML file containing configuration
information.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209059632 (LWP 29966)]
0x0069dce9 in operator delete[] (p=0x8) at sp_debug_hooks.cpp:224
224 BOOST_ASSERT(*pm != deleted); // double delete
(gdb) bt
#0 0x0069dce9 in operator delete[] (p=0x8) at sp_debug_hooks.cpp:224
#1 0x47ff0eb6 in std::ios_base::~ios_base$base () from /usr/lib/libstdc++.so.6
#2 0x006dbefd in boost::io::detail::put
On Fri, 2007-03-23 at 02:46 +0200, Peter Dimov wrote:
Yes, there are a bunch of assertions in sp_debug_hooks that attempt to catch heap- and shared_ptr-related errors. Make sure you don't #define NDEBUG, though.
If the asserts don't trigger, your problem might be deeper than a simple invalid use of shared_ptr. If you post a backtrace/call stack of one of your crashes, we may be able to help.
When I add the BOOST_SP_ENABLE_DEBUG_HOOKS to the compile flags for g++
I am getting a segmentation fault when the boost::format lines in my
code are executed. Yet when I compile without it I don't. Here is the
output from my project that is in development. It gives me a error from
the parser.
$ ./reader --file kernel32.dll
File to analyze was set to kernel32.dll.
Parser_Base::Cannot find /home/storri/src/libreader/config.xml
Exception throw in Parser_Base.cpp at line 37
Unable to find the default setup files for the system.
Starting the library using the default settings
Data_Object::setData - Filename = kernel32.dll (Ptr count = 3,
Input Ptr count = 3)
Exception throw in Master_Formula_Parser.cpp at line 132
Exception:(Parsing_Exception) 3
Internal parsing error
When I compile it with BOOST_SP_ENABLE_DEBUG_HOOKS it fails with the
segfault:
$ ./reader --file kernel32.dll
File to analyze was set to kernel32.dll.
Parser_Base::Cannot find /home/storri/src/libreader/config.xml
Segmentation fault
(gdb) bt
#0 0x48029fa8 in std::operator<<
Stephen Torri wrote:
When I add the BOOST_SP_ENABLE_DEBUG_HOOKS to the compile flags for g++ I am getting a segmentation fault when the boost::format lines in my code are executed. Yet when I compile without it I don't. Here is the output from my project that is in development. It gives me a error from the parser.
[...]
When I compile it with BOOST_SP_ENABLE_DEBUG_HOOKS it fails with the segfault:
[...]
Any suggestions how I can use the flag and the code to debug my original problem without causing a new one?
None at the moment, but if you post a minimal example that causes the problem, I'll take a look at it. I've tried just using boost::format as in your code with sp_debug_hooks, but it appears to work (with g++ 3.4.4 and MSVC 7.1).
You're not passing an input_value parameter?
e.g.
A_User ()
: m_a_ptr ( new A(42) )
{}
Richard
On 3/23/07, Stephen Torri
I am attempting to hunt down why I am getting a segmentation fault from the boost::shared_ptr class. I know that it has to do with how I am managing my shared pointers. That is creating and using them in functions. I am reading the best practices web page and I have a question about the best way to initialize a shared_ptr.
Normally I have a class like the following:
class A { public:
typedef boost::shared_ptr<A> ptr_t;
A ( int input_value ) : value ( input_value ) {}
private: int value; };
Which I will use in another place:
class A_User { public:
A_User () : m_a_ptr ( new A() ) {}
private:
A::ptr_t m_a_ptr; };
Is this the correct way to initialize the A::ptr_t held in the A_User class in its constructor?
Stephen
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (4)
-
Peter Dimov -
Peter Dimov -
Richard Dingwall -
Stephen Torri