Please help 
Author Message
 Please help

Hi All,
   When my debug version app exit, the debug console always display
following information:
    pid 1120 : Detected memory leaks!
    pid 1120 : Dumping objects ->
    pid 1120 : {429}     pid 1120 : normal block at 0x00A38AF8, 84 bytes
long.
    pid 1120 :  Data: <                > 02 00 00 00 00 00 00 00 F4 80 A3 00
01 00 00 00
    pid 1120 : {427}     pid 1120 : normal block at 0x00A38A70, 84 bytes
long.
    pid 1120 :  Data: <                > 02 00 00 00 00 00 00 00 F4 80 A3 00
02 00 00 00
    pid 1120 : {425}     pid 1120 : normal block at 0x00A389E8, 84 bytes
long.
    pid 1120 :  Data: <                > 02 00 00 00 00 00 00 00 F4 80 A3 00
00 00 00 00
    pid 1120 : Object dump complete.
I want to know:
   1. What's name of the source code file related the line number?
   2. How can I find which handle I forgot to release? that is, how
to find the variable name of 0x00A38AF8, 0x00A38A70 and 0x00A389E8?

Thanks in advance.
Tian



Fri, 27 May 2005 01:55:45 GMT  
 Please help
Tian,
        In this case, the memory dump does not include line numbers.  The
numbers in braces ({425}, {427}, {429}) are allocation numbers.  This
means that the 425th, 427th and 429th allocations (using that allocator)
were leaked.  These were just "normal blocks", so they didn't have
stored the source file and line number as "client blocks" often will.
        If you can reliably reproduce the memory leak, and if it always is
the same allocation numbers, then you can set a conditional breakpoint
in the allocator for when the number is 425.  Once the breakpoint is
reached, simply look in the call stack to determine where the allocation
was initiated.
        If it is not predictably reproducible, then you'll have to do more
sleuthing.  In the memory dump, only the first 16 bytes are displayed,
even though the leaked blocks are 84 bytes long each.  If you set a
breakpoint in the code that produces these memory dumps, you can use the
memory pane to see the entire contents of the blocks.  Perhaps in the
full 84 bytes, you can recognize the structure being leaked, and thereby
discover the origin.
        Just from the 16 bytes displayed, there are some clues.  It's
clear that after the first 8 bytes, there is a 4-byte pointer in the
leaked structures.  In this case, all three of the pointers refer to
address 0x00A380F4.  Also, following the pointer, there is an integer
with values 0, 2, and 1, (for allocations 425, 427, and 429,
respectively).
        Good luck!


Quote:
> Hi All,
>    When my debug version app exit, the debug console always display
> following information:
>     pid 1120 : Detected memory leaks!
>     pid 1120 : Dumping objects ->
>     pid 1120 : {429}     pid 1120 : normal block at 0x00A38AF8, 84 bytes
> long.
>     pid 1120 :  Data: <                > 02 00 00 00 00 00 00 00 F4 80 A3 00
> 01 00 00 00
>     pid 1120 : {427}     pid 1120 : normal block at 0x00A38A70, 84 bytes
> long.
>     pid 1120 :  Data: <                > 02 00 00 00 00 00 00 00 F4 80 A3 00
> 02 00 00 00
>     pid 1120 : {425}     pid 1120 : normal block at 0x00A389E8, 84 bytes
> long.
>     pid 1120 :  Data: <                > 02 00 00 00 00 00 00 00 F4 80 A3 00
> 00 00 00 00
>     pid 1120 : Object dump complete.
> I want to know:
>    1. What's name of the source code file related the line number?
>    2. How can I find which handle I forgot to release? that is, how
> to find the variable name of 0x00A38AF8, 0x00A38A70 and 0x00A389E8?

> Thanks in advance.
> Tian



Fri, 27 May 2005 10:36:19 GMT  
 Please help
Thanks Scot,
    Those memory leak can be predictably reproduced when the app exits,
it always appears after  CWinApp::ExitInstance() called, anyway
every time I execute the app, the allocation number is different.
Would you please give me further hint on how to set breakpoint
to trap this?

