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