Re: memory leak - cairo/x11 backend

[Fred Kiefer]

On 22.12.2013 19:58, Riccardo Mottola wrote:
> Fred Kiefer wrote:
>> I am able to reproduce this behaviour, but I am unsure about what it
>> means. I did an in depth inspection with the memory panel of GNUstep,
>> but this didn't show up a specific issue. (BTW the memory panel is hard
>> to use with Laterna Magica. The AppController registers itself for the
>> notification NSTableViewSelectionDidChangeNotification and as the
>> fileListView is still null at the point in time where this happens it
>> will get called even from the memory panel. The same is true for the
>> other notification. You should move these calls into the awakeFromNib
>> method)
> Fine, I just moved those calls as you suggested.

No you didn't :-(

> I pointed out to two memory leaks: not only the Xorg doesn't get back to
> its original memory usage, but also LaternaMagica itself: in the example
> I went from X: 108 LM: 58, to X: 142 LM: 91. That is about a 35MB
> increase for the server, but also a 33MB increase of LM! Thus I see a
> problem on both sides, let's analyze LM, perhaps the problem is there
> and now the Xorg problem is a reflection of that.
> 
> You didn't find anything obvious, I too tried the memory panel without
> success. At start, I see no NSImageViews! why?
> 
> Clicking on an item yields
> 2013-12-22 18:47:19.268 LaternaMagica[14382] Problem posting
> notification: <NSException: 0x8127f00> NAME:NSRangeException
> REASON:Index 11 is out of range 0 (in
> 'objectAtIndex:') INFO:{Array = (); Count = 0; Index = 11; }

You get this message as I explained above because the AppController
tries to handle notifications from the memory panel. Move the calls and
this will stop to show up. If it doesn't, then the instance variable
fileListView you are using is not set during NIB loading. Please check
your Gorm file in that case.

> Anyway, at start I see:
> NSBitmapImageRep: 12
> NSImageView: ?
> NSImage: ?

You should at least open the open file panel once to have a real
baseline. Better yet, open one image and remove it and use that
situation for the memory panel.

> I load an image, while displaying it:
> NSBitmapImageRep: 34
> NSImageView: 1
> NSImage: 193
> 
> I remove the image (do not "delete" it while testing :) )
> NSBitmapImageRep: 33
> NSImageView: 1
> NSImage: 192
> 
> I don't know the original state, but it went back of one, so Indeed
> something get released, but is it enough?

You should keep on adding and removing an image and look at the
difference between before and after. If there is a leak in GNUstep
objects and you do these steps often enough the class will show up in
the memory panel.
If we have a leak at C level or in the X resource consumption you wont
find it that way.

>> There is a lot of other strange code in Laterna Magica, for example:
>>
>>    [view setImage: destImage];
>>    [view setNeedsDisplay:YES];
>>    [[view superview] setNeedsDisplay:YES];
>>    [window displayIfNeeded];
>>
>> Here only the first line should be needed. Why is the rest there?
>> But none of that looks like an obvious memory leak.
> I will check that, it looks I desperately had some redraw problems. That
> code needs to work both inside a window and with a full-screen window.
> Perhaps it is not needed anymore, I will check on Mac and GNUstep.
> However, you say yourself that it shouldn't cause memory problems. At
> most, it is inefficient/inelegant.
> 
>>
>> I also tried to see any specific memory leaks with valgrind, but here
>> the normal GNUstep leaks overshadow the output.
> Well, "normal leaks".....

I was referring to valgrind reporting any font or image that GNustep
loads and stores in global variables as a leak. Richard added code to
base to be able to remove such resources at program exit to be able to
inspect memory issues better. Maybe I need to add such code in gui and
back as well.

>> And I am still not completely convinced that there is a problem. When I
>> keep on loading and removing images the size of the XOrg process keeps
>> returning to the same value it had before. Not to the initial one, but
>> it does not keep on growing endlessly. It is more like the biggest image
>> ever loaded in Laterna Magica determines the additional resource usage
>> of the X process.

You did not reply to this bit. I think it is the most important one. If
we are really talking about a leak it should get worse, but this is not
what I see. When I keep on loading one image and remove it immediately
the memory consumption stays at about the same level. When I load a lot
of images at once the value goes up and stays there.