[Bf-cycles] Cycles memory leaks

[Thomas Krebs]

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
>