Re: GSLaunchedApplications.lock
Steven R. Baker wrote: > I keep seeing this error: > > NSGenericException: lock > '/tmp/GNUstepSecure1000/GSLaunchedApplications.lock' already broken I got this error this week a few times as well but did not get it during the three years before while using wmaker/gnustep daily. It might be a recent change in Debian testing. I will need to check which packages I updated, if any, which might be related. I will try to do so this week. Svetlana ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Topics about GNUstep/libobjc2
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
#import
#import
#import
#import
#import
#import
#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 :
>
> 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 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
>> #include
>> #include
>> 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 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 :
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
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: GSLaunchedApplications.lock
Steven, On Tuesday, October 25, 2016, Steven R. Baker wrote: > Heya, > > I keep seeing this error: > > NSGenericException: lock > '/tmp/GNUstepSecure1000/GSLaunchedApplications.lock' already broken > > I get it when trying to start PRICE.app and AddressManager.app, pretty > consistently right now. But I've seen it from other apps as well. > > I'm running Debian testing, and whatever the latest packages are from > there. > > Help is appreciated! This is a race condition on a distributed lock. The only solution, unfortunately, is going to be to keep trying to launch it. -Steven > Thanks, GC -- Gregory Casamento GNUstep Lead Developer / OLC, Principal Consultant http://www.gnustep.org - http://heronsperch.blogspot.com http://ind.ie/phoenix/ ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
GSLaunchedApplications.lock
Heya, I keep seeing this error: NSGenericException: lock '/tmp/GNUstepSecure1000/GSLaunchedApplications.lock' already broken I get it when trying to start PRICE.app and AddressManager.app, pretty consistently right now. But I've seen it from other apps as well. I'm running Debian testing, and whatever the latest packages are from there. Help is appreciated! -Steven ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Topics about GNUstep/libobjc2
Hi David! > Am 25.10.2016 um 12:28 schrieb David Chisnall : > > It would help if the reduced test case compiled, but adding -march=native > seems to fix that. On my FreeBSD machine, -march=native doesn't help. Intel(R) Atom(TM) CPU D510 @ 1.66GHz (1666.72-MHz K8-class CPU) > It would also help if it were something a bit more minimal, but from what > you’ve sent me: Please excuse this. I started creating a test case from scratch, but that one didn't care to crash. Then I thought that the "ambient" of the incriminated piece of code does matter, and so I stripped down the actual project and let the involved structs and types in place, because their offsets might have made up for the difference. After this exercise, I ran out of time and for this reason I could not reduce the test case further -- I was just happy that I could present something that shows the problem. > The crash happens in [CalcFactor evaluate], which simply returns the > ResultType ivar itsValue. Yes, accessing itsValue was consistently the problem in the actual project. > 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. Well, I am glad that you found the problem, and tonight I will try out libobjc2 from GitHub. Again, thank you very much for taking your time. Best regards Rolf ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Topics about GNUstep/libobjc2
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 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
> #include
> #include
> 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 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 :
>>>
>>> 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
>>>
On 24 Oct 2016, at 23:38, Dr. Rolf Jansen wrote:
Hi David,
many thanks for the reply.
Does this mean, that it is not advised to use arbitrary C structs as
Objective-C instance variables?
The code is more than 10 years old, and at that time I started learning
Objective-C, and I heavily intermixed C data structures and algorithms
into a hollow OOP construct. It is a calculator engine with more than
1 lines of code.
The code (without #pragma pack, and -O1,-O2,-O3, or -Ofast) crashes
consistently on FreeBSD when accessing one instance variable indicated
below from within the respective object.
...
typedef struct
{
ErrorFlags flag;
unsigned begin, count;
char*field;
} ErrorRecord;
typedef struct ResultType
{
ResultTypeFlags f;
unsignedn;
boolean b;
long long i;
long double r;
long double complex z;
struct ResultType *v;
char *s;
ErrorRecord e;
} ResultType;
@interface CalcObject : MyObject
{
boolean isPercent;
TokenPtritsToken;
Precedence itsPrecedence;
OpKind itsOpKind;
CalcObject *itsParent;
Calculator *itsCalculator;
}
...
- many instance methods;
...
@end
@interface CalcFactor : CalcObject
{
ResultType itsValue; accessing this one gives Bus Error
}
...
- some more instance methods;
...
@end
Questions:
As said already, on Mac OS X this code does not crash with Apple's
non-fragile ABI. Is this only by coincidence and other similar constructs
may crash? Or, may I continue to use my 1 line of code, without a
major rewrite?
Likewise on FreeBSD, is it safe to rely on the magic of #pragma pack(8) or
is my code too fragil for the non-fragil ABI?
AFAIK, 8 byte struct packing/padding is standard for 64bit architectures
and 4 byte packing/padding for 32bit architectures. Isn't it possible to
do this reliable for C structs included as Objective-C instance variables?
Best regards
Rolf
> Am 24.10.2016 um 17:09 schrieb David Chisnall
> :
gnustep.info may be down tomorrow...
The gnustep.info is up for renewal tomorrow. Currently, the site is managed on GANDI.NET, but I will be moving the registration to domains.google (purely for cost reasons). Just wanted to give anyone a heads up if you visit the site using that URL. Alternatively, if you think the domain should simply be allowed to expire, please let me know. Thanks, - - Gregory Casamento GNUstep Lead Developer / OLC, Principal Consultant http://www.gnustep.org - http://heronsperch.blogspot.com http://ind.ie/phoenix/ ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Topics about GNUstep/libobjc2
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
#include
#include
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 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 :
>>
>> 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
>>
>>> On 24 Oct 2016, at 23:38, Dr. Rolf Jansen wrote:
>>>
>>> Hi David,
>>>
>>> many thanks for the reply.
>>>
>>> Does this mean, that it is not advised to use arbitrary C structs as
>>> Objective-C instance variables?
>>>
>>> The code is more than 10 years old, and at that time I started learning
>>> Objective-C, and I heavily intermixed C data structures and algorithms into
>>> a hollow OOP construct. It is a calculator engine with more than 1
>>> lines of code.
>>>
>>> The code (without #pragma pack, and -O1,-O2,-O3, or -Ofast) crashes
>>> consistently on FreeBSD when accessing one instance variable indicated
>>> below from within the respective object.
>>>
>>> ...
>>>
>>> typedef struct
>>> {
>>> ErrorFlags flag;
>>> unsigned begin, count;
>>> char*field;
>>> } ErrorRecord;
>>>
>>> typedef struct ResultType
>>> {
>>> ResultTypeFlags f;
>>> unsignedn;
>>> boolean b;
>>> long long i;
>>> long double r;
>>> long double complex z;
>>> struct ResultType *v;
>>> char *s;
>>> ErrorRecord e;
>>> } ResultType;
>>>
>>> @interface CalcObject : MyObject
>>> {
>>> boolean isPercent;
>>> TokenPtritsToken;
>>> Precedence itsPrecedence;
>>> OpKind itsOpKind;
>>> CalcObject *itsParent;
>>> Calculator *itsCalculator;
>>> }
>>>
>>> ...
>>> - many instance methods;
>>> ...
>>>
>>> @end
>>>
>>>
>>> @interface CalcFactor : CalcObject
>>> {
>>> ResultType itsValue; accessing this one gives Bus Error
>>> }
>>>
>>> ...
>>> - some more instance methods;
>>> ...
>>>
>>> @end
>>>
>>>
>>> Questions:
>>>
>>> As said already, on Mac OS X this code does not crash with Apple's
>>> non-fragile ABI. Is this only by coincidence and other similar constructs
>>> may crash? Or, may I continue to use my 1 line of code, without a major
>>> rewrite?
>>>
>>> Likewise on FreeBSD, is it safe to rely on the magic of #pragma pack(8) or
>>> is my code too fragil for the non-fragil ABI?
>>>
>>> AFAIK, 8 byte struct packing/padding is standard for 64bit architectures
>>> and 4 byte packing/padding for 32bit architectures. Isn't it possible to do
>>> this reliable for C structs included as Objective-C instance variables?
>>>
>>> Best regards
>>>
>>> Rolf
>>>
Am 24.10.2016 um 17:09 schrieb David Chisnall
:
Hi Rolf,
With the non-fragile ABI, it isn’t safe to assume that classes have the
same layout as C structs. This works with the fragile ABI, because the
compiler is entirely responsible for layout there. It sounds as if
#pragma pack is removing some padding that the ABI mandates for C structs,
but which the Objective-C runtime is not adding.
David
> On 24 Oct 2016, at 17:52, Dr. Rolf Jansen wrote:
>
> Would it be OK to discuss on this list topics about Objective-C
> development involving clang + GNUstep/libobjc2
Re: Topics about GNUstep/libobjc2
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
> On 24 Oct 2016, at 23:38, Dr. Rolf Jansen wrote:
>
> Hi David,
>
> many thanks for the reply.
>
> Does this mean, that it is not advised to use arbitrary C structs as
> Objective-C instance variables?
>
> The code is more than 10 years old, and at that time I started learning
> Objective-C, and I heavily intermixed C data structures and algorithms into a
> hollow OOP construct. It is a calculator engine with more than 1 lines of
> code.
>
> The code (without #pragma pack, and -O1,-O2,-O3, or -Ofast) crashes
> consistently on FreeBSD when accessing one instance variable indicated below
> from within the respective object.
>
> ...
>
> typedef struct
> {
> ErrorFlags flag;
> unsigned begin, count;
> char*field;
> } ErrorRecord;
>
> typedef struct ResultType
> {
> ResultTypeFlags f;
> unsignedn;
> boolean b;
> long long i;
> long double r;
> long double complex z;
> struct ResultType *v;
> char *s;
> ErrorRecord e;
> } ResultType;
>
> @interface CalcObject : MyObject
> {
> boolean isPercent;
> TokenPtritsToken;
> Precedence itsPrecedence;
> OpKind itsOpKind;
> CalcObject *itsParent;
> Calculator *itsCalculator;
> }
>
> ...
> - many instance methods;
> ...
>
> @end
>
>
> @interface CalcFactor : CalcObject
> {
> ResultType itsValue; accessing this one gives Bus Error
> }
>
> ...
> - some more instance methods;
> ...
>
> @end
>
>
> Questions:
>
> As said already, on Mac OS X this code does not crash with Apple's
> non-fragile ABI. Is this only by coincidence and other similar constructs may
> crash? Or, may I continue to use my 1 line of code, without a major
> rewrite?
>
> Likewise on FreeBSD, is it safe to rely on the magic of #pragma pack(8) or is
> my code too fragil for the non-fragil ABI?
>
> AFAIK, 8 byte struct packing/padding is standard for 64bit architectures and
> 4 byte packing/padding for 32bit architectures. Isn't it possible to do this
> reliable for C structs included as Objective-C instance variables?
>
> Best regards
>
> Rolf
>
>> Am 24.10.2016 um 17:09 schrieb David Chisnall :
>>
>> Hi Rolf,
>>
>> With the non-fragile ABI, it isn’t safe to assume that classes have the same
>> layout as C structs. This works with the fragile ABI, because the compiler
>> is entirely responsible for layout there. It sounds as if #pragma pack is
>> removing some padding that the ABI mandates for C structs, but which the
>> Objective-C runtime is not adding.
>>
>> David
>>
>>> On 24 Oct 2016, at 17:52, Dr. Rolf Jansen wrote:
>>>
>>> Would it be OK to discuss on this list topics about Objective-C development
>>> involving clang + GNUstep/libobjc2, but almost nothing else from GNUstep?
>>>
>>> I constructed my own root class having only the bare basic methods that are
>>> needed by a quite old project, that I revamped for inclusion into a new
>>> plain C project. My class/code is working well on FreeBSD 11.0 RELEASE-p1
>>> (amd64) when compiled with clang 3.8 (system) with -O0 or -Os and linked
>>> against libobjc2 1.8.1 (ports). Once compiled with any other optimization
>>> mode, it crashes (Bus Error) when accessing a certain instance variable
>>> struct.
>>>
>>> It is working well on Mac OS X 11.12 when compiled in any -O mode with my
>>> root class and linked against the native ObjC runtime. It is almost always
>>> working on FreeBSD 11 in any -O mode when using NSObject as the root class
>>> and linked against libobjc2 1.8.1 and gnustep-base (ports), although, I saw
>>> 2 random crashes.
>>>
>>> After some debugging I found a workaround. Once I add a #pragma pack(8)
>>> directive at the top of the headers that declare my class hierarchy + all
>>> the C structs that are used throughout, the code with my root class works
>>> well on FreeBSD 11 when compiled in any -O mode -- a pack(4) does work as
>>> well.
>>>
>>> It is still possible that something is wrong with my code. However, after
>>> these many experiments, I tend to assume that the Objective-C runtime and
>>> the compiler sometimes disagree on correct packing/alignment of instance
>>> variables in instantiated objects. I can't tell, though, if the runtime or
>>> the compiler is responsible for this.
>>>
>>> In the case that it is appropriate to discuss this further on this list, I
>>> am ready to send more information. If this is not the appropriate list,
>>> then please may I ask for advise on which location this topic may be
>>> discussed.
>>>
>>> The #pragma pack(8) does neither cost anything nor
