[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #6354] Failing to load a .gorm which uses a NSImageView custom clas
From: |
nobody |
Subject: |
[bug #6354] Failing to load a .gorm which uses a NSImageView custom class in a NSScrollView |
Date: |
Sat, 22 Nov 2003 09:20:13 -0500 |
User-agent: |
Mozilla/4.74 [en] (X11; U; Linux 2.0.36 i686) |
=================== BUG #6354: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=6354&group_id=99
Changes by: Alexander Malmberg <alexander@malmberg.org>
Date: Sat 11/22/2003 at 15:20 (Europe/Stockholm)
What | Removed | Added
---------------------------------------------------------------------------
Resolution | None | Fixed
Status | Open | Analyzed
------------------ Additional Follow-up Comments ----------------------------
The root cause is that the app in question makes calls that manipulate the view
hierarchy from -drawRect:. It removes the NSScroller subviews of the
NSScrollView. This confuses the display machinery which still tries to make
calls to the NSScroller:s that are now outside the view hierarchy, and this
causes the exception.
Recovery from the exception fails because the gorm-loading code is releasing
all connections twice, leading to memory corruption and, usually, a segfault.
I've fixed this part in cvs.
As I see it, view manipulation from inside the display machinery (including
-drawRect:) is not allowed, and changing the view hierarchy is definately an
error. Thus, I consider this an application error.
Since this was pretty obscure and took a bit of work to track down, I'll try to
get some asserts in place to catch view hierarchy manipulation during
displaying earlier.
=================== BUG #6354: FULL BUG SNAPSHOT ===================
Submitted by: gcasa Project: GNUstep
Submitted on: Tue 11/04/2003 at 09:39
Category: Gui/AppKit Severity: 3
Bug Group: Bug Resolution: Fixed
Assigned to: gcasa Status: Analyzed
Summary: Failing to load a .gorm which uses a NSImageView custom class in a
NSScrollView
Original Submission: This only occurs when the application is using
NSWindowController and uses a NSScrollView which contains an instance of a
custom class (specifically a subclass of NSImageView). I have been unable to
recreate this under any other circumstance.
I don't believe this to be a Gorm issue since the Gorm file loads and saves
find and upon inspection doesn't appear to have any problems.
Follow-up Comments
*******************
-------------------------------------------------------
Date: Sat 11/22/2003 at 15:20 By: alexm
The root cause is that the app in question makes calls that manipulate the view
hierarchy from -drawRect:. It removes the NSScroller subviews of the
NSScrollView. This confuses the display machinery which still tries to make
calls to the NSScroller:s that are now outside the view hierarchy, and this
causes the exception.
Recovery from the exception fails because the gorm-loading code is releasing
all connections twice, leading to memory corruption and, usually, a segfault.
I've fixed this part in cvs.
As I see it, view manipulation from inside the display machinery (including
-drawRect:) is not allowed, and changing the view hierarchy is definately an
error. Thus, I consider this an application error.
Since this was pretty obscure and took a bit of work to track down, I'll try to
get some asserts in place to catch view hierarchy manipulation during
displaying earlier.
-------------------------------------------------------
Date: Mon 11/10/2003 at 02:07 By: gcasa
Tried this with all other types of containers and it works fine. I can only
reproduce this with NSScrollView. I have tried this with another application
and I cannot reproduce this. The only time it appears is when the application
is document based app.
CC list is empty
No files currently attached
For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=6354&group_id=99
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/