Re: How to get more info about 'bad_function_call' ?

["J. Leslie Turriff" <jlturriff at mail dot com>]

On Tuesday 27 January 2015 11:21:22 Jonathan Wakely wrote:
> On 27 January 2015 at 17:11, Linda A. Walsh <gcc@tlinx.org> wrote:
> > Jonathan Wakely wrote:
> >> Look at the stack trace, find out why the std::function object you're
> >> calling is empty at that point.
> >
> > Forgot to include this, but the stack track shows that what I am
> > calling @ #7 is not empty.  IP = 4141c3, and 'this' is also nonzero.
> >
> >
> > Program terminated with signal SIGABRT, Aborted.
> > #0  0x0000003002035849 in __GI_raise (sig=sig@entry=6)
> >    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> > 56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> > (gdb) where
> > #0  0x0000003002035849 in __GI_raise (sig=sig@entry=6)
> >    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> > #1  0x0000003002036cd8 in __GI_abort () at abort.c:89
> > #2  0x0000003006465145 in __gnu_cxx::__verbose_terminate_handler ()
> >    at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95
> > #3  0x00000030064632e6 in __cxxabiv1::__terminate (handler=<optimized
> > out>) at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:38
> > #4  0x0000003006463313 in std::terminate ()
> >    at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:48
> > #5  0x0000003006463532 in __cxxabiv1::__cxa_throw (obj=0x511040,
> >    tinfo=0x30066ef6c0 <typeinfo for std::bad_function_call>,
> >    dest=0x30064b4c30 <std::bad_function_call::~bad_function_call()>)
> >    at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:87
> > #6  0x00000030064b4bc2 in std::__throw_bad_function_call ()
> >    at ../../../../../libstdc++-v3/src/c++11/functexcept.cc:113
> > #7  0x00000000004141c3 in std::function<void ()>::operator()() const (
> >    this=this@entry=0x50ac58) at /usr/include/c++/4.8/functional:2470
> > #8  0x000000000041408c in Task::run (this=this@entry=0x50ac40) at
> > ltask.cc:84
>
> Your bug is here.
>
> It's really quite simple. Instead of looking into the library code,
> you need to look here.
>
> That piece of code is calling an empty std::function object.
>
> The _M_empty() condition is true, so __throw_bad_function_call() runs,
> which ... guess what? Throws std::bad_function_call ... which is what
> you're seeing.
>
> You don't need "more info about bad_function_call" because it tells
> you exactly one thing: you called an empty std::function. Its sole
> purpose is to tell you where and when that call happens, which is in
> the stack trace above but you're insisting on ignoring your own code
> and digging into the library.
	Wow.  So simple, but I, for one, can't see any reference in the stack trace 
to _M_empty() that tells this.
>
> >    this=this@entry=0x7fff8a4ce900, wait_ms=wait_ms@entry=10,
> >    once=once@entry=false) at lsched.cc:65
> > #10 0x00000000004239d8 in OSstat::run (this=this@entry=0x7fff8a4ce670)
> >    at osstat.cc:97
> > #11 0x000000000041558c in main (argc=<optimized out>,
> > argv=0x7fff8a4ceb98) at main.cc:20



-- 
		A Caution to Everybody

	Consider the Auk;
	Becoming extinct because he forgot how to fly, and could only walk.
	Consider man, who may well become extinct
	Because he forgot how to walk and learned how to fly before he thinked.

-- Ogden Nash