gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Annoying memory bug


From: Fred Kiefer
Subject: Re: Annoying memory bug
Date: Wed, 17 Mar 2010 20:17:17 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.8) Gecko/20100228 SUSE/3.0.3-1.1.1 Thunderbird/3.0.3

Am 17.03.2010 12:34, schrieb Richard Frith-Macdonald:
> 
> On 17 Mar 2010, at 09:26, Fred Kiefer wrote:
> 
>> I am trying to hunt down a very hard to catch memory issue. It
>> should be easy to reproduce for anybody interested. Just start up
>> Ink, open the info panel and start up the memory panel by clicking
>> on the icon. Now press the update button a few times until things
>> settle down.
>> 
>> If you keep on pressing update you will notice that only one value
>> keeps on changing. It is the amount of GSCBufferString objects at
>> increases by one every time you press the button. If you move the
>> mouse a bit, it will even increase more.
>> 
>> I was able to track down the lost string itself, it is 
>> @"NSStringPboardType". And it is easy to see that the problem
>> vanishes as soon as you close the last open document. This means
>> that the leak is most likely related to the NSTextView and there to
>> the pasteboard handling. It also goes away when I comment out the
>> contents of validateUserInterfaceItem:, that way it was possible to
>> track the problem down to the call to [[NSPasteboard
>> generalPasteboard] availableTypeFromArray: types]
>> 
>> It is the result value of this call that gets leaked. Now
>> NSPasteboard is implemented mostly as DO to the pasteboard server
>> and here I am lost. How could we leak memory here?
> 
> Bug in DO.
> 
> Thanks to you tracking the whole thing down with such precision, it
> was possible to know almost exactly where to look (it really had to
> be returning a string value from a method in a remote process) and I
> think I have a fix in place in NSConnection.m in svn (please try it
> out).
> 
> Probably we should do a thorough audit of how different data types
> are returned (either as a return value or a by-reference argument)
> from a method called over DO ... since the behavior of invocations
> has changed subtly over the years, and code which may once have been
> correct could now be leaking.  Unfortunately  I don't have time to do
> that right now.
> 

Great! This fixed the problem. Now I am back to the original reason why
I started the memory panel on Ink.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]