[Top][All Lists]
[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.