Re: crash upon startup in GWorkcenter, Recycler, ProjectCenter and Gorm

[Fred Kiefer]

> Am 23.12.2017 um 12:15 schrieb Richard Frith-Macdonald 
> <richard.frith-macdonald@theengagehub.com>:
>> On 23 Dec 2017, at 09:42, Richard Frith-Macdonald 
>> <richard.frith-macdonald@theengagehub.com> wrote:
>>> On 23 Dec 2017, at 09:32, Richard Frith-Macdonald 
>>> <richard.frith-macdonald@theengagehub.com> wrote:
>>> 
>>> 
>>> So the difference between the offsets in the runtime (correct) and the 
>>> compiler (wrong) was 16 bytes, with the runtime thinking the strruct size 
>>> was 32 and trhe compiler thinking it was 16;
>>> 
>>> It seems the compiler is sizing the structure as if it contained a pointer 
>>> and two integers when it should actually be two pointers and three integers;
>> 
>> No, my mistake, that's rubbish ... on a 64bit processor the fieldds only 
>> occupy 28 bytes, so the 32 byte offset is produced by alignment rules 
>> rounding up to a 16byte boundery.
>> In that case, the offsets calculated by the compiler would be consistent 
>> with it ignoring the two __unsafe_unretained pointers.  Perhaps that is a 
>> clue?
> 
> It occurs to me that this is not anything like that simple :-(
> 
> While the compiler is getting the offset to _gcontext wrong, it's still 
> getting the offset to the next ivar (_runLoopInfo) correct, so it can't just 
> be that it's calcularing the size of the struct incorrectly.


First a thank you to both Josh and Richard for gathering so much information on 
this issue and to Richard for the quick workaround. I hope this lets simple 
GNUstep applications run on systems with non-fragile ivars. But it is 
definitely not the final solution for the issue. I was hoping for David to 
provide more insight into the working of the non-fragile code. When ever a 
class gets loaded the compiler or the runtime have to provide information about 
the ivar layout and this seems to be off for the case where the class comes 
from a different compilation unit and has a structure within. (or at least this 
is what the current findings suggest) Most likely this information comes from 
the compiler, as the runtime itself seems to have the correct information. But 
according to Josh’s finding this information isn’t just hard coded, it seems to 
change even without changes to the compilation unit.

The decision we now have to make is whether this unresolved issue is bad enough 
to block a GNUstep base release? I would suggest to go ahead with that, but if 
anybody has a different view I am fine with that.