Re: Question about message forwarding (with fix)

[Larry Campbell]

On Apr 21, 2006, at 9:47 PM, Andrew Ruder wrote:

> On Fri, Apr 21, 2006 at 06:42:08PM -0700, Issac Trotts wrote:
> > Have you sent a bug report to the FFI maintainers?
>
> I'd like to find some time to investigate it first; its hard to tell  
> if
> the problem is with FFI or GNUstep's usage of FFI.
>
> - Andy
>
> --
> Andrew Ruder <andy@aeruder.net>
> http://www.aeruder.net


I ran into a similar problem, which does not occor on MacOS X, and did  
not occur when I was using ffcall (I have switched to libffi). I found  
that this patch to GSFFIInvocation.m (in gnustep-base 1.18.0) fixes  
the problem:

--- GSFFIInvocation.m~  2008-12-19 04:06:14.000000000 -0500
+++ GSFFIInvocation.m   2009-04-02 16:43:24.000000000 -0400
@@ -159,7 +159,7 @@
 	 get the right one, though. What to do then? Perhaps it can be  
fixed up
         in the callback, but only under limited circumstances.
        */
-      sel_type = sel_get_type (sel);
+      sel_type = sel_get_type (gs_find_best_typed_sel(sel));
       if (sel_type)
        {
          sig = [NSMethodSignature signatureWithObjCTypes: sel_type];

The problem is that selectors aren't necessarily unique, and that  
selectors can exist with no type information; if the FFI forwarding  
mechanism latches onto one with no type information, it messes up the  
argument passing, and boom. The fix is to find a selector with type  
information, if one exists. If more than one exists you might still  
lose, but at least you're not guaranteed to lose any more.

The path above fixed my crash as well as the sample program Isaac  
Trotts supplied at the beginning of this email thread.

I don't know why ffcall doesn't have the same problem; a quick glance  
at GSFFCallInvocation.m leads me to believe it should. Yet my code  
that crashes with ffi worked fine with ffcall.

- lc

smime.p7s
Description: S/MIME cryptographic signature