author | zecke <zecke> | 2004-09-12 23:47:11 (UTC) |
---|---|---|
committer | zecke <zecke> | 2004-09-12 23:47:11 (UTC) |
commit | 03d8f31d45fa569d944ff635428ad9a946f077b9 (patch) (side-by-side diff) | |
tree | 9e1bdc54778581577a16be570c133a9693b4a47d | |
parent | f05a19bd1e248ea8cea29d361a1a8085ca145c6a (diff) | |
download | opie-03d8f31d45fa569d944ff635428ad9a946f077b9.zip opie-03d8f31d45fa569d944ff635428ad9a946f077b9.tar.gz opie-03d8f31d45fa569d944ff635428ad9a946f077b9.tar.bz2 |
OColorButton::~OColorButton ( )
{
+ delete d->m_menu;
delete d;
}
That was a tricky one to find. If a dynamically loaded shared object (dso)
creates QObjects/QWidgets on the destruction of QApplication they will
be freed. For normal applications these dso's have already been removed
from the address-space leading to calling delete to or from a bogus
part of memory leading to segfaults
-rw-r--r-- | libqtaux/ocolorbutton.cpp | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/libqtaux/ocolorbutton.cpp b/libqtaux/ocolorbutton.cpp index 925df7f..004fafc 100644 --- a/libqtaux/ocolorbutton.cpp +++ b/libqtaux/ocolorbutton.cpp @@ -60,32 +60,33 @@ OColorButton::OColorButton ( QWidget *parent, const QColor &color, const char *n setPopup ( d-> m_menu ); // setPopupDelay ( 0 ); connect ( d-> m_menu, SIGNAL( colorSelected(const QColor&)), this, SLOT( updateColor(const QColor&))); QSize s = sizeHint ( ) + QSize ( 12, 0 ); setMinimumSize ( s ); setMaximumSize ( s. width ( ) * 2, s. height ( )); d->m_color = color; } /** * This destructs the object */ OColorButton::~OColorButton ( ) { + delete d->m_menu; delete d; } /** * @return Returns the current color of the button */ QColor OColorButton::color ( ) const { return d-> m_color; } /** * This method sets the color of the button * @param c The color to be set. */ void OColorButton::setColor ( const QColor &c ) |