clear data and payload after removed from ops_in_flight

[boydc2014]

http://tracker.ceph.com/issues/9916 Fixes: #9916

Signed-off-by: Dong Lei leidong@yahoo-inc.com

[liewegas]

Reviewed-by:

[boydc2014]

update <> to email address

[ghost]

bot timed out, increasing timeout

[boydc2014]

@dachary how can we see the result after timeout increased?

[ghost]

@boydc2014 ok, I'll run the bot again

[loic-bot]

FAIL: the output of run-make-check.sh on 3e7abac is http://paste.pound-python.org/show/eolLxZVMWwbAKrtpyBEw/

Sent from GH.

[ghost]

You should try to run the failed tests locally to get more information. I suspect that running a vstart.sh cluster manually will also show problems.

PASS: unittest_on_exit
FAIL: test/erasure-code/test-erasure-code.sh
PASS: unittest_bufferlist.sh
PASS: test/encoding/check-generated.sh
PASS: test/mon/osd-pool-create.sh
PASS: test/mon/misc.sh
PASS: test/mon/osd-crush.sh
PASS: test/mon/osd-erasure-code-profile.sh
PASS: test/mon/mkfs.sh
PASS: test/ceph-disk.sh
PASS: test/mon/mon-handle-forward.sh
FAIL: test/vstart_wrapped_tests.sh 

[liewegas]

this fails make check.. test/erasure-code/test-erasure-code.sh is enough to reproduce in my case.

[loic-bot]

SUCCESS: the output of run-make-check.sh on 725391e is http://paste.pound-python.org/show/ZrNGT4lYlkg0Qz1vyIXA/

Sent from GH.

[boydc2014]

@dachary @liewegas put it under lock instead of changing order passed the tests.

[boydc2014]

@liewegas I may need to explain why QA fails on my first commit:

Firstly, I want to clear data and payload after remove op from ops_in_flight using the following code:
{
Mutex::Locker locker(ops_in_flight_lock);
assert(i->xitem.get_list() == &ops_in_flight);
utime_t now = ceph_clock_now(cct);
i->xitem.remove_myself();
history.insert(now, TrackedOpRef(i)); // here is the problem
}
i->request->clear_data();
i->request->clear_payload();

Why QA fails is that when after doing history.insert, the destructor of this op is called. And then I want to clear the data and payload. It just crashs with a segment fault.

Still investigating why the destructor is called since this op is still tracked by history.
===== Update====
After further investigation, why destructor is called after inserting op to history is that this op got removed by op history because history_size limit is hit.

I may open another pull request to refine the order of op history.

[boydc2014]

ping @dachary @liewegas

[liewegas]

This looks correct to me! Alternatively, you could take a ref and do teh free after, but this is simpler, and clear should be fast.

Reviewed-by:

[liewegas]

Can you redo this pull request, targetting master branch? and put

Backport: giant, firefly

in the git commit message so that we can backport it. Thanks!

[boydc2014]

@liewegas Thanks sage, this has been fixed in master 11082f7
I just redo it in firefly.