Tue 16 Dec 2008 07:23:02 PM UTC, comment #1:
To make the discussion about this issue easier, here a backtrace of the recursion:
#27 0x0804af1d in -[ThemeDocument activate] (self=0x81ab608,
_cmd=0x8061590) at ThemeDocument.m:212
#28 0x0804f95d in -[ThemeDocument setInfo:forKey:] (self=0x81ab608,
_cmd=0x8066cb8, value=0x9051f40, key=0x80666cc) at ThemeDocument.m:881
#29 0x08059689 in -[MiscElement textDidEndEditing:] (self=0x82c5cf8,
_cmd=0xb7f355c0, aNotification=0x9051ed8) at MiscElement.m:141
#30 0xb7923179 in -[NSNotificationCenter _postAndRelease:] (
self=0x8078878, _cmd=0xb7b37588, notification=0x9051ed8)
at NSNotificationCenter.m:1070
#31 0xb7923a8e in -[NSNotificationCenter postNotificationName:object:userInfo:] (self=0x8078878, _cmd=0xb7b37590, name=0xb7f261a4, object=0x8427990,
info=0x0) at NSNotificationCenter.m:1129
#32 0xb7923945 in -[NSNotificationCenter postNotificationName:object:] (
self=0x8078878, _cmd=0xb7f358a8, name=0xb7f261a4, object=0x8427990)
at NSNotificationCenter.m:1109
#33 0xb7e13764 in -[NSTextView resignFirstResponder] (self=0x8427990,
_cmd=0xb7f18840) at NSTextView.m:1490
#34 0xb7dca3c0 in -[NSWindow makeFirstResponder:] (self=0x844ec08,
_cmd=0xb7f11780, aResponder=0x844ec08) at NSWindow.m:3081
#35 0xb7dadf84 in -[NSView removeSubview:] (self=0x844ed00,
_cmd=0xb7f11758, aView=0x841e898) at NSView.m:879
#36 0xb7dadefc in -[NSView removeFromSuperview] (self=0x841e898,
_cmd=0xb7f18418) at NSView.m:853
#37 0xb7dc341b in -[NSWindow setContentView:] (self=0x844ec08,
_cmd=0x8062398, aView=0x841e898) at NSWindow.m:1126
#38 0x08051a28 in -[ThemeElement selectAt:] (self=0x82c5cf8,
_cmd=0x8066c30, mouse={x = 321, y = 432}) at ThemeElement.m:69
#39 0x0805900b in -[MiscElement selectAt:] (self=0x82c5cf8,
_cmd=0x8061360, mouse={x = 321, y = 432}) at MiscElement.m:71
#40 0x0804af59 in -[ThemeDocument activate] (self=0x81ab608,
_cmd=0x8061590) at ThemeDocument.m:214
#41 0x0804f95d in -[ThemeDocument setInfo:forKey:] (self=0x81ab608,
_cmd=0x8066cb8, value=0x9037380, key=0x80666cc) at ThemeDocument.m:881
#42 0x08059689 in -[MiscElement textDidEndEditing:] (self=0x82c5cf8,
_cmd=0xb7f355c0, aNotification=0x9037340) at MiscElement.m:141
#43 0xb7923179 in -[NSNotificationCenter _postAndRelease:] (
self=0x8078878, _cmd=0xb7b37588, notification=0x9037340)
at NSNotificationCenter.m:1070
#44 0xb7923a8e in -[NSNotificationCenter postNotificationName:object:userIn---Type <return> to continue, or q <return> to quit---
fo:] (self=0x8078878, _cmd=0xb7b37590, name=0xb7f261a4, object=0x8427990,
info=0x0) at NSNotificationCenter.m:1129
#45 0xb7923945 in -[NSNotificationCenter postNotificationName:object:] (
self=0x8078878, _cmd=0xb7f358a8, name=0xb7f261a4, object=0x8427990)
at NSNotificationCenter.m:1109
#46 0xb7e13764 in -[NSTextView resignFirstResponder] (self=0x8427990,
_cmd=0xb7f18840) at NSTextView.m:1490
This is just the main part, beside that a lot of other thing happen, as setting the main menu...
What is happening: The text view, where you type in the author looses focus, it calls resignFirstResponder which according to the comments there does what it has to do:
/* NB: According to the doc (and to the tradition), we post this
notification even if no real editing was actually done (only
selection of text) [Note: in this case, no editing was started,
so the notification does not come after a
NSTextDidBeginEditingNotification!]. The notification only means
that we are resigning first responder status. This makes sense
because many objects inside the gui need this notification anyway
- typically, it is needed to remove a field editor (editable or
not) when the user presses TAB to move to the next view. Anyway
yes, the notification name is misleading. */
It posts a NSTextDidEndEditingNotification notification. Which causes the misc element to set some info on the theme document. This gets the theme document to activate the theme, this sounds wired to me, but is application logic and beyond question here.
This results in the same misc element being selected and its super class implementation removes the contents view of the window but setting that very view as the contents view of some inspector.
As it happens our text view is a subclass of this contents view and now looses first responder state. As far as GNUstep is involved all of this sounds rather normal. The only thing that I could do in GNUstep is to prevent replacing a contents view by itself. I will try this and see if it helps.
But really do you think what your application is doing is the right thing? Do you still think so after looking that backtrace over?
|
Tue 16 Dec 2008 05:35:41 PM UTC, original submission:
I'm not even completely sure this is a bug, but it's a change in behavior which caused Thematic to hang (eventual crash when machine ran out of memory).
The way it happens is this ... when Thematic changes anything, it gets the theme to update by sending an -activate message to it.
Now, when changing the author and other descriptive information, what happens is that ending editing causes a notification which thematic catches and uses to update with the edited text, then calls -activate. However, the activation of the theme is somehow causing the textfied to send another end editing notification ... so re have recursion and a crash.
The only reason I've marked this as minor rather than critical was because it was possible to check in the Thematic code to see if the text in the textfield has actually changed, and refrain from activating the theme if it hasn't.
To reproduce this problem ... get Thematic from svn from 15th December 2008 and build it. Go in and start a new theme. Click on the gnustep icon to edit theme author etc. Type something in to the authors field then click on the details field to end editing the authors field ... your system will then grind to a halt as the recursing program uses all your cpu.
|