Review Request: Fix sporadic crash when parsing files

[Maciej Cencora]

> On Oct. 25, 2012, 3:30 p.m., Andreas Pakulat wrote:
> > I'm wondering wether this is really the right place to fix this, or wether maybe the places using the class should not pass temporaries to it? How many places are actually affected by this and how many are not and hence would rather keep a reference since that safes memory (how much memory is needed for the variable? and how many are there?)

There is no memory saving since the TypePtr has only one member - pointer to T, so the size of TypePtr<T> and TypePtr<T>& should be the same. There are two usages of DeclarationChecker where the dataType is a temp, and two where it is not a temp. I prefer mine solution over fixing the uses since it makes us safe for future.


- Maciej


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/107035/#review20890
-----------------------------------------------------------


On Oct. 25, 2012, 1:42 p.m., Maciej Cencora wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107035/
> -----------------------------------------------------------
> 
> (Updated Oct. 25, 2012, 1:42 p.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Description
> -------
> 
> Sometimes we pass a reference to temporary variable (i.e. AbstractType::Ptr() ) as _dataType param to DeclarationChecker constructor.
> It is later used in operator() member function, while this temp variable does not exist anymore resulting in SIGSEGV.
> Fix this by storing copy of dataType instead of const ref inside DeclarationChecker.
> 
> 
> Diffs
> -----
> 
>   language/duchain/topducontextutils.h 349ba50 
> 
> Diff: http://git.reviewboard.kde.org/r/107035/diff/
> 
> 
> Testing
> -------
> 
> None. How do I run all UTs for kdevplatform?
> 
> 
> Thanks,
> 
> Maciej Cencora
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20121025/8780ea35/attachment.html>