Trouble using shared_ptr with g++ -O0 and -O2 options
Hello there
I'm getting a SIGSEGV when using the boost::shared_ptr in my program and
compiling with the g++ -O2 option, whereas if I'm using the g++ -O0 option
my programs works the way it should. My program is multi-threaded but to the
best of my knowledge it is mutex'ed correctly.
I compile my program the following way when using -O2 and -O0
g++ -O0 -ggdb3 -DNDEBUG -DTTSERVER ....
g++ -O2 -ggdb3 -DNDEBUG -DTTSERVER ....
When I use gdb to step through the program (only with 'n') I go into the
shared_count.hpp file when using the -O2 option whereas the version compiled
with -O0 disregards this file in gdb.
The -O2 version of the program crashes in the file checked_delete.hpp and
the member "checked_delete":
template<class T> inline void checked_delete(T * x)
{
// intentionally complex - simplification causes regressions
typedef char type_must_be_complete[ sizeof(T)? 1: -1 ];
(void) sizeof(type_must_be_complete);
=> delete x;
}
Here's the gdb output:
Program received signal SIGSEGV, Segmentation fault.
0x08053370 in
boost::detail::sp_counted_base_impl
Bear wrote:
Hello there
I'm getting a SIGSEGV when using the boost::shared_ptr in my program and compiling with the g++ -O2 option, whereas if I'm using the g++ -O0 option my programs works the way it should. My program is multi-threaded but to the best of my knowledge it is mutex'ed correctly.
I compile my program the following way when using -O2 and -O0
g++ -O0 -ggdb3 -DNDEBUG -DTTSERVER .... g++ -O2 -ggdb3 -DNDEBUG -DTTSERVER ....
When I use gdb to step through the program (only with 'n') I go into the shared_count.hpp file when using the -O2 option whereas the version compiled with -O0 disregards this file in gdb.
Are you sure you don't have that the wrong way round?
The -O2 version of the program crashes in the file checked_delete.hpp and the member "checked_delete":
You cannot find bugs in optimised programs using a source-level debugger. The source locations you see are no more than a hint as to the source of the machine code being run. An optimising compiler can reorganise your code in ways you hadn't dreamed of. Besides which, just because a bug shows up when deleting an object, doesn't mean the bug is in the deletion. To debug the problem, you will probably find it more useful to add debug output to your program. <snip>
As I mentioned earlier, the -O0 run without problems. Has anyone experienced similar problems? <snip>
Yes, I think most C and C++ programmers manage to produce bugs with this sort of effect from time to time. That's nothing to do with Boost, though. Ben.
participants (2)
-
Bear -
Ben Hutchings