advanceDerived() badly placed

I just ran into what I think is a bug, resulting from the changes in emplace<>. Please @joanvallve have a look at this.

The mechanisms of advance and reset in processors are a little tricky. Here I will consider only advance since it is the one presenting problems, but the same thing may apply to reset.

Starting at the end, the pointers are moved:

last_ptr_ = incoming_ptr_;

Before this point, at some point, there is a call to advanceDerived(). This function assumes that all pointers origin , last and incoming are still at the old state. Otherwise the behavior of the function is unpredictable.

The recent changes due to emplace introduced the following code in ProcessorTracker::processCapture():

// We do not create a KF

// Advance this
FrameBasePtr frm = getProblem()->emplaceFrame(NON_ESTIMATED, last_ptr_->getFrame()->getState(), incoming_ptr_->getTimeStamp());
incoming_ptr_->link(frm);
last_ptr_->getFrame()->remove(); // implicitly calling last_ptr_->remove();

// Update pointers
advanceDerived();
last_ptr_   = incoming_ptr_;
incoming_ptr_ = nullptr;

where now, advanceDerived is called AFTER a last->frame->remove(), which will in turn call last->remove().

The result is that inside advanceDerived we had last_ptr_ = nullptr.

I have made a change to this bit of code, by moving advanceDerived() up before the remove() lines, as follows:

// We do not create a KF

// Advance this
advanceDerived();

// Replace frame
FrameBasePtr frm = getProblem()->emplaceFrame(NON_ESTIMATED, last_ptr_->getFrame()->getState(), incoming_ptr_->getTimeStamp());
incoming_ptr_->link(frm);
last_ptr_->getFrame()->remove(); // implicitly calling last_ptr_->remove();

// Update pointers
last_ptr_   = incoming_ptr_;
incoming_ptr_ = nullptr;