Leak: Allocation Number increasing by one when reported

[himitsujanai]

Hi guys i have a memory leak in my program which the memory allocation number is increasing by one everytime its reported. I wanted to put a break point on it but I'm wondering if that allocation number make sense. Any idea what does it mean and how to track this? Here is the actual memory leak.

Detected memory leaks!
Dumping objects ->
{1986} normal block at 0x01CD66B0, 88 bytes long.
 Data: < Ls            > 8C 6C 45 10 00 00 00 00 CD CD CD CD 00 00 00 00 
Object dump complete.
Detected memory leaks!
Dumping objects ->
{1986} normal block at 0x01CD66B0, 88 bytes long.
 Data: < Ls             > 8C 6C 45 10 00 00 00 00 CD CD CD CD 00 00 00 00 
Object dump complete.
The program '[2232] SampleApp_d.exe: Native' has exited with code 0 (0x0).

that allocation number {1986} will be come {1987} next time the leak is reported.

[VictorN]

FAQ

[Igor Vartanov]

Enabling Memory Leak Detection
Setting a Breakpoint on a Memory Allocation Number
Detecting Memory Leaks in MFC

[himitsujanai]

FAQ

Thanks Victor but I already know how to manage and how to solved memory leak the point is this memory leak is a bit tricky and new to me because every time it reported the allocation number is increase by one and if i break point it its does not make any sense the one that it points to is a non suspected line of code. the others that i solved is a fixed allocation number and there's some information that u can use like the data, file and line where the leak occured

[S_M_A]

If you know that the allocation number increase by one you can compensate for that can't you?

[Paul McKenzie]

it its does not make any sense the one that it points to is a non suspected line of code.

Please show this line of code you say is "non-suspected".

Too many times, we get posters not showing code because they think the code isn't relevant to their problem. Then when we finally get to see the code that wasn't supposed to be relevant, it turns out that the code is the root cause of the problem.

Regards,

Paul McKenzie