perfmon_collection_t accessed after destruction.

[srh]

Specifically, its children access it after destruction.

This can be seen clearly in commit 48ed6fd (running the polyglot tests, for example), which adds a field to perfmon_collection_t to help exhibit the bug.

This was uncovered after noticing the intrusive_list_t destructor implementation, with its commented out assertion, which make this kind of bug seem very likely. A perfmon_collection_t is accessed after destruction by its constituents trying to remove themselves.

    ~intrusive_list_t() {
        //rassert(empty());
    }

[srh]

I am working on this in branch sam_1497, which is based off of v1.10.x.

[srh]

This seems to be the result of the perfmon_collection field being declared after the cache field in internal_disk_backed_queue_t.

[srh]

While the code is bad, this bug does not result in bad behavior or real unreliable behavior in practice, because the perfmon_collection_t is part of an internal_disk_backed_queue_t that is still in the process of being destructed -- so its memory is sitting around unused, and its destructors don't do anything interesting.

I'm moving this issue to 1.11.

[srh]

This is currently in code review 964.

[srh]

This is merged to next as of 7129359.