[bugs #4068] DO uses typed selector from local instead of distant object.

[Richard Frith-Macdonald]

This mail is an automated notification from the bugs tracker
 of the project: GNUstep.

/**************************************************************************/
[bugs #4068] Latest Modifications:

Changes by: 
                Richard Frith-Macdonald <rfm@gnu.org>
'Date: 
                Tue 08/24/04 at 08:27 (GMT)

            What     | Removed                   | Added
---------------------------------------------------------------------------
         Assigned to | CaS                       | None







/**************************************************************************/
[bugs #4068] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=4068>
Project: GNUstep
Submitted by: Stefan Urbanek
On: Sun 06/22/03 at 08:22

Category:  Base/Foundation
Severity:  1 - None
Item Group:  Change Request
Resolution:  Fixed
Privacy:  Public
Assigned to:  None
Status:  In Test


Summary:  DO uses typed selector from local instead of distant object.

Original Submission:  Distributed Objects in -base uses information about typed 
selectors (for building method signatures and invocations) from local runtime 
instead of distant object. This is ugly behaviour and causes, for example, 
segfaults due to type mismatches or selector nonexistence.



Follow-up Comments
------------------


-------------------------------------------------------
Date: Fri 07/04/03 at 09:40         By: Richard Frith-Macdonald <CaS>
The GNUstep extension to use information from the remote system should now be 
working for ffcall and ffi as well as the old mframe forwarding mechanism, at 
least inasmuch
as it ever makes sense ... if the types that the compiler was expecting in the 
client do not match the types in the server then it is of course impossible for 
the two to cooperate.


-------------------------------------------------------
Date: Fri 07/04/03 at 08:46         By: Richard Frith-Macdonald <CaS>
After more investigation, it seems it may be possible to work around this 
problem, so the modification I suggested earlier to the runtime hook 
__objc_msg_forward is probably not actually needed :-)

-------------------------------------------------------
Date: Fri 07/04/03 at 05:58         By: Richard Frith-Macdonald <CaS>
This is nothing to do with the DO system ... it's a feature of the message 
forwarding mechanism used (this comes before any DO code can be called). The 
ffcall and ffi based forwarding get type information from the local runtime.  
Turning these off and using the old mframe code should do as a workaround.

I'm looking into trying to get ffcall and ffi to work, but this may require 
adding a new feature to the objc runtime.

-------------------------------------------------------
Date: Sun 06/22/03 at 09:49         By: Stefan Urbanek <stefanu>
Problem is, that DO does not seem to fetch types from remote end, or fetches 
them and uses only on one place and there are still places in -base where local 
selector info is used. 

I'm reffering to my previous email to the list:

http://mail.gnu.org/archive/html/gnustep-dev/2003-06/msg00018.html

Whole problem is described in that post.

If you would like to reproduce it, you have to get older version of StepTalk, 
because I have created a workaround for this bug.


-------------------------------------------------------
Date: Sun 06/22/03 at 09:17         By: Richard Frith-Macdonald <CaS>
I'm not sure about this ... DO has to handle arguments both locally and 
remotely, so the argument types on both ends of the connection must match
Where there is no type information at the local end, DO fetches it from the 
remote end, so the simple assertion that DO uses the local runtime rather than 
the remote end is not the case.  I think we need more specific 
examples/testcases of exactly what the problem is.

I seem to recall an email conversation about an objc-runtime problem with 
selector types for forwarding.  Is this the same problem in a different guise?













For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=4068>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/