[Bf-cycles] Cycles memory leaks

[Sergey Sharybin]

Kevin,

libc itself can have some globally initialized variables which are out of
our control. It is important to understand that there possible (and are)
false-positive reports. We can't solve all of them.

On Tue, Jul 12, 2016 at 11:51 PM, Kévin Dietrich <kevin.dietrich at mailoo.org>
wrote:

> 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
>
>
>
> _______________________________________________
> 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/48d841d0/attachment.htm