Problem implementing faults in Objective-C

Problem implementing faults in Objective-C

[Frederic Stark]

Hi all,

I am sending this to gnustep-dev crossposted to gcc. Maybe this isn't 
the right mailing list. See at the end of the post for a 40 line program 
that exhibit the bad behavior.

Problem:
If a is a fault (ie: changes its isa pointer during forwardInvocation), 
then:

[a method1:[a method2]]

fails (a does not recognize 'method1:'), while:

id o = [a method2];
[a method1:o];

works.

The code works correctly under Mac OS X.

Am I doing something horribly wrong ?
This is on gcc 3.2/mingw

Thanks for any help,

--fred

fred@FLEA /c/Dev/ObjcInvocations
$ shared_obj/invocation.exe
This one works:
method1
This one fails:
: Uncaught exception NSInvalidArgumentException, reason: B(instance) 
does not recognize method1:

fred@FLEA /c/Dev/ObjcInvocations


$ gcc -v
Reading specs from 
c:/GNUstepVersions/1.10.0/MinGW/bin/../lib/gcc-lib/mingw32/3.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as 
--host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads 
--disable-nls --enable-languages=f77,c++,objc,ada 
--disable-win32-registry --disable-shared
Thread model: win32
gcc version 3.2 (mingw special 20020817-1)

$ uname -a
MINGW32_NT-5.0 FLEA 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown

makefile:

---------------------

MAKEFILE_NAME = GNUstepMakefile

include $(GNUSTEP_MAKEFILES)/common.make

TOOL_NAME = invocation

invocation_OBJC_FILES = Invocation.m

invocation_C_FILES =

invocation_CC_FILES =

invocation_HEADER_FILES =

invocation_OBJ_FILES =

ADDITIONAL_OBJCFLAGS =

ADDITIONAL_INCLUDE_DIRS = -I../SystemConfiguration

ADDITIONAL_LIB_DIRS = -L../SystemConfiguration

invocation_TOOL_LIBS = -lgnustep-base \
         -lobjc

-include GNUstepMakefile.preamble
-include GNUstepMakefile.local

include $(GNUSTEP_MAKEFILES)/tool.make

-include GNUstepMakefile.postamble

---------------------

//	Test for invocation problem
#import <Foundation/Foundation.h>

@interface A : NSProxy
@end

@interface B : NSObject
- (void)method1:(id)o;
- (id)method2;
@end

@implementation A
- init { return self; }
- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSel { return [B 
instanceMethodSignatureForSelector:aSel]; }
- (void)forwardInvocation:(NSInvocation *)anInvocation
{
	isa = [B class];
	[anInvocation invoke];
}
@end

@implementation B
- (id)method2 { return self; }
- (void)method1:(id)a { printf( "method1\n" ); }
@end

int main()
{
	[[NSAutoreleasePool alloc] init];
	B *theB0 = (B *)[[A alloc] init];
	B *theB1 = (B *)[[A alloc] init];

	printf( "This one works:\n" );

	id o = [theB0 method2];
	[theB0 method1:o];

	printf( "This one fails:\n" );
	fflush( stdout );

	[theB1 method1:[theB1 method2]];

	return 0;
}

Re: Problem implementing faults in Objective-C

[Timothy J. Wood]

On Jun 21, 2005, at 4:12 AM, Frederic Stark wrote:

> I am sending this to gnustep-dev crossposted to gcc. Maybe this  
> isn't the right mailing list. See at the end of the post for a 40  
> line program that exhibit the bad behavior.
>
> Problem:
> If a is a fault (ie: changes its isa pointer during  
> forwardInvocation), then:
>
> [a method1:[a method2]]
>
> fails (a does not recognize 'method1:'), while:


   I believe the GNU runtime looks up the IMP and then calls it  
rather than always calling a dispatch function.  In this case, the  
code above is possibly getting miscompiled into something like

     IMP imp1 = getInstanceImp(a->isa, @selector(method1:))
     IMP imp2 = getInstanceImp(a->isa, @selector(method2))
     id result1 = imp2(a, @selector(method2))
     id result2 = imp1(a, @selector(method1:), result1)

   That is, the lookup of the IMP for -method1: may be happening too  
early.

> The code works correctly under Mac OS X.

   The Apple runtime doesn't have this design choice, so it can't  
really have this problem.

> Am I doing something horribly wrong ?

   I don't think so; seems like a bug in the GNU ObjC runtime support  
