Re: OpenBSD: Services problems

[Richard Frith-Macdonald]

On 7 Sep 2011, at 09:50, Fred Kiefer wrote:

> On 07.09.2011 01:32, Riccardo Mottola wrote:
>> Hi,
>> 
>> as I wrote some days ago, when testing OpenBSD/sparc with gcc 2.95 I had
>> mainly problems with services, Sebastian had similar poblems he didn't
>> report again though.
>> 
>> I can reproduce these on OpenBSD/x86 gcc 4.2.1 end even other platforms.
>> 
>> For example, I have gworkspace and Terminal running. I select a folder
>> and run "Open Terminal here" it used to work not too long ago.
>> 
>> On OpenBSD and FreeBSD I get:
>> 
>> Failed to contact service provider for 'Terminal/Open shell here': -[nil
>> terminalService:userData:error:]: unrecognized selector sent to instance
>> (null)
>> 
>> If I select an URL text and use "Open URL in Vespucci" I get:
>> 
>> Failed to contact service provider for 'Open URL in Vespucci': -[nil
>> openURL:userData:error:]: unrecognized selector sent to instance (null)
>> 
>> That used to work too... I will test other platforms, but surely there
>> seems to be some kind of problem.
> 
> The message "unrecognized selector sent to instance" is only defined in 
> base/Source/GSFFIInvocation.m. There we have this long comment:
> 
>  /* Take care here ... the receiver may be nil (old runtimes) or may be
>   * a proxy which implements a method by forwarding it (so calling the
>   * method might cause recursion).  However, any sane proxy ought to at
>   * least implement -methodSignatureForSelector: in such a way that it
>   * won't cause infinite recursion, so we check for that method being
>   * implemented and call it.
>   * NB. object_getClass() and class_respondsToSelector() should both
>   * return NULL when given NULL arguments, so they are safe to use.
>   */
> 
> But the actual code seems to be unsuited for the service provider case. There 
> the selector doesn't have to be defined in the calling application, but as it 
> has a well defined type and the GSServiceManager sets up the NSInvocation 
> with all the needed information this should work. As it doesn't in your case, 
> this looks like a base bug to me that should be analysed before the upcoming 
> base release.
> I tried to look into the GSFFIInvocation code myself, but failed to 
> understand how we end up in the gs_objc_msg_forward2 function. When we get 
> there, with the old runtime that passes a receiver of nil, we are lost.
> 
> David, Richard, could one of you please take over? Do we have a test case 
> that uses an NSInvocation where the selector is not defined in the test 
> itself? If not, we may need to add one.

I've hacked in some code to attempt to get type information *before* performing 
the invocation, and replace the untyped selector with a typed one so that, if 
the runtime does a callback without providing the object we want to message, we 
can use the type information from the selector anyway.

This will probably make things work, but the problem is, this means we always 
trust the method signature in the invocation (which might not actually contain 
the same type info that the remote system would give us).

So in fact (assuming I'm understanding this correctly) this change is really 
introducing a minor bug in order to work around a runtime failure ... and we 
should really be figuring out what the runtime is doing wrong and how to fix 
it, rather than hacking a workaround into base.

What's special about OpneBSD and FreeBSD?  Are they using a particularly old 
version of the GNU runtime?
Maybe the correct solution is to revert the code change I just made, and have 
those systems use a more recent GNU runtime, or the GNUstep traditional 
runtime, or the new GNUstep objc2 runtime.