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

["Linda A. Walsh" <gcc at tlinx dot org>]

Jonathan Wakely wrote:
> By doing exactly that. Check if the std::function you're calling is
> valid, e.g. if (f) or if (f == nullptr) or if (!!f) or whatever floats
> your boat.
>   
----
I tried that --- nothing converts it to a printable.  It's a pointer to 
a structure
that contains ...
   private:
     // Invokes the underlying function object __arg by unpacking all
     // of the arguments in the tuple.
     template<typename _CVArg, typename... _Args, std::size_t... _Indexes>
   auto
..l.
------------------
I don't have access to the underlying function object because it is
*is* C++ specific -- in that it is buried in a private part of an opaque 
structure.


> Look at the stack trace, find out why the std::function object you're
> calling is empty at that point.
>   
----
   What I am calling isn't empty.  It's only after it gets into the
library internals and is unpacked that something doesn't pass.

> Then either fix the code so it isn't empty, or add a check so you
> don't call it when it's empty.
>   
----

> Nothing in this question is specific to libstdc++, it's a basic "how
> do I use std::function?" question and would be much more appropriate
> in a general C++ forum, such as StackOverflow.
>   
----
   It isn't the pointer to the std::function object that is empty, gdb 
single steps
past that call into the library internals where something fails.


That there is no way for me to validate this before calling seems 
ridiculous:
it is 'task' specific' (specific to the task being placed on the 
scheduler).  If
I don't  place this task on Q, it will run for days w/no problems, but I 
see nothing
specific to this task that would make it diffferent.

What I see in my prog is:
   function<void (void) > work{};

And 'work' is "valid"** -- it points into a lib function and it is 
inside the c++
function that it is determined to be invalid.

** - -it's not null and the debugger traces it into libstd++ where 
checks there
invalidate it...   But at that point I'm trying to debug an opaque blob 
that is part
of libstd++ internals.