bugGNUstep - Bugs: bug #27233, GSFFIInvocations share _retval...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #27233: GSFFIInvocations share _retval ivar while in -forwardInvocation:

Submitted by:  Niels Grewe <thebeing>
Submitted on:  Wed 12 Aug 2009 11:55:38 AM UTC  
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed

Sun 11 Oct 2009 03:30:18 PM UTC, comment #5: 

Thanks for testing.

I wouldn't call recording invocations unsound design, even if there happens to be a better way of doing what you want in your particular application. It ought to have worked for you and you had every right to expect it to work.  Thanks to your testing, it will work for the next person who wants to do it.

Richard Frith-Macdonald <CaS>
Project Member
Sun 11 Oct 2009 02:59:24 PM UTC, comment #4: 

Although my code does not use that invocation-recording approach anymore (it was unsound design to begin with), I checked this out once more and can confirm that it's working for me now.
Many thanks for tracking this one done!

Cheers,

Niels

Niels Grewe <thebeing>
Project Member
Sat 03 Oct 2009 06:40:15 PM UTC, comment #3: 

Sorry for taking so long to get round to this.  I took a look at the issue and agree with the original analysis (more or less).  The code was trying to be too clever and store the result (of an invocation created to forward a message) directly to the callers memory ... which is obviously a problem if the receiver saves the invocation to use itsself later.

I believe I have fixed this in svn trunk.  it passes the simple testcase for
me, and our regression tests for nsinvocation continue to work, but it would be good if you could check this too and confirm that it's fixed.

Thanks very much for this bug report ... the bug is obscure and I imagine could have resulted in some problems which would be very hard to track down.

Richard Frith-Macdonald <CaS>
Project Member
Mon 17 Aug 2009 07:43:43 PM UTC, comment #2: 

Setting the return value seems to have nothing to do with the problem, but I have amended the test case to reflect your concerns, although I don't know how to expose the problem without using an invocation with a non-object return (CLEAR_RETURN_VALUE_IF_OBJECT will properly reset _retval to nil so you're not getting into trouble in that case). I also had the chance to test the code on Cocoa and can confirm that it works there.

Cheers,

Niels

(file #18592)

Niels Grewe <thebeing>
Project Member
Sun 16 Aug 2009 07:49:56 PM UTC, comment #1: 

I am not sure that I understand this problem correctly, but looking at your code I notice that you are setting self as the result of the invocation even in the case where a boolean result is expected.

From my point of view this rather looks like a bug in your code than one in NSInvocation. Does your code work on Cocoa?

I would suggest that you try your code with methods that all return an object and report, whether this works or not.

Fred Kiefer <FredKiefer>
Project Member
Wed 12 Aug 2009 11:55:38 AM UTC, original submission:  

Hello,

I encountered an odd problem with invocations (GNUstep SVN r28455, 64bit Debian Linux with libffi 3.0.7). I'm working on a class that records invocations for later use. The seems to be no problem as long as those invocations are invoked from outside -forwardInvocation:.

But whenever I invoke those invocations from -forwardInvocation: their respective _retval ivars point to the same chunk of memory. This causes a problem as soon as you have two invocations with different return types. (eg. BOOL and id) If you invoke the id invocation first, it will set _validReturn to yes and places a reference to the returned object in _retval.
Invoking the BOOL invocation afterwards will then modify the _retval field to hold its own return value.
If you invoke the id invocation again afterwards, it will try to release _retval with CLEAR_RETURN_VALUE_IF_OBJECT because _validReturn is YES and info[0].type is _C_ID. This causes a message lookup to a class at some invalid address (0x1 or 0x0 in this case) and results in a segfault. I have appended a test case to demonstrate the problem.

kind regards,

Niels

Niels Grewe <thebeing>
Project Member

 

Attached Files
file #18592:  test.m added by thebeing (2KiB - application/octet-stream - Modified test case)
file #18560:  test.m added by thebeing (2KiB - text/x-objcsrc - Test case)

 

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 FredKiefer (Posted a comment)
  • -email is unavailable- added by thebeing (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-10-11 CaS Open/ClosedIn Test => Closed
    2009-10-03 CaS Open/ClosedOpen => In Test
        StatusNone => Fixed
    2009-08-17 thebeing Attached File- => Added test.m, #18592
    2009-08-12 thebeing Attached File- => Added test.m, #18560

    Back to the top


    Powered by Savane 3.5