Hello David,
As a matter of fact, accessing the ResultType ivar itsValue of CalcFactor does
not crash anymore with the latest libobjc2 from GitHub, however, with that
another problem has been introduced. When calling -[CalcObject init:::], the
parameters become assigned to different ivars then requested.
In order to trigger this problem, I modified the file main.m of my test case to:
------------------ main.m ----------------
#import <stdio.h>
#import <stdlib.h>
#import <stdint.h>
#import <math.h>
#import <complex.h>
#import <tmmintrin.h>
#import <objc/Object.h>
#import "BareClass.h"
#import "CalcObject.h"
int main(int argc, const char *argv[])
{
TokenRecord t = (TokenRecord){0, 2, numDigit, "11", nil, NULL};
CalcFactor *a = [[CalcFactor alloc] init:&t :factor :param];
return 0;
}
------------------- END ------------------
In the Makefile I replaced -g0 -Ofast with -g -O0. After building on FreeBSD, I
ran a debugging session using lldb.
As you can see in the attached screenshot, the expression "itsToken = token"
actually left itsToken at nil but changed the other instance variable
itsCalculator from nil to a bogus pointer.
This problem cannot be resolved by changing the optimization switches nor by
using #pragma pack directives.
For the time being I need to switch back to the previous version of libobjc2.
Best regards
Rolf
> Am 25.10.2016 um 13:52 schrieb David Chisnall <[email protected]>:
>
> This should now be fixed:
>
> https://github.com/gnustep/libobjc2/commit/6df23377a02f187e0df8cb359175fb274b34aae1
>
> It turns out that I’d previously got some code that was slightly wrong for
> this and then disabled it…
>
> It needs a lot more testing, but I really should push out the 1.9 release
> soon as there are a load of improvements since the last one.
>
> David
>
>> On 25 Oct 2016, at 15:28, David Chisnall <[email protected]> wrote:
>>
>> Hi,
>>
>> It would help if the reduced test case compiled, but adding -march=native
>> seems to fix that. It would also help if it were something a bit more
>> minimal, but from what you’ve sent me:
>>
>> The crash happens in [CalcFactor evaluate], which simply returns the
>> ResultType ivar itsValue. Clang is emitting sse instructions for this,
>> assuming that the ivar is correctly 128-bit aligned. The offset is 48, so
>> it is aligned within the object, but the 64-bit header makes it unaligned
>> again.
>>
>> Here is a reduced test case that demonstrates the problem:
>>
>> #include <objc/runtime.h>
>> #include <stdint.h>
>> #include <assert.h>
>> typedef int v4si __attribute__ ((vector_size (16)));
>> @interface Foo
>> {
>> Class isa;
>> v4si var;
>> }
>> - (void)check;
>> + (id)new;
>> @end
>> @implementation Foo
>> + (id)new
>> {
>> return class_createInstance(self, 0);
>> }
>> - (void)check
>> {
>> size_t addr = (size_t)&var;
>> assert(addr & 15 == 0);
>> }
>> @end
>>
>> int main(void)
>> {
>> [[Foo new] check];
>> }
>>
>> It appears that we’re not taking the offset into account correctly. I
>> thought I’d fixed this, but apparently I haven’t. I’ll take a look now.
>>
>> David
>>
>>> On 25 Oct 2016, at 14:47, Dr. Rolf Jansen <[email protected]> wrote:
>>>
>>> Hi David,
>>>
>>> Attached to this message you will find a .zip-Archive with the stripped
>>> down test case. It contains a FreeBSD Makefile and a .xcodeproj-package.
>>>
>>> It should build on FreeBSD against libobjc2 (ports) and Mac OS X (native
>>> libobjs) out of the box. On Mac OS X it should run fine and it would crash
>>> on FreeBSD.
>>>
>>> If you uncomment the #pragma pack() directives in CalcObject.h it builds
>>> and runs fine also on FreeBSD 11-RELEASE-p1.
>>>
>>> Best regards
>>>
>>> Rolf
>>>
>>>> Am 25.10.2016 um 06:55 schrieb David Chisnall <[email protected]>:
>>>>
>>>> Hi Rolf,
>>>>
>>>> From your code snippets, it looks as if it should work and you’ve probably
>>>> found either a compiler or runtime bug. If you can put together a reduced
>>>> test case (ideally something that doesn’t depend on anything other than
>>>> libobjc) I’ll take a look.
>>>>
>>>> David
_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
