Hi Vincent
On Fri, Sep 19, 2008 at 2:08 PM, Vincent Bourdier
<[EMAIL PROTECTED]> wrote:
> Hi thibault
>
> I just have tried with the microsoft compiler. I still have some memory
> leaks, but the ouput is unreadable :
>
> [...]
> {431278} normal block at 0x12194A50, 108 bytes long.
> Data: < {\ > FC 7B 5C 10 00 00 00 00 01 00 00 00 00 00 00 00
> {431277} normal block at 0x12194A08, 12 bytes long.
> Data: <U O T P S R > 55 03 4F 03 54 03 50 03 53 03 52 03
> [...]
This is quite expected, unless you leak a memory block containing a
string. Anyway, the valuable information here is:
- the allocation number of the block (here, 431278 and 431277)
- the length (108 bytes and 12 bytes)
To chase the bug, you need to find the lowest allocation number that
results in a leak, since further allocations might be done by the
object that is leaking and fixing the first leak may fix others -
maybe all if you are lucky :)
Once you have this, you need to re-run your program a few times to see
if this allocation number changes. If it does, you are in trouble (see
below). If it does not, then what you need to do is to call
_CrtSetBreakAlloc(<your allocation number>);
at the beginning of the program and run it under the debugger. When
the allocation number is hit, you get a popup from the debugger and
you are pointed to the exact instruction that triggers the allocation.
With this information you can hopefully find why the memory block is
never freed.
If the allocation number changes from run to run, it means that there
is some kind of random process bothering you. This typically happens
in GUIs as the user moves the mouse pointer, triggering events that
allocate memory and it is impossible to recreate the exact same order
of allocations between two runs. Facing this kind of horror, two
techniques can help you:
- try to reduce the program by removing all interactions and any other
source of randomness until the leaking allocation number does not
change between runs
- track the allocation size with a hook. Let me explain this further:
You can place a hook (i.e. callback) for each allocation with the
function _CrtSetAllocHook():
First, our callback:
int MyAllocHook( int allocType, void *userData, size_t size, int
blockType, long requestNumber, const unsigned
char *filename, int
lineNumber)
{
// This is called upon each allocation. Return TRUE to allow
the allocation, FALSE to make it fail
return TRUE;
}
and then at the beginning of the program:
_CrtSetAllocHook(MyAllocHook)
Now your hook is called for each allocation. To find the mysterious
allocation that leaks, try to find a range of numbers (e.g. the first
block that leaks is almost always in 431000..431300) and use the
allocation size in an if test such as:
if (size == <the size of your block> && requestNumber >= 431000 &&
requestNumber <= 431300)
int dummy = 0;
Place a breakpoint on the "int dummy=0" line. It will hopefully be hit
once during the faulty allocation. If it is hit more than once, try
to narrow the allocation range as much as you can.
You can as well use the hook instead of the _CrtSetBreakAlloc() call
since you are given the allocation number in it.
Hope this helps
Thibault
> I just need the line code where to find the leak but I am not able to do
> it... I added #define _CRTDBG_MAP_ALLOC but nothing appear...
> Any suggestion to get the file and line number ?
>
> thanks a lot.
> Regards,
> Vincent.
>
> 2008/9/19 Thibault Genessay <[EMAIL PROTECTED]>
>>
>> Hi Vincent
>>
>> On Fri, Sep 19, 2008 at 1:12 PM, Vincent Bourdier
>> <[EMAIL PROTECTED]> wrote:
>> > I know... but I am under windows... and so I have to forget this one...
>> > :'(
>> > No one under windows ?
>>
>> You could try IBM Rational Purify. It's quite a nice tool and you can
>> download a trial version.
>> (You can also try to port your code to Linux. You get a triple
>> benefit: you can cross-check your code for compiler-specific hidden
>> bugs, you can use Valgrind and your app will run under Linux.)
>>
>> > Searching memory leaks, I use some libraries looking at leaks but it is
>> > very difficult to know if a leak is really one or not, specially due to
>> > ref_prt<>.
>> > Is there any free profiler (memory, time, number of acces, ...) for
>> > windows or even for VS 2005 (not Team edition) to trace an OSG based
>> > program
>> > ?
>>
>> I've never come across difficulties with ref_ptrs themselves. If you
>> don't create circular dependencies, they will free the memory they
>> point to and the memory leak detector will not report a false
>> positive. If you use the Microsoft compiler, do you get any reports
>> when leak detection is turned on ? (i.e. by calling
>> _CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) |
>> (_CRTDBG_LEAK_CHECK_DF)); at the beginning of your program)
>> If you do have reports here you obviously have a memory leak due to a
>> programming error, not related to ref_ptrs.
>>
>> Regards
>>
>> Thibault
>> _______________________________________________
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
