tcmalloc and boost::diagnostic_information
I have some code that works fine on Mac OS X. I then switched it to use tcmalloc and it crashes when I attempt to use boost::diagnostic_information to print out information about an exception. #0 0x00007fff81298886 in __kill () #1 0x00007fff81338eae in abort () #2 0x000000010076ece3 in TCMalloc_CRASH_internal () at spinlock.h:104 #3 0x000000010076ee4b in TCMalloc_CrashReporter::PrintfAndDie () at spinlock.h:104 #4 0x000000010076c586 in (anonymous namespace)::InvalidFree (ptr=<value temporarily unavailable, due to optimizations>) at src/tcmalloc.cc:372 #5 0x000000010004171a in boost::units::detail::demangle (name=0x100258ac0 "N5boost16exception_detail10clone_implIN2fl5error14future_timeoutEEE") at utility.hpp:48 #6 0x0000000100046456 in boost::exception_detail::diagnostic_information_impl (be=0x101b00080, se=0x101b00070, with_what=true) at diagnostic_information.hpp:140 #7 0x00000001000466b9 in boost::diagnostic_information<boost::exception> (e=@0x101b00080) at diagnostic_information.hpp:156 Has anyone here seen this problem? I do not know whether this is a bug with tcmalloc or boost, but I would really like to use tcmalloc because it gives me a 10-50% performance increase when I am not throwing exceptions.
AMDG Daniel Larimer wrote:
I have some code that works fine on Mac OS X. I then switched it to use tcmalloc and it crashes when I attempt to use boost::diagnostic_information to print out information about an exception.
#0 0x00007fff81298886 in __kill () #1 0x00007fff81338eae in abort () #2 0x000000010076ece3 in TCMalloc_CRASH_internal () at spinlock.h:104 #3 0x000000010076ee4b in TCMalloc_CrashReporter::PrintfAndDie () at spinlock.h:104 #4 0x000000010076c586 in (anonymous namespace)::InvalidFree (ptr=<value temporarily unavailable, due to optimizations>) at src/tcmalloc.cc:372 #5 0x000000010004171a in boost::units::detail::demangle (name=0x100258ac0 "N5boost16exception_detail10clone_implIN2fl5error14future_timeoutEEE") at utility.hpp:48 #6 0x0000000100046456 in boost::exception_detail::diagnostic_information_impl (be=0x101b00080, se=0x101b00070, with_what=true) at diagnostic_information.hpp:140 #7 0x00000001000466b9 in boost::diagnostic_information<boost::exception> (e=@0x101b00080) at diagnostic_information.hpp:156
Has anyone here seen this problem? I do not know whether this is a bug with tcmalloc or boost, but I would really like to use tcmalloc because it gives me a 10-50% performance increase when I am not throwing exceptions.
I think __cxa_demangle is using glibc's malloc implementation, but free is calling tcmalloc. I have no idea how to make __cxa_demangle work with tcmalloc. In Christ, Steven Watanabe P.S. Why is boost::exception calling into boost::units::detail? Should I push demangle into boost::detail?
On 06/14/2010 08:04 AM, Steven Watanabe wrote:
AMDG
Has anyone here seen this problem? I do not know whether this is a bug with tcmalloc or boost, but I would really like to use tcmalloc because it gives me a 10-50% performance increase when I am not throwing exceptions.
I think __cxa_demangle is using glibc's malloc implementation, but free is calling tcmalloc. I have no idea how to make __cxa_demangle work with tcmalloc.
If you link with tcmalloc, you can check ldd output to verify that tcmalloc is the very first library in the list. If it's not, try moving it to the beginning of the linker command line.
On Sun, Jun 13, 2010 at 9:04 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
P.S. Why is boost::exception calling into boost::units::detail? Should I push demangle into boost::detail?
Good idea, though I wouldn't mind an official demangling Boost library -- why do you think it should be in ::detail? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
AMDG Emil Dotchevski wrote:
On Sun, Jun 13, 2010 at 9:04 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
P.S. Why is boost::exception calling into boost::units::detail? Should I push demangle into boost::detail?
Good idea, though I wouldn't mind an official demangling Boost library -- why do you think it should be in ::detail?
Because making it an official library would require more effort than I'm willing expend on it at the moment. In Christ, Steven Watanabe
On 14.06.2010 20:59, Steven Watanabe wrote:
AMDG
Emil Dotchevski wrote:
On Sun, Jun 13, 2010 at 9:04 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
P.S. Why is boost::exception calling into boost::units::detail? Should I push demangle into boost::detail?
Good idea, though I wouldn't mind an official demangling Boost library -- why do you think it should be in ::detail?
Because making it an official library would require more effort than I'm willing expend on it at the moment.
FWIW, in Boost.Log I implemented type_info_wrapper which provides similar functionality. I'd be happy to extract it to Boost.Utility or a separate library if there's enough interest.
On Mon, Jun 14, 2010 at 12:12 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On 14.06.2010 20:59, Steven Watanabe wrote:
AMDG
Emil Dotchevski wrote:
On Sun, Jun 13, 2010 at 9:04 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
P.S. Why is boost::exception calling into boost::units::detail? Should I push demangle into boost::detail?
Good idea, though I wouldn't mind an official demangling Boost library -- why do you think it should be in ::detail?
Because making it an official library would require more effort than I'm willing expend on it at the moment.
FWIW, in Boost.Log I implemented type_info_wrapper which provides similar functionality. I'd be happy to extract it to Boost.Utility or a separate library if there's enough interest.
I think that demangling should be separate from any type info functionality. It should be a function that takes a string and returns a string, just like it is done in the units library's detail header I hijacked. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
participants (4)
-
Andrey Semashev -
Daniel Larimer -
Emil Dotchevski -
Steven Watanabe