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
>
>
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
