bugGNUstep - Bugs: bug #27128, rootProxy cannot be called twice...

Group
 
 

bug #27128: rootProxy cannot be called twice on an NSConnection

Submitter:  Michael Johnston <mjohnston>
Submitted:  Tue 28 Jul 2009 03:27:16 PM UTC
   
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 03 Oct 2009 03:38:58 PM UTC, comment #3: 


> So should the rootProxy docs say ... "The returned proxy is not retained by the
> receiver. If it is deallocated the connection that supplied it is invalidated"?


No, I think, while the proxy may be autoreleased and deallocated, as long as the connection itsself is retained, it should be possible to call -rootproxy on it again and get a new proxy object.

I've modified the NSConnection code so that if the proxy on one end of the connection is deallocated, the object at the other end does not get deallocated if it happens to be the root object.  This should solve the problem.

Richard Frith-Macdonald <CaS>
Group Member
Wed 05 Aug 2009 09:56:41 AM UTC, comment #2: 

Unfortunately I don't have any easy to run test case at the moment, but I think my problem may be explained by your second point.

I don't explicitly release the proxy when I first call rootProxy. I assume the method returns an autoreleased object that is (or is a copy of) some object internally retained by the NSConnection instance.

However between the two times I call rootProxy the autorelease pool is emptied. So if the rootProxy is autoreleased when it is first returned (and not retained by the NSConnection that returned it) it is destroyed in my case - and hence the connection would be invalidated as you say.

Perhaps if you empty the autorelease pool between your calls you may see the problem?

So should the rootProxy docs say ... "The returned proxy is not retained by the receiver. If it is deallocated the connection that supplied it is invalidated"?

Michael Johnston <mjohnston>
Tue 04 Aug 2009 06:36:53 AM UTC, comment #1: 

Tricky ... there is no test case attached, so I can't tell how to reproduce this.
Please could you provide some test code demonstrating the issue,

It seems to me from testing with my own code, that there's no problem calling root proxy multiple times.

However, but if you call it once, then release it, then call it again ... the second call fails because the connection has been invalidated when the original proxy was destroyed.

Richard Frith-Macdonald <CaS>
Group Member
Tue 28 Jul 2009 03:27:16 PM UTC, original submission:  

Library Version - gnustep-base-0.19
OS - Fedora Core 10
gcc - 4.1.2

The expected behaviour is that you can call rootProxy multiple time on an NSConnection object.
This is the behaviour on Mac.

Actual Behaviour.

Initial calls to rootProxy, and subsequent calls in the same method succeed.

Once the method that first called rootProxy is exited subsequently sending rootProxy to the NSConnection instance (e.g. if its stored in an array and retrieved later) cause NSConnectionDidDieNotifications to be posted and exceptions to be raised.

The exceptions are different for message ports and socket ports.

Message ports raise NSPortTimeoutExceptions with reason 'root proxy request - port was invalidated'

Socket ports raise NSObjectInaccessibleException with reason 'Waiting for reply in wrong thread'

The bug is also present in gnustep-base-1.16

Reason

It seems that NSConnection tries to reuse the NSDistantObject created on the first call to rootProxy but does not retain it. Thus after exiting the method where the root proxy is first obtained it may be released.

Workaround

Retaining the rootProxy when its first returned avoids the bug. However doing this is difficult unless a central class manages all connections.



Michael Johnston <mjohnston>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by mjohnston (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-10-03 CaS StatusNeed Info Fixed
        Open/ClosedOpen Closed
    2009-08-04 CaS StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code