Long time no action on this front. I suggest to defer working on this until
issue344 is resolved.

The fix is now pushed into my downward-fixes repository.
I also fixed another issue I found, where LAMA-FF Synergy did not support the 
reset() method (to clear landmark information).

Ok, I'll start working on it.

I wouldn't be worried about destructors taking too much time. If it indeed turns
out that they do, we can do something about it then. So the suggestion sounds
good to me, and I wouldn't add an option -- searches should always clean up
after themselves.

It's part of a more general problem we have where things are allocated and then
not deleted due to laziness and the now ill-founded assumption that they will
persist until the end of the planner's lifetime anyway. So once this is
addressed, I'd like to see a separate issue about memory deallocation in
general. (Might as well open it now already, of course.)

It's only expensive if the destructor is actually invoked, right. And since it
all starts with IteratedSearch deleting it's current search, you could use an
option (to iterated_search) to control if you want it to do this or not. If it
doesn't, then none of the recursive destruction (search space, open lists, etc)
takes place, and overhead should be minimal.

Just saw this (I should go over the issue tracker more often).
I think it's worth doing (even though I know that deleting the old searches might 
take a considerable amount of time).
Any objections?

Nevermind, I think I've sorted this out.

In case anyone's interested:

- IteratedSearch::step needs to delete current_search;
- Search engine destructors need to delete their open list;
- AlternationOpenList's destructor needs to delete the sublists;
- SearchSpace's destructor (or someone) must delete the copies made of states by
StateProxy::make_permanent.

For the last point, I did a two-step thing that first iterates through the hash
table, collecting the state pointers in a vector, then deletes the hash table
and finally runs through the vector deleting the states. Directly deleting the
states while iterating through the hash table caused a segfault.

(I'm downgrading this to a "wish", on the basis that it might be nice if this
was done properly in some future version... ;))

I'm not sure if this is a bug, a feature, or just a stupid question.

I'm doing some experiments with repeated, randomised search, using FD. For this
purpose, I've added some randomisation to the FF heuristic (when there are
several min cost supporters for a proposition, one is chosen randomly) and to
lazy_search (very similar to the succ_mode == shuffled option that was already
there, but shuffling the preferred and non-preferred successors separately, and
placing the preferred ones first). To run repeated searches, I'm using the
iterated_search engine, as follows:

iterated(lazy_greedy(hff, succ_mode=3, preferred=(hff)), pass_bound=false,
repeat_last=true)

that is, I want the search to start "fresh" (no passing of bounds) in each
iteration. However, it seems that something is kept in memory between searches,
because memory use grows continually, and very rapidly. Are old "phase" engines
not deleted? (If not, some hints as to where/how I should modify iterated search
to do that would be highly appreciated...) Or is some information, like the
closed list, kept between searches?