[Bf-committers] Blender linux console errors
ideasman42 at gmail.com
Fri Mar 11 05:48:28 CET 2011
On Fri, Mar 11, 2011 at 3:22 AM, Richard Shaw <hobbes1069 at gmail.com> wrote:
> On Thu, Mar 10, 2011 at 6:53 PM, Campbell Barton <ideasman42 at gmail.com> wrote:
>> On Fri, Mar 11, 2011 at 12:39 AM, Richard Shaw <hobbes1069 at gmail.com> wrote:
>>> Thanks to Campbell for the python script fix! Now the next problem. I
>>> have no clue what's causing this. When I exit blender I get a BUNCH of
>>> the following (more than I have scrollback history):
>>> C++/anonymous len: 16 0x3839868
>>> GHOST:GHOST_IEvent len: 40 0x3aaa498
>>> Any clue where to start?
>> Short is answer, no bug, disable WITH_CXX_GUARDEDALLOC.
>> Long answer: WITH_CXX_GUARDEDALLOC is off by default and not in the
>> standard view (you need to toggle advanced), which I did so people
>> didn't turn it on by accident :).
>> This is a debugging option which enables #ifdefs to override many
>> C++'s allocators with our C malloc replacement which complains of
>> unfreed memory.
>> These 'C++/anonymous len: 16 0x3839ce8', can be ignored since they are
>> variables like...
>> STR_String emptyString= "";
>> in the main body of C++ source and not worth the trouble to manually free.
>> 'GHOST:GHOST_IEvent len: 40 0x3aaa498' could be a leak but I'd not
>> worry about it unless they accumulate.
> Thanks! The GHOST error only occurs once so it's probably not a big
> deal. I ran blender under valgrind to see if anything jumped out at me
> and it did say there was a small leak but it didn't amount to much and
> I've read that valgrind can get confused by python memory management
> so I'm not even sure I can trust the results.
I once spent some time trying to track down the allocations valgrind
complains about and it seems they are either...
* allocations by 3rd party libs - openal/python/x11 for eg, variables
that are allocated once and kept
* blenders own global C++ variables as mentioned before.
* a handful of variables that are not freed on exit correctly like the
event, happens with ReportList's sometimes.
Each case could be fixed but it means adding extra init/free calls to
the game engine for eg, or working out why the last event isn't freed,
so its just a fair amount of time spent on tracking down something
which isn't really causing anyone to run our of memory.
To make valgrind play nice with python you need to build python
for tracking down bugs which are unrelated to python just build
without python is easiest.
valgrind is really handy but I don't bother with its on exit memory
leak messages, mostly our guarded-malloc gives more useful info.
Theres a wiki page for more details
More information about the Bf-committers