Regards
Tian.



Quote:
> Tian,
> In this case, the memory dump does not include line numbers.  The
> numbers in braces ({425}, {427}, {429}) are allocation numbers.  This
> means that the 425th, 427th and 429th allocations (using that allocator)
> were leaked.  These were just "normal blocks", so they didn't have
> stored the source file and line number as "client blocks" often will.
> If you can reliably reproduce the memory leak, and if it always is
> the same allocation numbers, then you can set a conditional breakpoint
> in the allocator for when the number is 425.  Once the breakpoint is
> reached, simply look in the call stack to determine where the allocation
> was initiated.
> If it is not predictably reproducible, then you'll have to do more
> sleuthing.  In the memory dump, only the first 16 bytes are displayed,
> even though the leaked blocks are 84 bytes long each.  If you set a
> breakpoint in the code that produces these memory dumps, you can use the
> memory pane to see the entire contents of the blocks.  Perhaps in the
> full 84 bytes, you can recognize the structure being leaked, and thereby
> discover the origin.
> Just from the 16 bytes displayed, there are some clues.  It's
> clear that after the first 8 bytes, there is a 4-byte pointer in the
> leaked structures.  In this case, all three of the pointers refer to
> address 0x00A380F4.  Also, following the pointer, there is an integer
> with values 0, 2, and 1, (for allocations 425, 427, and 429,
> respectively).
> Good luck!


> > Hi All,
> >    When my debug version app exit, the debug console always display
> > following information:
> >     pid 1120 : Detected memory leaks!
> >     pid 1120 : Dumping objects ->
> >     pid 1120 : {429}     pid 1120 : normal block at 0x00A38AF8, 84 bytes
> > long.
> >     pid 1120 :  Data: <                > 02 00 00 00 00 00 00 00 F4 80
A3 00
> > 01 00 00 00
> >     pid 1120 : {427}     pid 1120 : normal block at 0x00A38A70, 84 bytes
> > long.
> >     pid 1120 :  Data: <                > 02 00 00 00 00 00 00 00 F4 80
A3 00
> > 02 00 00 00
> >     pid 1120 : {425}     pid 1120 : normal block at 0x00A389E8, 84 bytes
> > long.
> >     pid 1120 :  Data: <                > 02 00 00 00 00 00 00 00 F4 80
A3 00
> > 00 00 00 00
> >     pid 1120 : Object dump complete.
> > I want to know:
> >    1. What's name of the source code file related the line number?
> >    2. How can I find which handle I forgot to release? that is, how
> > to find the variable name of 0x00A38AF8, 0x00A38A70 and 0x00A389E8?

> > Thanks in advance.
> > Tian



Fri, 27 May 2005 14:03:05 GMT  
 Please help

Quote:

>     pid 1120 : Detected memory leaks!
>    1. What's name of the source code file related the line number?
>    2. How can I find which handle I forgot to release? that is, how
> to find the variable name of 0x00A38AF8, 0x00A38A70 and 0x00A389E8?

  You can use my tool:
  http://www.codeproject.com/useritems/leakfinder.asp

Then you will get the callstack of the allocation, and so you can fix the
problem.

--
Greetings
  Jochen

  Do you need a memory-leak finder ?
  http://www.codeproject.com/useritems/leakfinder.asp



Fri, 27 May 2005 15:13:39 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Please help!!!!Please help!!!!Please help!!!!Please help!!!!Please help!!!!Please help!!!!Please help!!!!

2. Please help!!!!Please help!!!!Please help!!!!

3. NEED HELP WITH PRITING AN ARRAY, PLEASE PLEASE HELP

4. PLEASE PLEASE HELP HELP...question on interleaving C functions

5. Please Please Help!!!!!!

6. ICloneable - Please help.....please....

7. simulate dragDrop of ListView Item -- Please Please Help!!!!

8. Very Urgent !!! please please help

9. please help with algorythm, PLEASE

10. Please Please Help!!!!!!

11. PLEASE PLEASE HELP

12. Please Please Help! - pointer notation

 

 
Powered by phpBB® Forum Software