bug-gnustep
[Top][All Lists]
Advanced

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

DO is not using method types from remote objects


From: Stefan Urbanek
Subject: DO is not using method types from remote objects
Date: Sun, 15 Jun 2003 10:38:11 +0200

Hi,

This is a bit larger problem with DO and selectors. Problem is that somewhere 
in gnustep DO wrong selector types are used. DO mechanism does not use selector 
types from remote object but from local runtime.

I'll refer to StepTalk CVS version  from Jun 15 10:20 CET. Here is how to 
reproduce it:

In StepTalk script I want to send a message to a distant object. Say that we 
have an object Server (from StepTalk sources Examples/Server) which implements 
method:

- say:(NSString *)string

I have a small script:

    s := NSConnection rootProxyForConnectionWithRegisteredName:'Server' 
host:nil.
    s say:'test'.

Thing is, that on local side I do not know selector say:. What steptalk does? 
When building an invocation (see [1]) to the distant object, selector is get 
from NSSelectorFromString. Because there is no selector, nil is returned. 
Steptalk tries to register the selector by using:

        sel_register_name(name);

where 'name' is [selectorName cString]. This will register selector without 
type definition. Then I get a method signature from target which is a distant 
object.:

   signature = [target methodSignatureForSelector:sel];

Signature contains the right selector type information received from remote 
process.

When I launch the script I get:

2003-06-15 10:27:56.482 stexec[9781] Invalid selector say: (no type 
information)test

And here is the problem, because on the client side i have no type information 
in runtime. Should not the information from method signature be used instead of 
getting one from runtime?
I've tried another option (as with previous versions of StepTalk), where i have 
tried to register unknown selector types as returning id and having all 
arguments id (see [2]). However, I usualy got segfault if the return type was 
not id (like BOOL or something):

0x402387c9 in objc_msg_lookup () from /usr/local/lib/libobjc.so.1
(gdb) bt
#0  0x402387c9 in objc_msg_lookup () from /usr/local/lib/libobjc.so.1
#1  0x401247ef in _i_NSPortCoder__encodeObject_ ()
  from 
/usr/GNUstep/System/Library/Libraries/ix86/linux-gnu/gnu-gnu-gnu/libgnustep-base.so.1

in NSPortCoder line 1241 which was:
          obj = [anObject replacementObjectForPortCoder: self];
and anObject was 1 as a result of BOOL return value. Simular problems were on 
methods returning void, and somewrhere some object was RETAINing return value 
which was some random object.

References:
[1] Source/NSInvocation+additions.m: +invocationWithTarget:selectorName:
[2] Source/STObjCRuntime.m: STSelectorFromString()

Is this a -base bug or there is a problem on my side?

Thanks for any help,

Stefan
--
http://urbanek.host.sk

First they ignore you, then they laugh at you, then they fight you, then you 
win.
- Mahatma Gandhi






reply via email to

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