[Bf-cycles] Cycles memory leaks

Kévin Dietrich kevin.dietrich at mailoo.org
Tue Jul 12 23:51:15 CEST 2016


Hi, 

The other day, I quickly tried my hand at implementing Alembic in Cycles
standalone, didn't really work out partly since Alembic files don't
store lights. Anyway, I did notice the following leak report from GCC: 

=================================================================
==643==ERROR: LeakSanitizer: detected memory leaks 

Direct leak of 32816 byte(s) in 1 object(s) allocated from:
#0 0x7f591193444a in malloc
(/usr/lib/x86_64-linux-gnu/libasan.so.2+0x9444a)
#1 0x7f590fbe4dd0 (/lib/x86_64-linux-gnu/libc.so.6+0xbcdd0) 

SUMMARY: AddressSanitizer: 32816 byte(s) leaked in 1 allocation(s). 

It's not very detailed, but I just tried again with master and it's
still there, though I don't know if it's the same issue as Thomas' or
just GCC being confused. Thought I'd share. 

Cheers, 

Kévin 

Le 2016-07-12 20:12, Sergey Sharybin a écrit :

> 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> 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
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20160712/2e6e2966/attachment.htm 


More information about the Bf-cycles mailing list