gnustep-dev
[Top][All Lists]
Advanced

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

Re: Trouble with toolbars


From: Wolfgang Lux
Subject: Re: Trouble with toolbars
Date: Tue, 6 Jan 2009 18:57:33 +0100

Hi Fred!

I am currently getting a back trace when closing Gorm after working with
a project. The back trace looks like this:

#0  0xb763d734 in objc_msg_lookup () from /usr/lib/libobjc.so.2
#1  0xb7eb194f in -[GormGenericEditor refreshCells] (self=0x8887050,
    _cmd=0xb7f17a88) at GormGenericEditor.m:299
#2  0xb7eb1cda in -[GormGenericEditor resizeWithOldSuperviewSize:] (
self=0x8887050, _cmd=0xb7de7af8, oldSize={width = 313, height = 163})
    at GormGenericEditor.m:333
#3 0xb7c88459 in -[NSView resizeSubviewsWithOldSize:] (self=0x88c5e78, _cmd=0xb7de7a58, oldSize={width = 313, height = 163}) at NSView.m:1812 #4 0xb7c854ed in -[NSView setFrame:] (self=0x88c5e78, _cmd=0xb7d69ff0,
    frameRect=
{origin = {x = 21, y = 2}, size = {width = 313, height = 225}})
    at NSView.m:1129
#5  0xb7b519ad in -[NSClipView setFrame:] (self=0x88c5e78,
    _cmd=0xb7de7b08, rect=
{origin = {x = 21, y = 2}, size = {width = 313, height = 225}})
    at NSClipView.m:584
#6 0xb7c88707 in -[NSView resizeWithOldSuperviewSize:] (self=0x88c5e78, _cmd=0xb7de7af8, oldSize={width = 336, height = 186}) at NSView.m:1911 #7 0xb7c88459 in -[NSView resizeSubviewsWithOldSize:] (self=0x88c5ca8, _cmd=0xb7dc4058, oldSize={width = 336, height = 186}) at NSView.m:1812
#8  0xb7c31d42 in -[NSScrollView resizeSubviewsWithOldSize:] (
self=0x88c5ca8, _cmd=0xb7de7a58, oldSize={width = 336, height = 186})
    at NSScrollView.m:1226
#9 0xb7c854ed in -[NSView setFrame:] (self=0x88c5ca8, _cmd=0xb7dc3fc8,
    frameRect=
        {origin = {x = 5, y = 5}, size = {width = 336, height = 248}})
    at NSView.m:1129
#10 0xb7c309bf in -[NSScrollView setFrame:] (self=0x88c5ca8,
    _cmd=0xb7d5d650, rect=
        {origin = {x = 5, y = 5}, size = {width = 336, height = 248}})
    at NSScrollView.m:964
#11 0xb7b2c9b8 in -[NSBox setFrame:] (self=0x88ab6f8, _cmd=0xb7de7b08,
    frameRect=
        {origin = {x = 0, y = 0}, size = {width = 346, height = 258}})
    at NSBox.m:298
#12 0xb7c88707 in -[NSView resizeWithOldSuperviewSize:] (self=0x88ab6f8, _cmd=0xb7d5d748, oldSize={width = 346, height = 196}) at NSView.m:1911 #13 0xb7b2dce6 in -[NSBox resizeWithOldSuperviewSize:] (self=0x88ab6f8, _cmd=0xb7de7af8, oldSize={width = 346, height = 196}) at NSBox.m:425 #14 0xb7c88459 in -[NSView resizeSubviewsWithOldSize:] (self=0x88ab590, _cmd=0xb7de7a58, oldSize={width = 346, height = 196}) at NSView.m:1812 #15 0xb7c854ed in -[NSView setFrame:] (self=0x88ab590, _cmd=0xb7e1eba0,
    frameRect=
        {origin = {x = 4, y = 4}, size = {width = 346, height = 258}})
    at NSView.m:1129
#16 0xb7d25228 in -[GSWindowDecorationView(ToolbarPrivate)
removeToolbarView:] (self=0x88aa928, _cmd=0xb7de8540, toolbarView=0x88b7808)
    at GSWindowDecorationView.m:347
#17 0xb7c941f2 in -[NSWindow(Toolbar) setToolbar:] (self=0x88a9e48,
    _cmd=0xb7dee1d8, toolbar=0x0) at NSWindow+Toolbar.m:92
#18 0xb7c96e82 in -[NSWindow dealloc] (self=0x88a9e48, _cmd=0xb7a08f08)
    at NSWindow.m:732


To summon up what happens: The window gets deallocated to clean up it
frees the toolbar which results in a resize of the content view and this
ends in GormGenericEditor refreshCells where an invalid document
instance variable gets dereferenced.
Now in this specific case it surely would help to get Gorm to clean up
the document instance variable and there is already code to do so, most
likely it is just not working in this specific case. (Closing the
project first and then quiting Gorm works)
After a long analysis I would suggest to call willCloseDocument: from
close: either in GormGenericEditor or GormObjectEditor, the actual class that causes this problem. (Greg, could you please verify this solution?)

Just a small note: I do not understand why the content view of the Gorm
window is resized at all in this case. If the toolbar is part of the window's decoration view the content view of the window should not change its frame at all if the toolbar is inserted or removed, except maybe for those border cases where the whole window is resized in order to fit within the screen (however note that NSWindow on Mac OS X 10.4 and earlier does not show this behavior, so maybe you shouldn't care either -- at least until the toolbar
implementation stabilizes).

But there is a more general problem here, we shouldn't rely on all the
views still being fully functional when the window is deallocated. Why
do I call the setToolbar: method to free the toolbar in the first place?
Wouldn't it be easier to just DESTROY() the toolbar instance? Yes, but
it would leave a memory leak. Currently the toolbar view retains the
toolbar and this gets only released when the toolbar is removed from the
window.
So why didn't this cause problems before? The whole toolbar framework
was heavily leaking objects. Also the toolbar view was already removed
when the window was closed, most likely at that point in time the
document in Gorm was still valid.

How to proceed? If you would know, I wouldn't be writing this mail :-)
What I would like to do is rewrite the toolbar framework, so that the
toolbar retains the toolbar view and not the other way round. There is
one big drawback to that, it makes it harder to code stand alone
toolbars, where the toolbar isn't embedded in the window, instead it is in the normal view hierarchy. For that case we will then have to retain
the toolbar and for code like ToolbarExample this would result in a
memory leak. Is this acceptable?

I just did a quick test with Apple's ObjectAlloc and it looks like on
Mac OS X the toolbar retains its view and not vice versa. In addition,
the toolbar itself is retained by the window upon passing it to
-setToolbar:. This means that if a program wants to insert a toolbar
view into the view hierarchy at some other point it remains the owner
of the toolbar and is responsible for releasing the toolbar when the
toolbar view is removed from the view hierarchy or the whole window
is closed. A memory leak of course isn't acceptable, but then it looks
like there is an error in ToolbarExample if it does leak (I haven't
looked into its source, though).

Wolfgang





reply via email to

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