awakeFromNib not called on File's Owner

[Doug Simons]

As far as I can tell, the NSSecureTextView in our nib is now loading properly -- thanks for that fix!

Unfortunately, this only gets us to the next problem: awakeFromNib is not being called on the nib file's owner.

In digging through this issue in gdb I noticed that this nib is another one that contains objects which load other nib files in their init methods. I don't think this is the cause, because I think we have other nibs that do the same that are loading okay, but I thought I'd mention it.

I didn't see where the code is supposed to call awakeFromNib on the owner -- is the file's owner supposed to be one of the regular objects in the nib's list of objects? It's not in that list.

Also, I noticed that one of the objects that is in the list is a custom object that resolves to NSApp, causing awakeFromNib to be called on NSApp for EVERY NIB that is loaded. This seems wrong to me (although it isn't causing us any trouble). In fact, I just set a breakpoint on our application's awakeFromNib on Mac OS X and verified that it is only called once by Cocoa, when the MainMenu nib is loaded.

Doug

On Mar 24, 2010, at 2:00 AM, Fred Kiefer wrote:

No this wasn't caused by the NIB loading fixes, this time it was the
NSTextView change I made :-)
While investigating the NIB problem I noticed that Ink kept on to each
text network it created. I thought that there was no point in fixing NIB
loading when most the same objects get retain just a little bit later
anyway and so I fixed that as well. The basic issue was that the text
storage was retained inside of NSTextView buildUpTextNetwork:, but not
set into the ivar. Correcting this removed the memory leak here. But it
also uncovered places where we weren't careful enough about our text
network. The method replaceTextContainer: was one such place, here the
text storage now needs an extra retain to have it around for the whole
method execution. The same is true in the NSTextContainer method
replaceLayoutManager: and Riccardo pointed me to that in a private mail
yesterday. At the time you reported this bug it was already fixed in
SVN, if we could only be that fast all the time.

The whole text system network is really too complicated. Removing an
object at one level could trigger a release at a completely different
level. It would just be great if somebody with enough time at hand could
have a deep look at all this and see how it could be restructured.

Part of the problem here is the way we program in GNUstep. I try to use
as much explicit memory handling as possible. That is, to avoid auto
released objects. The benefit of this is that objects get freed as soon
as they are no longer needed. But sometimes this might be a little bit
to early, as the recent problems show. With auto release objects these
would stay around until their auto release pool get drained and many
issues could be hidden that way. Still I am reluctant to change my
coding style. I think a library should be as strict as possible with
memory usage. What ever wast can be avoided should be avoided.

Fred

Am 23.03.2010 23:15, schrieb Doug Simons:

Okay, here's another problem that's apparently been exposed by the recent changes to retains when loading a nib. It appears there is a problem in the way objects retain/release each other in the text system.

We have an NSSecureTextField in a panel loaded from a nib file. When the panel is displayed, it tries to setup the secure text field which replaces the layout manager with a secure layout manager. But when replaceLayoutManager: calls [textStorage removeLayoutManager: _layoutManager] this results in the textStorage object itself being freed, and it crashes on the next line. I tried to figure out what was going on, but there are a lot of subtle interconnections in the text system, so I'm not sure exactly what isn't being retained that needs to be (or is being released that shouldn't be!).

Here's what the crash looks like:

Program received signal SIGSEGV, Segmentation fault.

0x67848ae6 in objc_msg_lookup () from c:\GNUstep\GNUstep\System\Tools\objc-1.dll

(gdb) bt

#0  0x67848ae6 in objc_msg_lookup () from c:\GNUstep\GNUstep\System\Tools\objc-1.dll

#1  0x63c24e04 in -[NSTextContainer replaceLayoutManager:] (self=0x9de34b0, _cmd=0x63d65b38,

   aLayoutManager=0x144b890) at NSTextContainer.m:171

#2  0x63bee87e in -[NSSecureTextView initWithFrame:textContainer:] (self=0x1401ea0,

   _cmd=0x63db4870, frameRect={origin = {x = 0, y = 0}, size = {width = 0, height = 0}},

   aTextContainer=0x9de34b0) at NSSecureTextField.m:305

#3  0x63c9e5f1 in -[NSTextView initWithFrame:] (self=0x1401ea0, _cmd=0x63d8b058, frameRect=

       {origin = {x = 0, y = 0}, size = {width = 0, height = 0}}) at NSTextView.m:744

#4  0x63c3aa9c in -[NSView init] (self=0x1401ea0, _cmd=0x63d65aa8) at NSView.m:566

#5  0x63bee378 in -[NSSecureTextFieldCell setUpFieldEditorAttributes:] (self=0x15a35a0,

   _cmd=0x63d7df98, textObject=0x1290ee0) at NSSecureTextField.m:209

#6  0x63c2649e in -[NSTextField selectText:] (self=0x994d9d0, _cmd=0x63d7e070, sender=0x994d9d0)

   at NSTextField.m:181

#7  0x63c26e17 in -[NSTextField becomeFirstResponder] (self=0x994d9d0, _cmd=0x63d91b70)

   at NSTextField.m:431

#8  0x63c53285 in -[NSWindow makeFirstResponder:] (self=0x16594c0, _cmd=0x585240,

   aResponder=0x994d9d0) at NSWindow.m:3176