[bug #27233] GSFFIInvocations share _retval ivar while in -forwardInvocation:
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@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #27233] GSFFIInvocations share _retval ivar while in -forwardInvocation:
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@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #27233] GSFFIInvocations share _retval ivar while in -forwardInvocation:
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@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #27233] GSFFIInvocations share _retval ivar while in -forwardInvocation:
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@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #27233] GSFFIInvocations share _retval ivar while in -forwardInvocation:
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@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
