[Bf-cycles] Cycles memory leaks
kevin.dietrich at mailoo.org
Tue Jul 12 23:51:15 CEST 2016
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
#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.
Le 2016-07-12 20:12, Sergey Sharybin a écrit :
> 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:
>> 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.
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
> With best regards, Sergey Sharybin
> Bf-cycles mailing list
> Bf-cycles at blender.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bf-cycles