Leaks!?

eugen · Post by **eugen** » Mon Jan 10, 2005 8:34 am

i'm using NuMega BoundsChecker and i got this memory (realloc, but never allocated) leak from the start...i use the ExampleApplication and as u can see only ran ogre code so far

what do u think?!
i'm trying to get a leak free program!

eugen · Post by **eugen** » Mon Jan 10, 2005 9:22 am

those might be also problems...they are detected at the end of the ogre demo!
[img]
ftp://www.laserrollen.de/html/eu/OgreFo ... itled1.JPG
[/img]
[img]
ftp://www.laserrollen.de/html/eu/OgreFo ... itled2.JPG
[/img]
[img]
ftp://www.laserrollen.de/html/eu/OgreFo ... itled3.JPG
[/img]

eugen · Post by **eugen** » Mon Jan 10, 2005 9:24 am

here are the correct addresses:
[img]
http://www.laserrollen.de/eu/OgreForum/untitled1.JPG
[/img]
[img]
http://www.laserrollen.de/eu/OgreForum/untitled2.JPG
[/img]
[img]
http://www.laserrollen.de/eu/OgreForum/untitled3.JPG
[/img]

Post by **sinbad** » Mon Jan 10, 2005 3:02 pm

How reliable is this? I ran an Ogre demo through Rational's leak tracker a little while back (I forget the name of it) and it reported utter nonsense as leaks - it was clear that it didn't understand STL properly. I've never use BoundsChecker.

Post by **:wumpus:** » Mon Jan 10, 2005 3:44 pm

It is allowed to reallocate a null pointer, realloc(NULL, size) is defined as alloc(size)

eugen · Post by **eugen** » Mon Jan 10, 2005 3:56 pm

I'm not sure how reliable is it, but all errors it found for me (which i was making) were real (thou some of them very hidden)!

this is the result i obtain running the bspdemocollision!
the same (first five) errors apear on my demo, which is notting like bspdemo! the other ones are demo specific!

i hope it helps...the first above window contains details of the errors...the files and the reason for some...

[img]
http://www.laserrollen.de/eu/OgreForum/global.JPG
[/img]

eugen · Post by **eugen** » Mon Jan 10, 2005 4:02 pm

u're right about the realloc.

eugen · Post by **eugen** » Mon Jan 10, 2005 4:10 pm

"A module attempted to free memory that was allocated by a different module. If a module is statically linked to the C runtime library and uses an RTL call (such as malloc) to allocate memory, then it is the module’s responsibility to free that memory. The memory cannot be freed from a different module."

this is the explanation for the first five errors...

Post by **sinbad** » Mon Jan 10, 2005 5:55 pm

The thing is, we deliberately don't statically link to the C runtime library, precisely because of this heap allocation nonsense. Therefore this error is a misnomer - perhaps it can't tell? We link dynamically to msvcrt*.dll.

It may have gotten confused because the old dependencies had some libs which were not compiled with quite the right runtime lib settings. 1.0.0's dependencies have been more carefully recompiled from source so that they are all using the dynamically linked, multithreaded CRT.

eugen · Post by **eugen** » Mon Jan 10, 2005 6:55 pm

Great! Thnx!