Double Free involving APTK h_{FF}

[miquelramirez]

While profiling the Match Tree, I have come up with the following stack trace (reported by callgrind)

==9420== Process terminating with default action of signal 6 (SIGABRT)
==9420==    at 0x6E70428: raise (raise.c:54)
==9420==    by 0x6E72029: abort (abort.c:89)
==9420==    by 0x6EB27E9: __libc_message (libc_fatal.c:175)
==9420==    by 0x6EBAE09: _int_free (malloc.c:5004)
==9420==    by 0x6EBE98B: free (malloc.c:2966)
==9420==    by 0x4DE0530: std::_Sp_counted_ptr_inplace<aptk::agnostic::Relaxed_Plan_Heuristic<aptk::agnostic::Fwd_Search_Problem, aptk::agnostic::H1_Heuristic<aptk::agnostic::Fwd_Search_Problem, aptk::agnostic::H_Add_Evaluation_Function, (aptk::agnostic::H1_Cost_Function)1>, (aptk::agnostic::RP_Cost_Function)1>, std::allocator<aptk::agnostic::Relaxed_Plan_Heuristic<aptk::agnostic::Fwd_Search_Problem, aptk::agnostic::H1_Heuristic<aptk::agnostic::Fwd_Search_Problem, aptk::agnostic::H_Add_Evaluation_Function, (aptk::agnostic::H1_Cost_Function)1>, (aptk::agnostic::RP_Cost_Function)1> >, (__gnu_cxx::_Lock_policy)2>::_M_dispose() (bit_set.hxx:32)
==9420==    by 0x4D8FA23: fs0::bfws::LazyBFWSDriver<fs0::SimpleStateModel>::~LazyBFWSDriver() (shared_ptr_base.h:150)
==9420==    by 0x4D88D43: fs0::drivers::EngineRegistry::~EngineRegistry() (registry.cxx:62)
==9420==    by 0x6E74FF7: __run_exit_handlers (exit.c:82)
==9420==    by 0x6E75044: exit (exit.c:104)
==9420==    by 0x6E5B836: (below main) (libc-start.c:325)

ugly, ugly, as we say in Spanish. Not very clear to me just yet what is exactly causing it... perhaps an interaction between reference counting a la C++11 and some old style code (i.e. aptk::bitset?). Anyways, it seems to me to be a "bug" in APTK.

[gfrances]

Does this happen outside callgrind? Can we reproduce this in the debugger?

[miquelramirez]

Only in release, during stack unwinding: see the calls to the destructors of static objects.

[gfrances]

I'd say we can close this for now, as we shouldn't really be using APTK's FF implementation in the future...

[miquelramirez]

No objections here, it was a temporary measure and indeed, we don't really need it to work...