Hi,
Most of the memleaks found by valgrind seem to originate from libraries,
especially libfontconfig, so it’s not our fault. Maybe the only leak that
seems to be caused by libavogadro is:
==10531== 614 (36 direct, 578 indirect) bytes in 1 blocks are definitely lost
in loss record 165 of 237
==10531== at 0x4021DC5: operator new(unsigned) (vg_replace_malloc.c:163)
==10531== by 0x6C5E16C:
Avogadro::NavigateToolFactory::createInstance(QObject*)
(in /home/kde4/kde/lib/avogadro/tools/libnavigatetool.so)
==10531== by 0x4D9C81B: Avogadro::ToolGroup::load()
(in /home/kde4/kde/lib/libavogadro.so.0.0.1)
==10531== by 0x8064D85: Avogadro::MainWindow::constructor()
(in /home/kde4/kde/bin/avogadro)
==10531== by 0x806540B: Avogadro::MainWindow::MainWindow()
(in /home/kde4/kde/bin/avogadro)
==10531== by 0x806D0B2: main (in /home/kde4/kde/bin/avogadro)
I looked at the source code, and the main suspect is the destructor of
ToolPrivate, in tool.cpp:
~ToolPrivate() {
// delete settingsWidget; settingsWidget = 0;
delete activateAction; activateAction = 0;
}
I wondered why you had commented out the line deleting settingsWidget, so I
uncommented it, and got a segfault. So I understand why you had commented it
out. But I think this is likely responsible for the above memleak, isn’t it?
I don’t have a solution however. Googling for “delete qwidget segfault” didn’t
give much information.
Cheers,
Benoit
The reason there is a segfault is because the code is actually designed
a bit wrong. So Actions can be shared, but widgets can’t. So actually,
settingsWidget should be createSettingsWidget() because widgets, when
added to a layout / parent widget, are controlled by that parent widget
and that parent is responsible for deleteing it. Contrary to actions
which we must delete later on. It’s not lost, i think that valgrind is
having a hard time seeing how it’s deleted. The toolPropertiesStack is
actually deleteing it.
The problem we have though, is that if we create multiple settings
widgets for a tool, they will both have callbacks to our tool, and it’s
possible they won’t be synced up. This isn’t a problem really because
ideally there shouldn’t be more than one settingsWidget per tool ever
created. But the API would allow it.
(Sun, Apr 29, 2007 at 10:36:43PM +0200) Benoît Jacob jacob@math.jussieu.fr:
Hi,
Most of the memleaks found by valgrind seem to originate from libraries,
especially libfontconfig, so it’s not our fault. Maybe the only leak that
seems to be caused by libavogadro is:
==10531== 614 (36 direct, 578 indirect) bytes in 1 blocks are definitely lost
in loss record 165 of 237
==10531== at 0x4021DC5: operator new(unsigned) (vg_replace_malloc.c:163)
==10531== by 0x6C5E16C:
Avogadro::NavigateToolFactory::createInstance(QObject*)
(in /home/kde4/kde/lib/avogadro/tools/libnavigatetool.so)
==10531== by 0x4D9C81B: Avogadro::ToolGroup::load()
(in /home/kde4/kde/lib/libavogadro.so.0.0.1)
==10531== by 0x8064D85: Avogadro::MainWindow::constructor()
(in /home/kde4/kde/bin/avogadro)
==10531== by 0x806540B: Avogadro::MainWindow::MainWindow()
(in /home/kde4/kde/bin/avogadro)
==10531== by 0x806D0B2: main (in /home/kde4/kde/bin/avogadro)
I looked at the source code, and the main suspect is the destructor of
ToolPrivate, in tool.cpp:
~ToolPrivate() {
// delete settingsWidget; settingsWidget = 0;
delete activateAction; activateAction = 0;
}
I wondered why you had commented out the line deleting settingsWidget, so I
uncommented it, and got a segfault. So I understand why you had commented it
out. But I think this is likely responsible for the above memleak, isn’t it?
I don’t have a solution however. Googling for “delete qwidget segfault” didn’t
give much information.
Cheers,
Benoit
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options
On Sunday 29 April 2007 23:49:53 Donald Ephraim Curtis wrote:
It’s not lost, i think that valgrind is
having a hard time seeing how it’s deleted. The toolPropertiesStack is
actually deleteing it.
ah, then all is well!
Benoit