diff options
author | Marc Mutz <marc.mutz@kdab.com> | 2016-09-28 10:37:59 +0200 |
---|---|---|
committer | Marc Mutz <marc.mutz@kdab.com> | 2016-10-06 16:39:05 +0000 |
commit | daaa1a287bcccda61ce81941f8b3a69d2371e04a (patch) | |
tree | 25679efde34ae43de38a61904e321cc2c0e08b8b /tests | |
parent | 0f21e0bc198af106421b02275a053c82a2eded3d (diff) |
Plug leak in QFormLayout::setWidget()
Unlike layouts and spacer items, a QWidget is-not-a QLayoutItem.
QWidgetItem simply wraps the QWidget, so in QFormLayout::setWidget(),
we allocate a widget item for the widget passed, and hand that down
to Private::setItem() for adding to the various data structures.
Private::setItem() has a bunch of guard clauses, though, that return
without deleting the item.
A test triggered this code path and made asan complain.
This is just one part of a larger problem: QFormLayout::setLayout()
normally takes ownership of the layout passed, because QLayouts own
their QLayoutItems, and QLayout is-a QLayoutItem. But setLayout()
fails to live up to the owner role when it fails to add a layout,
and there's no easy way for the API user to check for success.
A fix for this breaks tst_qformlayout, and while those checks that
break deserve to be broken, I'll refrain from proposing the larger
fix for 5.6 LTS, but will propose it for 5.8 or 5.9 instead.
This fix here only fixes the leak in setWidget() by adding a bool
return to Private::setItem() informing Private::setWidget() of the
need to manually delete the item it allocated for the widget.
Change-Id: I81409c260f9bee2e95c9a98542d8c60bc19a1332
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Diffstat (limited to 'tests')
0 files changed, 0 insertions, 0 deletions