Plugin Cafe Homepage
Forum Home Forum Home > Plugin Cafe > General Discussion
  New Posts New Posts
  FAQ FAQ  Forum Search   Register Register  Login Login

Memory leak hunting

 Post Reply Post Reply
Author
Message
C4DS View Drop Down
Member
Member


Joined: 2015 Dec 01
Online Status: Offline
Posts: 107
Post Options Post Options   Quote C4DS Quote  Post ReplyReply Direct Link To This Post Topic: Memory leak hunting
    Posted: 2017 Sep 29 at 1:37am
Hi again,
I understand this post isn't quite about the SDK, and probably more C++ related, hence the reason I posted it here in the "General Discussion" area rather than in the SDK part of the forum.

After days of trying to track down some memory leaks I realized ... I simply don't know what I am doing.

In the past I used to narrow down the memory leaks to a particular code, from detecting in which part of the plugins things were being performed resulting in memory leaks.
But with this new project, there is just too many things going on at once that I don't know where to start looking.

Additionally, I am confused with the information I have regarding memory addresses.
While debugging, looking at the modules I noticed that the plugin (assumably) resides at address 0x7FFA1C2E0000, but using breakpoints in the code to check on the progress of interactions, I notice that all objects are residing around 0x000000DAxxxxxxxx, with a memory leak occuring at

Memory Leaks Detected:
p:\c4d_perforce_work\release\18.0\modules\c4dplugin\source\src\philip\pluginsystem\operatingsystem.cpp (1323): Memory leak of 64 bytes () at 000000DA896ABA40
1 blocks not freed


While looking at the .map file generated by Visual Studio, I notice

Preferred load address is 0000000180000000

Now, I understand that this "preferred" load address isn't typically the address the plugin gets loaded at, so all memory address of the .map file will need to be "translated" to the appropriate entry point. But that's where I am confused. What is the actual entry point address of the plugin?
How do I "map" the memory leak address to my objects and functions in the plugin?

I have tried google as well, only finding explanations using a simple .exe where the actual entry point address of the application is obvious.

Would appreciate any hints how to proceed.
Thanks,
Daniel
Back to Top
S_Bach View Drop Down
Forum Moderator
Forum Moderator
Avatar

Joined: 2011 Jun 27
Online Status: Offline
Posts: 1321
Post Options Post Options   Quote S_Bach Quote  Post ReplyReply Direct Link To This Post Posted: 2017 Oct 02 at 1:18am
Hello,

I'm no expert on this topic so I won't comment on it. But what I can say is that the line above references the allocation of a BaseSelect object. So somewhere a BaseSelect object is allocated that is not freed at the end.

best wishes,
Sebastian
SDK Support Engineer
Back to Top
C4DS View Drop Down
Member
Member


Joined: 2015 Dec 01
Online Status: Offline
Posts: 107
Post Options Post Options   Quote C4DS Quote  Post ReplyReply Direct Link To This Post Posted: 2017 Oct 03 at 3:50am
Thanks Sebastian.
I commented out pieces of the plugin until I found the part that was responsible for the memory leak.
It was indeed a BaseSelect.
I was using an AutoAlloc<BaseSelect> and assigned a clone of a selection, without first performing a Free().

Still, tips on how to detect where the offending call is performed are still welcome. Commenting out pieces is not always a solution. Even if it is it can take up quite some time before finding the right location.
Back to Top
C4DS View Drop Down
Member
Member


Joined: 2015 Dec 01
Online Status: Offline
Posts: 107
Post Options Post Options   Quote C4DS Quote  Post ReplyReply Direct Link To This Post Posted: 2017 Oct 06 at 3:13am
Got a few more memoryleaks popping up.
Knowing what these are about might point me in the right direction were to look.


Memory Leaks Detected:
p:\c4d_perforce_work\release\19.0\modules\c4dplugin\source\src\thomas\glsl\gl_program_factory.cpp (7011): Memory leak of 640 bytes () at 000000BD2EAF38C0
p:\c4d_perforce_work\release\19.0\modules\model\source\gui\ViewportNaviCube.cpp (216): 5 Memory leaks of 24 bytes (, first leak at 000000C5D62B6980)
p:\c4d_perforce_work\release\19.0\modules\model\source\gui\ViewportNaviCube.cpp (217): 5 Memory leaks of 1128 bytes (, first leak at 000000BD60660980)
3 blocks not freed



p:\c4d_perforce_work\release\19.0\modules\c4dplugin\source\src\philip\objects\polygonobject.cpp (12417): 6 Memory leaks of 15387 bytes (, first leak at 0000002F30617700)


Thanks


Edited by C4DS - 2017 Oct 06 at 4:59am
Back to Top
S_Bach View Drop Down
Forum Moderator
Forum Moderator
Avatar

Joined: 2011 Jun 27
Online Status: Offline
Posts: 1321
Post Options Post Options   Quote S_Bach Quote  Post ReplyReply Direct Link To This Post Posted: 2017 Oct 06 at 9:03am
Hello,

these source code locations refer to internal elements of the OpenGL viewport system. It could be that this is somehow related to the HUD system. That's all I can say.

The last issue is related to Ngons (GetNgonEdgesCompact()).

best wishes,
Sebastian
SDK Support Engineer
Back to Top
C4DS View Drop Down
Member
Member


Joined: 2015 Dec 01
Online Status: Offline
Posts: 107
Post Options Post Options   Quote C4DS Quote  Post ReplyReply Direct Link To This Post Posted: 2017 Oct 06 at 9:14am
Thanks Sebastian.

Ngons ... strange, as I don't support nor handle ngons in my plugin.
Is is that GetNgonEdgesCompact() is internally called as a result of other calls?

I have further investigated, and can confirm that the polygon object I was handling does indeed contain Ngons, but no where in the plugin do I call Ngon related functions.


Edited by C4DS - 2017 Oct 07 at 4:51am
Back to Top
S_Bach View Drop Down
Forum Moderator
Forum Moderator
Avatar

Joined: 2011 Jun 27
Online Status: Offline
Posts: 1321
Post Options Post Options   Quote S_Bach Quote  Post ReplyReply Direct Link To This Post Posted: 2017 Oct 10 at 12:31am
Hello,

based on the memory leak report it is impossible to say in which context GetNgonEdgesCompact() was called. The function is called internally in various situations including selection, subdivision, cloning, UV-editing, etc.

best wishes,
Sebastian

SDK Support Engineer
Back to Top
gr4ph0s View Drop Down
Member
Member


Joined: 2015 Jul 07
Location: France
Online Status: Online
Posts: 366
Post Options Post Options   Quote gr4ph0s Quote  Post ReplyReply Direct Link To This Post Posted: 2017 Oct 10 at 3:33am
I don't know if it's possible but, get the actual call stack linked to the memory leak would be nice.
But since we can't know memory leak on runtime (wich it's obvious), it should be hard, or memory intensive to store a call stack for every new allocation.
Or at least to get block of memory leak detection. A bit like undo where you start/end block and add event for each new allocation.
Or using a metaclass for get memory before/after each functions and allow user to check if it's normal or not.
It's just an idea, it may ask a lot of developpement time for not so much things.


Technical lover.
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down

Bulletin Board Software by Web Wiz Forums® version 9.61 [Free Express Edition]
Copyright ©2001-2009 Web Wiz

This page was generated in 0.094 seconds.