Review Request 128205: Fix crash when a method exposed to Kross returns QVariant with non-relocatable data

[Albert Astals Cid]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128205/#review96613
-----------------------------------------------------------



How hard is to add a unit test to prove this is needed+so it doesn't break again in the future?

- Albert Astals Cid


On June 16, 2016, 10:04 a.m., Alexander Potashev wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128205/
> -----------------------------------------------------------
> 
> (Updated June 16, 2016, 10:04 a.m.)
> 
> 
> Review request for KDE Frameworks and Friedrich W. H. Kossebau.
> 
> 
> Repository: kross
> 
> 
> Description
> -------
> 
> In the Python2 interpreter plugin we constuct a QVariant from a typeId
> and a pointer to the data. When a method returns e.g. a QVariantMap
> in a QVariant, the typeId is QVariant::Map, but toVoidStar() used to
> point to the memory where the wrapper QVariant was stored, but the QMap
> is actually stored elsewhere, because QTypeInfo<QVariantMap>::isStatic
> is true.
> 
> It wasn't crashing with Qt4 because in Qt4 QVariantMap was stored in the
> QVariant's internal store (the C++ union).
> 
> We add template specialization MetaTypeVariant<QVariant> to handle
> QVariants differently: now we directly return QVariant::data().
> 
> 
> Diffs
> -----
> 
>   src/core/metatype.h 5ffb9761377555bd0e664fa95828f1b43da7a9b3 
> 
> Diff: https://git.reviewboard.kde.org/r/128205/diff/
> 
> 
> Testing
> -------
> 
> This method does not crash anymore when called from a Python2 script:
> 
>     QVariant returnEmptyMap()
>     {
>         return QVariantMap();
>     }
> 
> 
> Thanks,
> 
> Alexander Potashev
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160616/83d64def/attachment.html>