Page 1 of 1


Posted: Mon Jan 10, 2005 8:34 am
by eugen
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! :roll:

Posted: Mon Jan 10, 2005 9:22 am
by eugen
those might be also problems...they are detected at the end of the ogre demo!
[img] ... itled1.JPG
[img] ... itled2.JPG
[img] ... itled3.JPG

Posted: Mon Jan 10, 2005 9:24 am
by eugen

Posted: Mon Jan 10, 2005 3:02 pm
by sinbad
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.

Posted: Mon Jan 10, 2005 3:44 pm
by :wumpus:
It is allowed to reallocate a null pointer, realloc(NULL, size) is defined as alloc(size)

Posted: Mon Jan 10, 2005 3:56 pm
by eugen
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...


Posted: Mon Jan 10, 2005 4:02 pm
by eugen
u're right about the realloc.

Posted: Mon Jan 10, 2005 4:10 pm
by eugen
"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...

Posted: Mon Jan 10, 2005 5:55 pm
by sinbad
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.

Posted: Mon Jan 10, 2005 6:55 pm
by eugen
Great! Thnx!