bugGNUstep - Bugs: bug #41586, Invocation forwarding doesn't work...

Group
 
 

bug #41586: Invocation forwarding doesn't work on my system

Submitter:  Sergei Golovin <svg>
Submitted:  Fri 14 Feb 2014 07:23:15 AM UTC
   
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Bug Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Declined
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 14 Feb 2014 05:24:25 PM UTC, comment #6: 

To implement forwarding you should generally implement -methodSignatureForSelector: to deal with any methods your proxy object doesn't implement itsself.

To make things friendlier (ie cope gracefully with code where -methodSignatureForSelector: fails) GNUstep has long (pretty much always) had an extension (not present in the NeXT/Apple codebase) allowing it to get type information directly from the selector, or failing that to get type information if one (and only one) selector with that name exists.

Mostly the compiler can ensure a correctly typed selector is used, but not always, so this feature to try to make faulty code work is not 100% reliable.
It will fail if there is no selector of the required name with type information (eg the receiver is actually in a different process or in a loadable bundle which hasn't been loaded yet).
It will also fail if two or more selectors with that name exist (since we have no way of knowing which one has the correct type info).

Possibly we should remove this in a later release and force people to write 'correct' (ie Apple compatible) code.  It appears that removing it might avoid confusion (though it might also break quite a bit of code … so I guess we'd have to start by deprecating and printing warning messages in one release before actually removing it)

Anyway, I hope it's clear how to add a -methodSignatureForSelector: implementation to make your code portable/reliable.

Richard Frith-Macdonald <CaS>
Group Member
Fri 14 Feb 2014 04:59:13 PM UTC, comment #5: 


Yes, this addition fixes the problem. Though it left me wondering why the problem doesn't pop up if I change the method name to 'someMethod'. It only manifests itself if I use a selector name already known from another class (of the gnustep base). See the attached modified test case.

P.S.
The testcase is simplification of some code which either forwards the invocation if a right object is present or takes some actions that lead to instantiating of such an object. That code hitherto has being working quite well.

(file #30551)

Sergei Golovin <svg>
Fri 14 Feb 2014 12:42:28 PM UTC, comment #4: 

Actually, prompted by where you got to in gdb,  I took a second look at your testcase and realised that the problem here is that the testcase is wrong rather than there being any bug in invocation forwarding.

Your gdb trace got past the code which should have done the type lookup, and as far as some code which tries to be friendly to buggy applications and guess what the types are intended to be … if the runtime knows about types, and only knows of one signature for a selector, it can infer the type signature with fairly reliably.

Anyway, to get back to your test case;
The test code is not actually attempting to forward anything, rather it's trying to log a message when -forwardInvocation: is called, and you forgot to implement the -methodSignatureForSelector: method in your forwarding class, so the system won't know what type information to use.  If you try out your testcase on OSX for instance, it will raise an exception there too.

To get your test to work, I think you need to implement something like this:

- (NSMethodSignature*) methodSignatureForSelector: (SEL)aSelector
{
  if (sel_isEqual(aSelector, @selector(name)))
    {
      return [Dummy instanceMethodSignatureForSelector: aSelector];
    }
  return [super methodSignatureForSelector: aSelector];
}

Please let me know if that fixes it for you.

Richard Frith-Macdonald <CaS>
Group Member
Fri 14 Feb 2014 11:14:19 AM UTC, comment #3: 


> So, possibly your problem is specific to gcc-4.6.3 and the objc
> library you are using, or perhaps something else … you might
> get an idea by looking at the config.log output from when you
> configured the base library, or perhaps some hint from running
> the testsuite?


I have attached the config.log. Here are excerpts with errors
from tests.log:
..........
Dashed hope:     basic.m:53 ... working callStackSymbols ... if this has failed it is probably due to a lack of support for objective-c method names (local symbols) in the backtrace_symbols() function of your libc. If so, you might lobby your operating system provider for a fix.
..........
Testing test03.m...
Building base/NSObject/test03.m
make debug=yes test03
This is gnustep-make 2.6.6. Type 'make print-gnustep-make-help' for help.
Making all for test_tool test03...
 Compiling file test03.m ...
test03.m: In function ‘main’:
test03.m:39:3: warning: implicit declaration of function ‘objc_setAssociatedObject’ [-Wimplicit-function-declaration]
test03.m:40:2: error: ‘OBJC_ASSOCIATION_RETAIN’ undeclared (first use in this function)
test03.m:40:2: note: each undeclared identifier is reported only once for each function it appears in
make[3]: * [obj/test03.obj/test03.m.o] Error 1
make[2]: * [internal-tool-all_] Error 2
make[1]: * [test03.all.test-tool.variables] Error 2
make: * [test03] Error 2
Failed build:
...........



> You could run your test under gdb, set a breakpoint in
> GSFFIInvocationCallback, and step through to try to find out
> why the type information can't be determined (it does look
> likely to be compiler, runtime, or ffi library related).


OK. I did so. That method begins with:

 obj      = (id )args[0];
 selector = (SEL )args[1];

after it is passed I issued the following gdb commands:

(gdb) p selector
$19 = (SEL) 0x602400
(gdb) p sel_getName(selector)
$20 = -144802851
(gdb) po NSStringFromSelector(selector)
name

(have no idea why there is the difference)

eventually the method calls the

SEL typed_sel = gs_find_best_typed_sel (selector);

which is the following code:

#elif defined (_GNU_LIBOBJC_)
  {
  /* The sel_getTypedSelector() function returns a typed
     selector if there is only one, nul if there are zero
     or more than one. */
  =>return sel_getTypedSelector(sel_getName(sel));
  }

this last call return 0 (no surprise if the sel_getName(sel)
returns an undefined value (see above)) and the exception is
triggered.


(file #30549, file #30550)

Sergei Golovin <svg>
Fri 14 Feb 2014 09:32:09 AM UTC, comment #2: 

Thanks for the report … but there's really too little information describing your specific system to help much.  Clearly you are running an older version of Ubuntu, and the exact combination of library/code causing trouble is unclear.

I just downloaded an Ubuntu virtual machine to try to reproduce the issue, but the /etc/motd lists the system as 'Ubuntu 13.04 (GNU/Linux 3.8.0-29-generic x86_64)' which is more recent than yours.

I used the standard packages for that system to do a completely clean configure/build:
apt-get install gobc build-essential libffi-dev libxml2-dev libxslt-dev libgnutls-dev libicu-dev

That gives me gcc-4.7.3 (and the libobjc that comes with it) and libffi 3.0.13

The standard NSInvocation tests (run using 'make check') all passed, as did the test you attached to this issue.

So, possibly your problem is specific to gcc-4.6.3 and the objc library you are using, or perhaps something else … you might get an idea by looking at the config.log output from when you configured the base library, or perhaps some hint from running the testsuite?
 
You could run your test under gdb, set a breakpoint in GSFFIInvocationCallback, and step through to try to find out why the type information can't be determined (it does look likely to be compiler, runtime, or ffi library related).

Richard Frith-Macdonald <CaS>
Group Member
Fri 14 Feb 2014 07:44:39 AM UTC, comment #1: 

Forgot to mention that on 32bit system it works with libobjc from
the gnustep's subversion repository.
I have just tried the distribution's libobjc (libobjc2 4.5.3-12ubuntu2) there and it doesn't work with too. So the summary isn't correct.

Sergei Golovin <svg>
Fri 14 Feb 2014 07:23:15 AM UTC, original submission:  

Hi!

I have the following problem while running the attached test case:

": Uncaught exception NSInvalidArgumentException, reason: Can not determine type information for -[TestObject name]"

on the 64bit Ubuntu 12.04 LTS with updates.

gcc 4.6.3 (libobjc3/gobjc 4.6.3-1ubuntu5)
libffi  3.0.11~rc1-5 (also tried the latest 3.0.13 with no avail)
base/make r37685/r37666 (current trunk)

The test case works well on 32bit Ubuntu 12.10.

Sergei Golovin <svg>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #30551:  FFI2.tar.gz added by svg (841B - application/x-tar-gz)
file #30550:  config.log added by svg (505KiB - text/x-log)
file #30549:  tests.sum added by svg (692KiB - application/octet-stream)
file #30548:  FFI.tar.gz added by svg (563B - application/x-tar-gz)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by svg (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-02-14 CaS StatusNone Invalid
        Open/ClosedAnalyzed Declined
    2014-02-14 svg Attached File- Added FFI2.tar.gz, #30551
    2014-02-14 CaS StatusNeed Info None
        Open/ClosedOpen Analyzed
    2014-02-14 svg Attached File- Added tests.sum, #30549
        Attached File- Added config.log, #30550
    2014-02-14 CaS StatusNone Need Info
        SummaryInvocation forwarding doesn\'t work on a 64bit system Invocation forwarding doesn't work on my system
    2014-02-14 svg Attached File- Added FFI.tar.gz, #30548

    Back to the top

    Powered by Savane 3.13-bb6a.
    Corresponding source code