[not a bug?] device->drop() and leaks

ChrisC · Post by **ChrisC** » Tue Dec 12, 2006 5:23 pm

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

niko · Post by **niko** » Tue Dec 12, 2006 7:06 pm

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.

hybrid · Post by **hybrid** » Tue Dec 12, 2006 8:40 pm

Are you sure that these are "real leaks" or just non-freed but referenced memory? A log would help.

stodge · Post by **stodge** » Wed Dec 13, 2006 5:07 pm

Use ALT-F4 to exit the demos. ESC isn't support.

TheC · Post by **TheC** » Wed Dec 13, 2006 5:57 pm

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

ChrisC · Post by **ChrisC** » Thu Dec 14, 2006 1:32 pm

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.

hybrid · Post by **hybrid** » Thu Dec 14, 2006 3:45 pm

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.

ChrisC · Post by **ChrisC** » Fri Dec 15, 2006 5:57 am

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

hybrid · Post by **hybrid** » Fri Dec 15, 2006 9:36 am

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.

TheC · Post by **TheC** » Tue Dec 19, 2006 9:00 am

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.

ChrisC · Post by **ChrisC** » Thu Dec 21, 2006 8:51 am

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?

hybrid · Post by **hybrid** » Fri Dec 22, 2006 9:06 pm

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