Valgrind "definitely lost" backtrace

Scott Kostyshak skostysh at lyx.org
Sat Feb 15 01:09:09 UTC 2020


On Fri, Feb 14, 2020 at 11:19:45AM -0500, Richard Kimberly Heck wrote:
> On 2/14/20 8:55 AM, Pavel Sanda wrote:
> > On Thu, Feb 13, 2020 at 09:58:15PM -0500, Scott Kostyshak wrote:
> >> 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?
> > Without looking how insert() is defined my guess is that it just copies
> > the whole object created by new TocModel(this) (not using pointer to it),
> > so once you leave this statement there is no handle for temporarily created
> > object and mem leak occurs.
> 
> QHash::insert does make a copy, but it makes a copy of the pointer: It's
> a QHash<QString, TocModel *>, right? So we still have access to the
> created object. The code is here:
> 
>     https://github.com/qt/qtbase/blob/dev/src/corelib/tools/qhash.h
> 
> I doubt that it is QHash's responsibility to call delete on these
> pointers, but the whole point of this change (see 6ad1b1cd0) was not to
> recreate all the objects every time we reset the TocModel. I.e., the
> pointers don't change. We just clear the objects to which they point and
> then reuse them.
> 
> I'm puzzled. Is it possible that valgrind just thinks that we lose
> access to this object, for the sorts of reasons Pavel gave?
> 
> That said, I am getting a weird warning in QtCreator about the loop
> variable itself involving a copy:
> 
> /cvs/lyx/lyx-devel/src/frontends/qt/TocModel.cpp:356: warning: loop
> variable 'toc' has type 'const pair<std::string, shared_ptr<lyx::Toc> >
> &' (aka 'const pair<basic_string<char>, shared_ptr<vector<lyx::TocItem>
> > > &') but is initialized with type 'const std::pair<const
> std::__cxx11::basic_string<char>,
> std::shared_ptr<std::vector<lyx::TocItem, std::allocator<lyx::TocItem> >
> > >' resulting in a copy
> 
> /cvs/lyx/lyx-devel/src/frontends/qt/TocModel.cpp:356: use non-reference
> type 'pair<std::string, shared_ptr<lyx::Toc> >' (aka
> 'pair<basic_string<char>, shared_ptr<vector<lyx::TocItem> > >') to keep
> the copy or type 'const std::pair<const
> std::__cxx11::basic_string<char>,
> std::shared_ptr<std::vector<lyx::TocItem, std::allocator<lyx::TocItem> >
> > > &' to prevent copying
> 
> Unsurprisingly, that goes away if I just change the loop variable to
> 'auto'. I've made that change in master. Probably won't help but....

Thanks to both of you for taking a look. I was hoping to investigate
this memory leak but it seems to be beyond my knowledge.

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/20200214/74aaa1c6/attachment-0001.asc>


More information about the lyx-devel mailing list