<div dir="ltr">Ah, those are using ustring from OIIO. Back in the days i've talked to Larry about a way to clean up storage used by ustring and at those days the answer was that nothing is explicitly cleared because of performance issues (it was taking too long to cleanup storage when invoking oslc fewzillions of times).<br><div><br></div><div>Now the ustring storage was reworked, but i can't remember if explicit clear of ustring is added/supported. Would need to dig into sources a bit more. Will do it in a bit.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 13, 2016 at 10:08 AM, Thomas Krebs <span dir="ltr"><<a href="mailto:Thomas.Krebs@mecadtron.de" target="_blank">Thomas.Krebs@mecadtron.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sergey,<br>
<br>
In blender_python.cpp:exit_func() I can see that you do:<br>
<br>
ShaderManager::free_memory();<br>
TaskScheduler::free_memory();<br>
Device::free_memory();<br>
device_list.free_memory();<br>
<br>
I copied the first three statements into the cycles main but this didn't<br>
help anything.<br>
<br>
Such initializers that produce leaks are e.g. in nodes.cpp in:<br>
static NodeEnum texture_mapping_projection_init()<br>
which are triggerered by:<br>
NodeEnum TextureMapping::projection_enum =<br>
texture_mapping_projection_init();<br>
<br>
AFAICS there is no interface in NodeEnum to properly free the allocated<br>
memory.<br>
<br>
Anyway, thanks for your effort.<br>
<br>
Thomas<br>
<span class=""><br>
<br>
Am 12.07.2016 um 20:12 schrieb Sergey Sharybin:<br>
> Hi,<br>
><br>
> In Blender we do use guarded allocator everywhere, including Cycles (at<br>
> least for it's major parts). I did not see any leaks reported. So can<br>
> you elaborate a bit more which exact memory is leaking?<br>
><br>
> Think it worth addressing the issue unless it leads to some nasty code<br>
> workaorunds or makes integration into other software creepier.<br>
><br>
> But all that being said, please make sure you're doing similar thing to<br>
> what we do in blender_python.cpp:exit_func(). This was the trick to make<br>
> staticly initialized data to be freed and make Blender's integration happy.<br>
><br>
> We should probably need to move that code to ccl::Session::exit() and<br>
> call from standalone app as well.<br>
><br>
> On Tue, Jul 12, 2016 at 6:31 PM, Thomas Krebs <<a href="mailto:Thomas.Krebs@mecadtron.de">Thomas.Krebs@mecadtron.de</a><br>
</span><span class="">> <mailto:<a href="mailto:Thomas.Krebs@mecadtron.de">Thomas.Krebs@mecadtron.de</a>>> wrote:<br>
><br>
> Hi,<br>
><br>
> We are currently trying to integrate cycles into our 3d app.<br>
> We have successfully implemented a collada exporter from our app<br>
> and produced some nice images in Blender.<br>
> Now we got the standalone cycles app compiled and running.<br>
> We found that cycles leaks quite some bit from some static<br>
> initializers. As we try to solve leaks by monitoring leaks reports from<br>
> MSVC this is somewhat problematic.<br>
> Personally I would prefer not to have static initializers rather than<br>
> some initialize/terminate functions, which would make cycles even more<br>
> usable for integration in other systems.<br>
> Is there some effort going on to address that situation or would such<br>
> an effort be welcome?<br>
> We might supply changes for that but we would leave it up to more<br>
> experienced submitters to integrate such changes, if at all.<br>
><br>
> Thomas<br>
> _______________________________________________<br>
> Bf-cycles mailing list<br>
</span>> <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a> <mailto:<a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a>><br>
<div class="HOEnZb"><div class="h5">> <a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
><br>
><br>
><br>
><br>
> --<br>
> With best regards, Sergey Sharybin<br>
><br>
><br>
> _______________________________________________<br>
> Bf-cycles mailing list<br>
> <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
> <a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
><br>
<br>
_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
<a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div><span style="color:rgb(102,102,102)">With best regards, Sergey Sharybin</span></div></div>
</div>