leaks again [solved]

Post Reply
gjaegy
Posts: 170
Joined: Fri Apr 18, 2008 2:20 pm

leaks again [solved]

Post by gjaegy » Mon Sep 08, 2008 9:40 am

Erwin,

I have tested the new 2.71 final release and still have memory leaks.

It is quite difficult to track them down as the memory allocation ID is random (lots of asynchronous stuffs in my app). I have managed to get the callstack however (by saving a screenshot for each 279-bytes alloc, which was quite a pain).

Anyway, look at the file attached, it shows the callstack for the last reported leak (as Visual Studio reports leaks in reverse allocation order). So by fixing the last reported one one might fix the other as well. See the leaks report below as well.

[edit] For your information, it looks a bit weird as some previously allocated memory (exactly same callstack) is properly destroyed. so maybe the clusters are generated recursively but not destroyed recursively ?? pure speculation though.

Cheers,
Greg

Code: Select all

Detected memory leaks!
Dumping objects ->
{467219} normal block at 0x071E61C8, 487 bytes long.
 Data: < a        H <  => C8 61 1E 07 ED ED ED ED 8C B6 48 BD 3C B7 AB 3D 
{467208} normal block at 0x071E6100, 139 bytes long.
 Data: <         a      > CD CD CD CD CD CD CD CD 00 61 1E 07 ED ED ED ED 
{467205} normal block at 0x071E5EA8, 535 bytes long.
 Data: < ^        l  f <> A8 5E 1E 07 ED ED ED ED FB 13 6C BD 80 66 E6 3C 
{467194} normal block at 0x071E5DD0, 151 bytes long.
 Data: <         ]      > CD CD CD CD CD CD CD CD D0 5D 1E 07 ED ED ED ED 
{467193} normal block at 0x071E5BA8, 487 bytes long.
 Data: < [       F ;P} => A8 5B 1E 07 ED ED ED ED E0 46 FF 3B 50 7D A9 3D 
{467185} normal block at 0x071E5AE0, 139 bytes long.
 Data: <         Z      > CD CD CD CD CD CD CD CD E0 5A 1E 07 ED ED ED ED 
{467181} normal block at 0x071E5868, 567 bytes long.
 Data: <hX        /    4> 68 58 1E 07 ED ED ED ED 19 C2 2F BE 00 00 80 34 
{467169} normal block at 0x071E5788, 159 bytes long.
 Data: < W         <   <> 88 57 1E 07 ED ED ED ED C1 09 1C 3C C1 09 1C 3C 
{467167} normal block at 0x071E55C0, 391 bytes long.
 Data: <         U      > CD CD CD CD CD CD CD CD C0 55 1E 07 ED ED ED ED 
{467160} normal block at 0x072085F8, 115 bytes long.
 Data: <           <   <> F8 85 20 07 ED ED ED ED C1 09 1C 3C C1 09 1C 3C 
{467158} normal block at 0x071E5338, 583 bytes long.
 Data: <8S       Hi= Q8>> 38 53 1E 07 ED ED ED ED CC 48 69 3D E8 51 38 3E 
{467146} normal block at 0x071E5258, 163 bytes long.
 Data: <XR         <   <> 58 52 1E 07 ED ED ED ED C1 09 1C 3C C1 09 1C 3C 
{467144} normal block at 0x071E5000, 535 bytes long.
 Data: <         P      > CD CD CD CD CD CD CD CD 00 50 1E 07 ED ED ED ED 
{467134} normal block at 0x071E4F28, 151 bytes long.
 Data: <(O         <   <> 28 4F 1E 07 ED ED ED ED C1 09 1C 3C C1 09 1C 3C 
{467132} normal block at 0x071E4CC0, 551 bytes long.
 Data: <         L      > CD CD CD CD CD CD CD CD C0 4C 1E 07 ED ED ED ED 
{467117} normal block at 0x071E4BE8, 155 bytes long.
 Data: < K         <   <> E8 4B 1E 07 ED ED ED ED C1 09 1C 3C C1 09 1C 3C 
{467115} normal block at 0x071E4990, 535 bytes long.
 Data: <         I      > CD CD CD CD CD CD CD CD 90 49 1E 07 ED ED ED ED 
{467104} normal block at 0x071E48B8, 151 bytes long.
 Data: < H         <   <> B8 48 1E 07 ED ED ED ED C1 09 1C 3C C1 09 1C 3C 
{467101} normal block at 0x071E4670, 519 bytes long.
 Data: <        pF      > CD CD CD CD CD CD CD CD 70 46 1E 07 ED ED ED ED 
{467100} normal block at 0x071E45A0, 147 bytes long.
 Data: <         E      > CD CD CD CD CD CD CD CD A0 45 1E 07 ED ED ED ED 
{467099} normal block at 0x071E4328, 567 bytes long.
 Data: <(C       ^ =    > 28 43 1E 07 ED ED ED ED AA 5E DB 3D 00 00 80 B4 
{467098} normal block at 0x0720C068, 159 bytes long.
 Data: <h          <   <> 68 C0 20 07 ED ED ED ED C1 09 1C 3C C1 09 1C 3C 
{467093} normal block at 0x071E4020, 711 bytes long.
 Data: <         @      > CD CD CD CD CD CD CD CD 20 40 1E 07 ED ED ED ED 
{467070} normal block at 0x07208320, 195 bytes long.
 Data: <                > CD CD CD CD CD CD CD CD 20 83 20 07 ED ED ED ED 
{467067} normal block at 0x0720BCB0, 887 bytes long.
 Data: <                > CD CD CD CD CD CD CD CD B0 BC 20 07 ED ED ED ED 
{467050} normal block at 0x07208FA0, 239 bytes long.
 Data: <                > CD CD CD CD CD CD CD CD A0 8F 20 07 ED ED ED ED 
{467049} normal block at 0x0720BA68, 519 bytes long.
 Data: <h       ?  =0   > 68 BA 20 07 ED ED ED ED 3F 18 87 3D 30 87 FE BD 
{467048} normal block at 0x071FF970, 147 bytes long.
 Data: <        p       > CD CD CD CD CD CD CD CD 70 F9 1F 07 ED ED ED ED 
{467046} normal block at 0x0720B810, 535 bytes long.
 Data: <                > CD CD CD CD CD CD CD CD 10 B8 20 07 ED ED ED ED 
{467036} normal block at 0x07209648, 151 bytes long.
 Data: <H          <   <> 48 96 20 07 ED ED ED ED C1 09 1C 3C C1 09 1C 3C 
{467035} normal block at 0x0720B638, 407 bytes long.
 Data: <8        l4 {]b>> 38 B6 20 07 ED ED ED ED 05 6C 34 BB 7B 5D 62 3E 
{467028} normal block at 0x071FE788, 119 bytes long.
 Data: <           <   <> 88 E7 1F 07 ED ED ED ED C1 09 1C 3C C1 09 1C 3C 
{467015} normal block at 0x0720A8C0, 3383 bytes long.
 Data: <                > CD CD CD CD CD CD CD CD C0 A8 20 07 ED ED ED ED 
{466953} normal block at 0x0720A520, 863 bytes long.
 Data: <                > CD CD CD CD CD CD CD CD 20 A5 20 07 ED ED ED ED 
{466946} normal block at 0x0720A180, 863 bytes long.
 Data: <                > CD CD CD CD CD CD CD CD 80 A1 20 07 ED ED ED ED 
{466934} normal block at 0x07208C80, 279 bytes long.
 Data: <                > CD CD CD CD CD CD CD CD 80 8C 20 07 ED ED ED ED 
{466910} normal block at 0x07209950, 279 bytes long.
 Data: <        P       > CD CD CD CD CD CD CD CD 50 99 20 07 ED ED ED ED 
{466908} normal block at 0x072097F8, 279 bytes long.
 Data: <        X       > F8 97 20 07 ED ED ED ED 58 AC 93 02 88 B8 93 02 
{466904} normal block at 0x07208B28, 279 bytes long.
 Data: <(       8       > 28 8B 20 07 ED ED ED ED 38 A4 93 02 C0 AC 93 02 
{466901} normal block at 0x071FE3B0, 279 bytes long.
 Data: <                > CD CD CD CD CD CD CD CD B0 E3 1F 07 ED ED ED ED 
{466891} normal block at 0x071FEB18, 151 bytes long.
 Data: <        P       > 18 EB 1F 07 ED ED ED ED 50 83 93 02 B8 83 93 02 
{466873} normal block at 0x07209720, 151 bytes long.
 Data: <                > CD CD CD CD CD CD CD CD 20 97 20 07 ED ED ED ED 
{466866} normal block at 0x071FF0C0, 151 bytes long.
 Data: <                > CD CD CD CD CD CD CD CD C0 F0 1F 07 ED ED ED ED 
{466852} normal block at 0x072094F0, 279 bytes long.
 Data: <                > CD CD CD CD CD CD CD CD F0 94 20 07 ED ED ED ED 
{466846} normal block at 0x07208A50, 151 bytes long.
 Data: <        P       > CD CD CD CD CD CD CD CD 50 8A 20 07 ED ED ED ED 
{466843} normal block at 0x07208978, 151 bytes long.
 Data: <x       @       > 78 89 20 07 ED ED ED ED 40 99 93 02 A8 99 93 02 
{461952} normal block at 0x072053F8, 151 bytes long.
 Data: < S      `       > F8 53 20 07 ED ED ED ED 60 87 93 02 C8 87 93 02 
{461876} normal block at 0x07205320, 151 bytes long.
 Data: <         S      > CD CD CD CD CD CD CD CD 20 53 20 07 ED ED ED ED 
{461691} normal block at 0x071FF7D0, 151 bytes long.
 Data: <                > CD CD CD CD CD CD CD CD D0 F7 1F 07 ED ED ED ED 
{461590} normal block at 0x071FF578, 535 bytes long.
 Data: <x        ~   ~  > 78 F5 1F 07 ED ED ED ED 08 7E 93 02 D8 7E 93 02 
{461550} normal block at 0x071FF420, 279 bytes long.
 Data: <                > CD CD CD CD CD CD CD CD 20 F4 1F 07 ED ED ED ED 
Object dump complete.
The program '[2644] ImagineViewerD.exe: Native' has exited with code 0 (0x0).
Attachments
bullet.png
bullet.png (225.61 KiB) Viewed 3502 times

gjaegy
Posts: 170
Joined: Fri Apr 18, 2008 2:20 pm

Re: leaks again [solved]

Post by gjaegy » Sat Sep 13, 2008 5:32 pm

nobody ?

User avatar
Erwin Coumans
Site Admin
Posts: 4189
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: leaks again

Post by Erwin Coumans » Sat Sep 13, 2008 6:03 pm

Can you help locating those memory leaks more in detail?

One way would be to comment out the following define in LinearMath\btAlignedAllocator.h

Code: Select all

#define BT_DEBUG_MEMORY_ALLOCATIONS 1
It will print out any allocation and de-allocation, with caller information. Perhaps it could help to locate where the issues are.
Thanks,
Erwin

chunky
Posts: 146
Joined: Tue Oct 30, 2007 9:23 pm

Re: leaks again

Post by chunky » Sat Sep 13, 2008 7:13 pm

It's also worth noting that valgrind is your friend. If your code is able to build on Linux [if it's not, port it to linux just so you can use valgrind...], make sure you compile with the -g option for debug symbols, and then hit it with valgrind. Valgrind neatly churns out a list of exactly how much memory [or other resources] is lost at exactly which points in the program.

I haven't busted out valgrind on my app in a few weeks, so once I upgrade to bullet-2.71 I'll probably be doing this myself.

Gary (-;

gjaegy
Posts: 170
Joined: Fri Apr 18, 2008 2:20 pm

Re: leaks again

Post by gjaegy » Mon Sep 15, 2008 9:35 am

Hi Erwin,

if you have a look at the screenshot I attached in the first stop, you can see the callstack that is responsible of the guilty allocation.

The method responsible of the allocation is btSoftBody::generateClusters(), line 825 in bullet 2.71.

However, this method is called several time, I guess it generates a recursive structure (maybe, hasn't checked). Some of the allocations done at this place are correctly freed (no leak reported), but some others are not. So i guess not the whole structure is cleaned correctly, maybe just the top level or something like this - pure speculation though.

I hope this help ?

Nathanael
Posts: 78
Joined: Mon Nov 13, 2006 1:44 am

Re: leaks again

Post by Nathanael » Mon Sep 15, 2008 10:10 am

Can you update your btSoftBody.h/cpp to latest svn version, and check if the leaks gone?

Thanks,
Nathanael.

gjaegy
Posts: 170
Joined: Fri Apr 18, 2008 2:20 pm

Re: leaks again

Post by gjaegy » Mon Sep 22, 2008 11:48 am

Nathanael,

first I would like to apologize for the late answer, I have been very busy with all sorts of things.

Anyway, I have tested your changes and I don't have any leak at all, so thanks a lot for that!

Cheers,
Gregory

User avatar
John McCutchan
Posts: 133
Joined: Wed Jul 27, 2005 1:05 pm
Location: Berkeley, CA
Contact:

Re: leaks again [solved]

Post by John McCutchan » Mon Sep 22, 2008 3:32 pm

Chunky is right. Valgrind is the best tool I have ever used to track down memory errors (leaks, double frees, touching memory you shouldn't.) When it detects a leak or error, you get a callstack and a hint at what you did wrong (eg "Touched memory 4 bytes past end of allocated buffer of size 128 bytes") It is worth porting your application to Linux (or MacOSX - Apple ships a valgrind derived tool in 10.5 - IRC.) just for this utility.

John

sparkprime
Posts: 508
Joined: Fri May 30, 2008 2:51 am
Location: Ossining, New York
Contact:

Re: leaks again [solved]

Post by sparkprime » Wed Sep 24, 2008 10:53 pm

John McCutchan wrote:Chunky is right. Valgrind is the best tool I have ever used to track down memory errors
It's awesome.

Also useful for certain kinds of profiling (callgraph, cache misses)

Post Reply