Page 1 of 1
[not a bug?] device->drop() and leaks
Posted: Tue Dec 12, 2006 5:23 pm
by ChrisC
at some point device->drop() started seg faulting, it segs while trying to decrement the reference counter.
I started looking for memory leaks thinking this was the probable cause.
to my horror there were loads on application exit.
(I can quite happily create "shot" nodes and node->remove() them without a run away increase of memory use. btw)
I had a look at some of the examples, unfortunately of the ones I tried only example01 would allow me to quit (the other examples keep hold of the mouse, and dont seem to allow exit with the escape key) I was unpleasantly surprised to see that even the very simple example01 leaks memory.
Is this a linux problem, can someone check the examples in windows?
I used Alleyoop which is gnome front end to Valgrind on Ubuntu edgy
Posted: Tue Dec 12, 2006 7:06 pm
by niko
Hm, that's strange. In windows, I don't get those. At least I didn't see any when I compiled and packaged the examples.
Posted: Tue Dec 12, 2006 8:40 pm
by hybrid
Are you sure that these are "real leaks" or just non-freed but referenced memory? A log would help.
Posted: Wed Dec 13, 2006 5:07 pm
by stodge
Use ALT-F4 to exit the demos. ESC isn't support.
Posted: Wed Dec 13, 2006 5:57 pm
by TheC
device->drop() gives me a windows "application must close" error. I'm trying to find the problem now.. I will report back if i find anything
Posted: Thu Dec 14, 2006 1:32 pm
by ChrisC
this log is from 01.helloworld, there are 100's more items but I've only included the ones over 1k as the whole log wouldnt fit!
==5527== 1,199 bytes in 2 blocks are still reachable in loss record 62 of 67
==5527== at 0x040206d5: calloc (vg_replace_malloc.c:279)
==5527== by 0x0400961a: ??? (in /lib/ld-2.4.so)
==5527== by 0x04005a89: ??? (in /lib/ld-2.4.so)
==5527== by 0x040077ad: ??? (in /lib/ld-2.4.so)
==5527== by 0x0400b346: ??? (in /lib/ld-2.4.so)
==5527== by 0x0400ca95: ??? (in /lib/ld-2.4.so)
==5527== by 0x0400b53a: ??? (in /lib/ld-2.4.so)
==5527== by 0x040108d4: ??? (in /lib/ld-2.4.so)
==5527== by 0x0400ca95: ??? (in /lib/ld-2.4.so)
==5527== by 0x040103c8: ??? (in /lib/ld-2.4.so)
==5527== by 0x04c22e1c: ??? (in /lib/tls/i686/cmov/libdl-2.4.so)
==5527== by 0x0400ca95: ??? (in /lib/ld-2.4.so)
==5527==
==5527== 1,565 bytes in 48 blocks are still reachable in loss record 63 of 67
==5527== at 0x04021396: malloc (vg_replace_malloc.c:149)
==5527== by 0x0419a0ec: _XlcAddCT (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x0419a3ca: _XlcInitCTInfo (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x041a11b7: ??? (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x0419ee9a: ??? (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x041a0fe7: _XlcCreateLC (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x04e5e70a: _XlcGenericLoader (in /usr/lib/X11/locale/common/xlibi18n.so.2.0.0)
==5527== by 0x0419321b: _XlcDynamicLoad (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x041a7a12: _XOpenLC (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x041a7b0d: _XrmInitParseInfo (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x0418ffc0: ??? (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x04191ab7: XrmGetStringDatabase (in /usr/lib/libX11.so.6.2.0)
==5527==
==5527== 2,048 bytes in 1 blocks are still reachable in loss record 64 of 67
==5527== at 0x04021396: malloc (vg_replace_malloc.c:149)
==5527== by 0x0419c3ee: _XlcCreateLocaleDataBase (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x041a12f9: ??? (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x0419ee9a: ??? (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x041a0fe7: _XlcCreateLC (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x04e5e70a: _XlcGenericLoader (in /usr/lib/X11/locale/common/xlibi18n.so.2.0.0)
==5527== by 0x0419321b: _XlcDynamicLoad (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x041a7a12: _XOpenLC (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x041a7b0d: _XrmInitParseInfo (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x0418ffc0: ??? (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x04191ab7: XrmGetStringDatabase (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x0416b19b: XGetDefault (in /usr/lib/libX11.so.6.2.0)
==5527==
==5527== 2,048 bytes in 1 blocks are still reachable in loss record 65 of 67
==5527== at 0x04021396: malloc (vg_replace_malloc.c:149)
==5527== by 0x0417bef5: _XrmInternalStringToQuark (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x0417c274: XrmPermStringToQuark (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x0419230f: XrmInitialize (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x0416b189: XGetDefault (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x0402b2d3: _XcursorGetDisplayInfo (in /usr/lib/libXcursor.so.1.0.2)
==5527== by 0x0402b50f: XcursorSupportsARGB (in /usr/lib/libXcursor.so.1.0.2)
==5527== by 0x0402da0c: XcursorNoticeCreateBitmap (in /usr/lib/libXcursor.so.1.0.2)
==5527== by 0x04164ee4: _XNoticeCreateBitmap (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x041652fc: XCreatePixmap (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x080527f6: irr::CIrrDeviceLinux::CCursorControl::CCursorControl(irr::CIrrDeviceLinux*, bool) (within /home/camacho/irrlicht/examples/01.HelloWorld/example)
==5527== by 0x08050e36: irr::CIrrDeviceLinux::CIrrDeviceLinux(irr::video::E_DRIVER_TYPE, irr::core::dimension2d<int> const&, unsigned, bool, bool, bool, bool, irr::IEventReceiver*, char const*) (within /home/camacho/irrlicht/examples/01.HelloWorld/example)
==5527==
==5527== 2,304 bytes in 48 blocks are still reachable in loss record 66 of 67
==5527== at 0x04021396: malloc (vg_replace_malloc.c:149)
==5527== by 0x0419a612: _XlcCreateDefaultCharSet (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x0419a32a: _XlcAddCT (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x0419a3ca: _XlcInitCTInfo (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x041a11b7: ??? (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x0419ee9a: ??? (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x041a0fe7: _XlcCreateLC (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x04e5e70a: _XlcGenericLoader (in /usr/lib/X11/locale/common/xlibi18n.so.2.0.0)
==5527== by 0x0419321b: _XlcDynamicLoad (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x041a7a12: _XOpenLC (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x041a7b0d: _XrmInitParseInfo (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x0418ffc0: ??? (in /usr/lib/libX11.so.6.2.0)
==5527==
==5527== 8,176 bytes in 1 blocks are still reachable in loss record 67 of 67
==5527== at 0x04021396: malloc (vg_replace_malloc.c:149)
==5527== by 0x0417bc89: ??? (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x0417c089: _XrmInternalStringToQuark (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x0417c274: XrmPermStringToQuark (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x0419230f: XrmInitialize (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x0416b189: XGetDefault (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x0402b2d3: _XcursorGetDisplayInfo (in /usr/lib/libXcursor.so.1.0.2)
==5527== by 0x0402b50f: XcursorSupportsARGB (in /usr/lib/libXcursor.so.1.0.2)
==5527== by 0x0402da0c: XcursorNoticeCreateBitmap (in /usr/lib/libXcursor.so.1.0.2)
==5527== by 0x04164ee4: _XNoticeCreateBitmap (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x041652fc: XCreatePixmap (in /usr/lib/libX11.so.6.2.0)
==5527== by 0x080527f6: irr::CIrrDeviceLinux::CCursorControl::CCursorControl(irr::CIrrDeviceLinux*, bool) (within /home/camacho/irrlicht/examples/01.HelloWorld/example)
==5527==
==5527== LEAK SUMMARY:
==5527== definitely lost: 133 bytes in 3 blocks.
==5527== indirectly lost: 104 bytes in 4 blocks.
==5527== possibly lost: 0 bytes in 0 blocks.
==5527== still reachable: 22,781 bytes in 310 blocks.
==5527== suppressed: 0 bytes in 0 blocks.
Posted: Thu Dec 14, 2006 3:45 pm
by hybrid
That's what I meant. These things are not mem leaks, but are not properly deleted upon exit. Only
==5527== definitely lost: 133 bytes in 3 blocks.
==5527== indirectly lost: 104 bytes in 4 blocks.
are problematic. Maybe indirectly lost is even not really troublesome, and 133 bytes are not what I would go for. You could try to identify the variable, though, and we'll see if there's a fix.
Posted: Fri Dec 15, 2006 5:57 am
by ChrisC
Yes but this is the simplest example I could find...
I see what you are getting at and I am aware of what you are talking about however the problem is worse with more complex examples
try for example texturing 3 or 4 scene nodes with different textures using the same mesh for one...
theres also some items missing from this log as the wouldn't fit
Posted: Fri Dec 15, 2006 9:36 am
by hybrid
No, what these figures try to tell you is that all memory is still referenced by some object which could be released (dropped) and thereby free this memory. Only lost memory can be considered a leak. And it does not matter that I did not see the others, they are just irrelevant.
Posted: Tue Dec 19, 2006 9:00 am
by TheC
I found the crash on mine when the destructors try to drop all the objects in the mesh cache. I haven't found out why its an issue, but its probably due to something being deleted and not removed from that list.
Posted: Thu Dec 21, 2006 8:51 am
by ChrisC
at any rate the *simplest* example (for example!) is NOT cleanly releasing memory and relying on the OS to do this, hence the post
in other examples there are plenty examples of LOST memory which do relate to a leak
can you demonstrate loading up a scene releasing it ALL and then repeating a few thousand times, does memory allocation grow? or stay steady?
Posted: Fri Dec 22, 2006 9:06 pm
by hybrid
Unless you get a "definitely lost" or "possibly lost" you won't get a leak. So you can repeat it a thousand times without problems.
BTW: I also used valgrind and fixed two mem leaks: We now save about 600 Bytes which were previously lost
