summaryrefslogtreecommitdiff
authorzecke <zecke>2004-09-12 23:47:11 (UTC)
committer zecke <zecke>2004-09-12 23:47:11 (UTC)
commit03d8f31d45fa569d944ff635428ad9a946f077b9 (patch) (side-by-side diff)
tree9e1bdc54778581577a16be570c133a9693b4a47d
parentf05a19bd1e248ea8cea29d361a1a8085ca145c6a (diff)
downloadopie-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
Diffstat (more/less context) (ignore whitespace changes)
-rw-r--r--libqtaux/ocolorbutton.cpp1
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 )