[Bf-cycles] Cycles memory leaks

[Sergey Sharybin]

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).

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.

On Wed, Jul 13, 2016 at 10:08 AM, Thomas Krebs <Thomas.Krebs at mecadtron.de>
wrote:

> Sergey,
>
> In blender_python.cpp:exit_func() I can see that you do:
>
>    ShaderManager::free_memory();
>    TaskScheduler::free_memory();
>    Device::free_memory();
>    device_list.free_memory();
>
> I copied the first three statements into the cycles main but this didn't
> help anything.
>
> Such initializers that produce leaks are e.g. in nodes.cpp in:
> static NodeEnum texture_mapping_projection_init()
> which are triggerered by:
> NodeEnum TextureMapping::projection_enum =
> texture_mapping_projection_init();
>
> AFAICS there is no interface in NodeEnum to properly free the allocated
> memory.
>
> Anyway, thanks for your effort.
>
> Thomas
>
>
> Am 12.07.2016 um 20:12 schrieb Sergey Sharybin:
> > Hi,
> >
> > In Blender we do use guarded allocator everywhere, including Cycles (at
> > least for it's major parts). I did not see any leaks reported. So can
> > you elaborate a bit more which exact memory is leaking?
> >
> > Think it worth addressing the issue unless it leads to some nasty code
> > workaorunds or makes integration into other software creepier.
> >
> > But all that being said, please make sure you're doing similar thing to
> > what we do in blender_python.cpp:exit_func(). This was the trick to make
> > staticly initialized data to be freed and make Blender's integration
> happy.
> >
> > We should probably need to move that code to ccl::Session::exit() and
> > call from standalone app as well.
> >
> > On Tue, Jul 12, 2016 at 6:31 PM, Thomas Krebs <Thomas.Krebs at mecadtron.de
> > <mailto:Thomas.Krebs at mecadtron.de>> wrote:
> >
> >     Hi,
> >
> >     We are currently trying to integrate cycles into our 3d app.
> >     We have successfully implemented a collada exporter from our app
> >     and produced some nice images in Blender.
> >     Now we got the standalone cycles app compiled and running.
> >     We found that cycles leaks quite some bit from some static
> >     initializers. As we try to solve leaks by monitoring leaks reports
> from
> >     MSVC this is somewhat problematic.
> >     Personally I would prefer not to have static initializers rather than
> >     some initialize/terminate functions, which would make cycles even
> more
> >     usable for integration in other systems.
> >     Is there some effort going on to address that situation or would such
> >     an effort be welcome?
> >     We might supply changes for that but we would leave it up to more
> >     experienced submitters to integrate such changes, if at all.
> >
> >     Thomas
> >     _______________________________________________
> >     Bf-cycles mailing list
> >     Bf-cycles at blender.org <mailto:Bf-cycles at blender.org>
> >     https://lists.blender.org/mailman/listinfo/bf-cycles
> >
> >
> >
> >
> > --
> > With best regards, Sergey Sharybin
> >
> >
> > _______________________________________________
> > Bf-cycles mailing list
> > Bf-cycles at blender.org
> > https://lists.blender.org/mailman/listinfo/bf-cycles
> >
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles
>



-- 
With best regards, Sergey Sharybin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20160713/d501c677/attachment.htm