discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Topics about GNUstep/libobjc2


From: Dr. Rolf Jansen
Subject: Re: Topics about GNUstep/libobjc2
Date: Tue, 25 Oct 2016 20:41:34 -0200

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 <theraven@sucs.org>:

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 <theraven@sucs.org> 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 <rj@obsigna.com> 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 <theraven@sucs.org>:

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]