Ticket #1046 (closed bug: fixed)

Opened 2 years ago

Last modified 2 years ago

Bugfix for memory corruption in vars: code review

Reported by: matija Owned by: janez
Milestone: Future Component: other
Severity: minor Keywords:
Cc: miha Blocking:
Blocked By:

Description

A crash has been occuring for me (Linux x86_64 with g++) on program shutdown when the 'inquisition.basket' file had been loaded: *** glibc detected *** python: double free or corruption (fasttop): 0x000000000102b180 ***

The culprit was this snippet in vars.cpp:

TVariable::~TVariable()
{
    /* When the program shuts down, it may happen that the list is destroyed before
       the variables. We do nothing in this case. */
    if (allVariablesMap.size()) {
        removeVariable();
    }
}

Apart from the fact that we're calling the size method on a possibly deallocated multimap, it seems that g++ doesn't clear the map before deallocating it, so its size stays positive. (Perhaps this is not the case and something else has actually been allocated after multimap's deallocation. For me, size() returned 40 in case of just loading the inquisition.basket and exiting. A consequent attempt to remove the variable from the map caused a second deallocation of multimap's entry.)

I commited a fix; see revision 12614.

Since what I'm doing is pretty nasty (inheriting from a STL container with a non-virtual destructor) and I'm a rookie in C++, I'd like you, Janez, to close this ticket if you deem the code acceptable; otherwise, fix it or make a comment on this ticket.

Change History

comment:1 Changed 2 years ago by janez

  • Status changed from new to closed
  • Resolution set to fixed

I guess it's OK. We probably don't care about proper destruction of this object properly for as long as it does not leave a bad impression when Orange exits. ;)

I have no idea how was this supposed to work originally, why did it work for so long and why it suddenly decided not to.

Note: See TracTickets for help on using tickets.