Valgrind "definitely lost" backtrace

[Scott Kostyshak]

Valgrind gave me the following when I was trying to debug what I believe
to be a separate issue:

    ==20945== 840 (336 direct, 504 indirect) bytes in 7 blocks are definitely lost in loss record 5,624 of 5,867
    ==20945==    at 0x483AE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
    ==20945==    by 0x1885EE7: lyx::frontend::TocModels::reset(lyx::BufferView const*) (TocModel.cpp:362)
    ==20945==    by 0x1805723: lyx::frontend::GuiView::structureChanged() (GuiView.cpp:1795)
    ==20945==    by 0x180364E: lyx::frontend::GuiView::onBufferViewChanged() (GuiView.cpp:1315)
    ==20945==    by 0x181F860: lyx::frontend::GuiView::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_GuiView.cpp:158)
    ==20945==    by 0x5AD3467: QMetaObject::activate(QObject*, int, int, void**) (qobject.cpp:3801)
    ==20945==    by 0x181FD12: lyx::frontend::GuiView::bufferViewChanged() (moc_GuiView.cpp:256)
    ==20945==    by 0x1803607: lyx::frontend::GuiView::on_currentWorkAreaChanged(lyx::frontend::GuiWorkArea*) (GuiView.cpp:1309)
    ==20945==    by 0x181F84F: lyx::frontend::GuiView::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_GuiView.cpp:157)
    ==20945==    by 0x5AD3467: QMetaObject::activate(QObject*, int, int, void**) (qobject.cpp:3801)
    ==20945==    by 0x184278B: lyx::frontend::TabWorkArea::currentWorkAreaChanged(lyx::frontend::GuiWorkArea*) (moc_GuiWorkArea.cpp:644)
    ==20945==    by 0x183ED05: lyx::frontend::TabWorkArea::on_currentTabChanged(int) (GuiWorkArea.cpp:1861)
    ==20945== 

The corresponding line of TocModel.cpp:362 is the line with "new" below:

  // First, fill in the toc models.
  iterator mod_it = models_.find(type);
  if (mod_it == models_.end())
  	mod_it = models_.insert(type, new TocModel(this));
  mod_it.value()->reset(toc.second);

Note that models_ is declared as follow:

  QHash<QString, TocModel *> models_;

Is it the responsibility of the QHash's destructor to call delete on all
of the TocModel * of its elements? Where is the problem likely to be?

I looked at another use of QHash just to get an idea, and noticed the
following comment:

  /// Multiple views container.
  /**
  * Warning: This must not be a smart pointer as the destruction of the
  * object is handled by Qt when the view is closed
  * \sa Qt::WA_DeleteOnClose attribute.
  */
  QHash<int, GuiView *> views_;

However, the TocModel * does not appear to be a smart pointer (I guess
new would have to be wrapped in a smart pointer cast?).

Is this memory leak worth investigating further?

Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20200213/eed85e84/attachment.asc>