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

[anonymous-98]

URL:
  <http://savannah.gnu.org/bugs/?27233>

                 Summary: GSFFIInvocations share _retval ivar while in
-forwardInvocation:
                 Project: GNUstep
            Submitted by: thebeing
            Submitted on: Mi 12 Aug 2009 11:55:38 GMT
                Category: Base/Foundation
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

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



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Mi 12 Aug 2009 11:55:38 GMT  Name: test.m  Size: 2kB   By: thebeing
Test case
<http://savannah.gnu.org/bugs/download.php?file_id=18560>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27233>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[anonymous-98]

Follow-up Comment #1, bug #27233 (project gnustep):

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.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27233>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[anonymous-98]

Follow-up Comment #2, bug #27233 (project gnustep):

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)
    _______________________________________________________

Additional Item Attachment:

File name: test.m                         Size:2 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27233>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[anonymous-98]

Update of bug #27233 (project gnustep):

                  Status:                    None => Fixed                  
             Open/Closed:                    Open => In Test                

    _______________________________________________________

Follow-up 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.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27233>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[anonymous-98]

Follow-up Comment #4, bug #27233 (project gnustep):

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

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27233>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[anonymous-98]

Update of bug #27233 (project gnustep):

             Open/Closed:                 In Test => Closed                

    _______________________________________________________

Follow-up 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.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27233>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep