gnustep-dev
[Top][All Lists]
Advanced

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

Re: OpenBSD: Services problems


From: Fred Kiefer
Subject: Re: OpenBSD: Services problems
Date: Wed, 07 Sep 2011 10:50:38 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.20) Gecko/20110804 SUSE/3.1.12 Thunderbird/3.1.12

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.



reply via email to

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