in the compiler.  I suppose the runtime maintainers might choose to  
define this as a bug in your code, but isa-swizzling is a fairly  
common and _extremely_ useful pattern in ObjC (see CoreData,  
NSZombie, etc.) so that'd not be my stance, obviously :)

-tim

Re: Problem implementing faults in Objective-C

[Frederic Stark]

Timothy J. Wood wrote:

[crunch]
>> The code works correctly under Mac OS X.

I just checked under linux/gcc 3.4 and the code works fine there. Maybe 
this is a gcc 3.2 specific problem. I'll check gcc 3.4 windows one of 
those days.

>   The Apple runtime doesn't have this design choice, so it can't  really 
> have this problem.

You are right. I just disassembled a small variation on the thing, and 
gcc 3.2 generates:

0x401406 <x>:   push   %ebp
0x401407 <x+1>: mov    %esp,%ebp
0x401409 <x+3>: push   %edi
0x40140a <x+4>: push   %esi
0x40140b <x+5>: push   %ebx
0x40140c <x+6>: sub    $0xc,%esp
0x40140f <x+9>: sub    $0x4,%esp
0x401412 <x+12>:        sub    $0x4,%esp
0x401415 <x+15>:        push   $0x4041f0
0x40141a <x+20>:        mov    0x8(%ebp),%esi
0x40141d <x+23>:        push   %esi
0x40141e <x+24>:        call   0x4017b0 <objc_msg_lookup>
0x401423 <x+29>:        add    $0xc,%esp
0x401426 <x+32>:        mov    %eax,%edi
0x401428 <x+34>:        sub    $0x4,%esp
0x40142b <x+37>:        push   $0x4041e8
0x401430 <x+42>:        mov    0x8(%ebp),%ebx
0x401433 <x+45>:        push   %ebx
0x401434 <x+46>:        call   0x4017b0 <objc_msg_lookup>
0x401439 <x+51>:        add    $0x8,%esp
0x40143c <x+54>:        push   $0x4041e8
0x401441 <x+59>:        push   %ebx
0x401442 <x+60>:        call   *%eax
0x401444 <x+62>:        add    $0xc,%esp
0x401447 <x+65>:        push   %eax
0x401448 <x+66>:        push   $0x4041f0
0x40144d <x+71>:        push   %esi
0x40144e <x+72>:        call   *%edi
0x401450 <x+74>:        add    $0x10,%esp
0x401453 <x+77>:        lea    0xfffffff4(%ebp),%esp
0x401456 <x+80>:        pop    %ebx
0x401457 <x+81>:        pop    %esi
0x401458 <x+82>:        pop    %edi
0x401459 <x+83>:        pop    %ebp
0x40145a <x+84>:        ret

It looks like the two objc_msg_lookup are made before the actual call 
(0x401442 and 0x40144e)

>   I don't think so; seems like a bug in the GNU ObjC runtime support  in 
> the compiler.  I suppose the runtime maintainers might choose to  define 
> this as a bug in your code, but isa-swizzling is a fairly  common and 
> _extremely_ useful pattern in ObjC (see CoreData,  NSZombie, etc.) so 
> that'd not be my stance, obviously :)

As in my code the real classes are all subclass of a specific one, I 
worked around the problem by implementing:

- (void)forwardInvocation:(NSInvocation *)anInvocation
{
	if (![self respondsToSelector:[anInvocation selector]])
		[super forwardInvocation:anInvocation];

	[anInvocation invoke];
}

in the 'B' class.

Thanks for the help (and it have been a loooong time since we last 
exchanged emails on the omni dev list...)

--fred

Re: Problem implementing faults in Objective-C

[Andrew Pinski]

On Jun 21, 2005, at 1:20 PM, Frederic Stark wrote:

> Timothy J. Wood wrote:
>
> [crunch]
>>> The code works correctly under Mac OS X.
>
> I just checked under linux/gcc 3.4 and the code works fine there.  
> Maybe this is a gcc 3.2 specific problem. I'll check gcc 3.4 windows  
> one of those days.

It is a 3.2 specific bug.
This was fixed in 3.4.0 at least for sure with:
2003-09-24  Ziemowit Laski  <zlaski@apple.com>

         MERGE OF objc-improvements-branch into MAINLINE.
         See 'gcc/ChangeLog' and 'gcc/testsuite/ChangeLog' for
         the gory details.

mainly:
Fix PR objc/11754
When cascading message together under GNU runtime, GCC was sending the  
inner message twice,
this patch fixes that.
Also adds a testcase for that case.

And the patch:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/objc-act.c.diff? 
r1=1.179.2.4&r2=1.179.2.2

Thanks,
Andrew Pinski