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? Fred _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev