gnustep-dev
[Top][All Lists]
Advanced

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

Re: NSClassSwapper leaving dangling pointers?


From: Fred Kiefer
Subject: Re: NSClassSwapper leaving dangling pointers?
Date: Wed, 26 Jun 2013 10:55:36 +0200

I am currently on holidays with only my iPad and limited connectivity. That's why I may be wrong on a few things. Still I think that the class swapper does stuff it should not be doing. It seems to replace all cell objects not just the cells belonging to the controler it is currently decoding. And it even replaces these cells when they are already of the correct subclass. Both things, if valid, need to be changed.

What I don't understand is why a menu item would use its cell as the target. Or is the main cell of a popup button being used as the target of its menu items? Only the inspection of the NIB file could explain this. The later could explain our problem as we replace an object that has external references to it.

Fred

On the road

Am 26.06.2013 um 07:45 schrieb Gregory Casamento <address@hidden>:

Upon further examination, I'm not sure that Fred's concern is valid.  The reason the cell contents are not copied is because they don't have to be:

          result = [[newCellClass alloc] initWithCoder: coder];   

The above line in the method -(id)unarchiver:didDecodeObject: unarchives the proper attributes into the new instance and replaces the old instance of the cell.



On Wed, Jun 26, 2013 at 1:35 AM, Gregory Casamento <address@hidden> wrote:
Lubos,

I'm not sure why you're saying it should only be used for looking up the name.   What leads you to the conclusion that this is all it's used for.  When I wrote it I did many backtraces to determine how it worked.

If you have known object A and custom class B. "Known" classes are classes which IB knows about (e.g. Cocoa classes) and can archive.  A is what is actually archived in the .nib file because that is what Interface Builder can instantiate and save, but in the data structures which are saved in the nib, there is a map which indicates that object A should be replace by an instance of custom class B.  The way this is indicated by the user is when you select the custom class in the class inspector in IB.

NSClassSwapper is certainly doing what it is supposed to be doing in this case.   The only fault, I believe is what Fred pointed out in an earlier email.   The cell contents and settings are not being copied and, perhaps, they should be.

Anyway, just adding my 0.02 to the conversation.

GC


On Tue, Jun 25, 2013 at 7:48 PM, Gregory Casamento <address@hidden> wrote:
Wow, I really need to look into this immediately.  NSClassSwapper does what its name suggests.  It determines the custom class for a given object and instantiates it.  

It shouldn't create an object then destroy it immediately.   


On Tue, Jun 25, 2013 at 2:57 PM, Luboš Doležel <address@hidden> wrote:
Hi,

I've contacted the author and it seems it doesn't serve any purpose at
all, as is.

"Sounds like one of the character encoding popups. The actual contents
of the menu are built dynamically at runtime."

Which sounds logical, given that the item's description is "dummy" (and
the replacement class is "TUEncodingPopUp".

Either way, GNUstep should somehow support it. What I don't understand
why isn't NSClassSwapper used only to determine the real class name. Why
first create a different object only to destroy it moments later?

I also couldn't find out why -initWithCoder: on the new object doesn't
replace the child objects as well - which I'd guess would mitigate the
problem too.

Luboš


On 06/24/2013 09:07 PM, Fred Kiefer wrote:
> This backtraces finally helped me understand what goes on here a bit
> better, at least I hope so.
>
> NSClassSwapper not only replaces a specific object, it also registers
> itself as the delegate of the decoder to be able to replace the cells
> used by that object. This happens here and the decoded cell gets
> replaced by a newly created cell without transfering any of the
> already set values.
>
> What I still don't understand is why the menu item uses its menu cell
> as the target. This ould be another difference to the GNUstep
> implementation. Could you please try to find out what the used action
> is?
>
> At the moment I still don't have an idea how we could work around
> this issue. We should try to find out more about it.
>
> Fred
>
> On the road
>
> Am 24.06.2013 um 11:49 schrieb Luboš Doležel <address@hidden>:
>
>> Sorry for the spam, I have another backtraces providing a clear
>> picture, alhough they seem to be slightly different from the ones
>> before.
>>
>> You can see an object being set as a target, then deallocated and
>> then used (with SIGSEGV).
>>
>> Luboš
>>
>>
>> On Mon, 24 Jun 2013 10:21:18 +0200, Luboš Doležel wrote:
>>> What I forgot to add:
>>>
>>> Until gnustep-gui supports resource directory names like
>>> "en.lproj", you have to symlink English.lproj->en.lproj to make
>>> it work (GNUstep bug #36764). This bug also prevents apps from
>>> working when mounted directly from a .dmg file via my FUSE
>>> module, since the mounts are read-only.
>>>
>>> Lubos
>>>
>>> On Mon, 24 Jun 2013 09:52:51 +0200, Luboš Doležel wrote:
>>>> Hi,
>>>>
>>>> great! Feel free to contact me via Jabber (same as mail
>>>> address), should you run into any issues.
>>>>
>>>> Attached is the backtrace leading up to NSClassSwapper, as
>>>> Germán requested.
>>>>
>>>> Lubos
>>>
>> <darling-unarchiver2.txt>
>> _______________________________________________ Gnustep-dev mailing
>> list address@hidden
>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>


--
Luboš Doležel

_______________________________________________
Gnustep-dev mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/gnustep-dev



--
Gregory Casamento
Open Logic Corporation, Principal Consultant
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)
http://www.gnustep.org
http://heronsperch.blogspot.com


--
Gregory Casamento
Open Logic Corporation, Principal Consultant
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)
http://www.gnustep.org
http://heronsperch.blogspot.com



--
Gregory Casamento
Open Logic Corporation, Principal Consultant
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)
http://www.gnustep.org
http://heronsperch.blogspot.com



--
Gregory Casamento
Open Logic Corporation, Principal Consultant
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)
http://www.gnustep.org
http://heronsperch.blogspot.com
_______________________________________________
Gnustep-dev mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/gnustep-dev

reply via email to

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