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<char, std::char_traits<char>, std::allocator<char>, char const (&) [16]> ( x=@0x7870cd, specs=@0x8e56268, res=@0x8e5626c, buf=@0xbfb2e220, loc_p=0x0) at /usr/include/boost/format/feed_args.hpp:227 #3 0x006dc05f in boost::io::detail::distribute<char, std::char_traits<char>, std::allocator<char>, char const (&) [16]> ( self=@0xbfb2e1e8, x=@0x7870cd) at /usr/include/boost/format/feed_args.hpp:241 #4 0x006dc0be in boost::io::detail::feed<char, std::char_traits<char>, std::allocator<char>, char const (&) [16]> ( self=@0xbfb2e1e8, x=@0x7870cd) at /usr/include/boost/format/feed_args.hpp:251 #5 0x006dc184 in boost::basic_format<char, std::char_traits<char>, std::allocator<char> >::operator%<char [16]> ( this=0xbfb2e1e8, x=@0x7870cd) at /usr/include/boost/format/format_class.hpp:64 #6 0x006dab02 in libreverse::infrastructure::Parser_Base::parse_impl (this=0xbfb2e48c, file_ref=@0x8419c0) at Parser_Base.cpp:34 #7 0x006ccb69 in libreverse::infrastructure::Configuration_Parser::parse (this=0xbfb2e48c) at Configuration_Parser.cpp:26 #8 0x006d063e in libreverse::infrastructure::Configurator::Instance () at Configurator.cpp:29 #9 0x00770a79 in libreverse::infrastructure::Data_Source_Factory::Instance () at Data_Source_Factory.cpp:143 #10 0x006ba2ab in Component (this=0x8e548b8, id=0) at Component.cpp:36 #11 0x006b6c2d in Null_Component (this=0x8e548b8, id=0) at Null_Component.cpp:16 #12 0x006b4132 in libreverse::infrastructure::Component_Factory::get_Null_Component (this=0x8e54668, id=0) at Component_Factory.cpp:83 #13 0x006904a2 in libreverse::api::Reverse::execute (this=0xbfb2e9a8, target_file=@0x8e5453c, input_type=@0x805c8dc, output_type=@0x805c94c) at Reverse.cpp:67 #14 0x0804d9df in main (ac=Cannot access memory at address 0x1 ) at reverse.cpp:50 Stephen
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<< <std::char_traits<char> > () from /usr/lib/libstdc++.so.6 #1 0x0039cc7e in boost::io::detail::put_last<char, std::char_traits<char>, char [16]> (os=@0xbfa89674, x=@0x44584d) at /usr/include/boost/format/feed_args.hpp:98 #2 0x0039cdaa in boost::io::detail::put<char, std::char_traits<char>, std::allocator<char>, char const (&) [16]> ( x=@0x44584d, specs=@0x9969e48, res=@0x9969e4c, buf=@0xbfa89938, loc_p=0x0) at /usr/include/boost/format/feed_args.hpp:150 #3 0x0039d549 in boost::io::detail::distribute<char, std::char_traits<char>, std::allocator<char>, char const (&) [16]> ( self=@0xbfa89900, x=@0x44584d) at /usr/include/boost/format/feed_args.hpp:241 #4 0x0039d5a8 in boost::io::detail::feed<char, std::char_traits<char>, std::allocator<char>, char const (&) [16]> ( self=@0xbfa89900, x=@0x44584d) at /usr/include/boost/format/feed_args.hpp:251 #5 0x0039d66e in boost::basic_format<char, std::char_traits<char>, std::allocator<char> >::operator%<char [16]> ( this=0xbfa89900, x=@0x44584d) at /usr/include/boost/format/format_class.hpp:64 #6 0x0039c06e in libreader::infrastructure::Parser_Base::parse_impl (this=0xbfa89bbc, file_ref=@0xbfa89b8c) at Parser_Base.cpp:38 #7 0x0038d750 in libreader::infrastructure::Configuration_Parser::parse (this=0xbfa89bbc) at Configuration_Parser.cpp:31 #8 0x003914fe in libreader::infrastructure::Configurator::Instance () at Configurator.cpp:31 #9 0x0042f869 in libreader::infrastructure::Data_Source_Factory::Instance () at Data_Source_Factory.cpp:143 #10 0x0037af5b in Component (this=0x99684c0, id=0) at Component.cpp:37 #11 0x00377901 in Null_Component (this=0x99684c0, id=0) at Null_Component.cpp:16 #12 0x00374e2a in libreader::infrastructure::Component_Factory::get_Null_Component (this=0x9968458, id=0) at Component_Factory.cpp:83 #13 0x0035138e in libreader::api::reader::execute (this=0xbfa89fc7, target_file=@0x9968174, input_type=@0x806acac, output_type=@0x806acf4) at reader.cpp:68 #14 0x0805559a in main (ac=3, av=0xbfa8a1c4) at reader.cpp:50 When I go to the code I see in Parser_Base.cpp at line a message that prints out above: std::cerr << boost::format("Exception throw in %s at line %d") % __FILE__ % __LINE__ << std::endl; __LINE__ is on line 37 in the file. The only change in the compile flags from the pervious attempt was the flag to activate the code in sp_debug_hooks.cpp that I included in the file. Any suggestions how I can use the flag and the code to debug my original problem without causing a new one? Stephen
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 <storri@torri.org> wrote:
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