gnustep-dev
[Top][All Lists]
Advanced

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

Trouble with toolbars


From: Fred Kiefer
Subject: Trouble with toolbars
Date: Tue, 06 Jan 2009 13:06:44 +0100
User-agent: Thunderbird 2.0.0.18 (X11/20081112)

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?)

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?




reply via email to

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