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

[Richard Frith-Macdonald]

> On 28 Dec 2017, at 14:00, Fred Kiefer <fredkiefer@gmx.de> wrote:
> 
> 
> 
>> 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.

Yes, I forgot to mention;  when using Josh Freeman's debug outpupt (priinting 
ivar offsets as returned by the runtime and as produced by the compiler), I 
tried running a pure base tool as well as a gui test.
The behavior was consistently different in those two cases:  using a pure base 
tool, the offest given by the compiler for th->_gcontext matches that produced 
by the funtime functions, but from a gui tool it didn't.
In both cases, this is definitely with the code that prints the debug compiled 
into the base library, so it seems something about linking the gui library is 
causing the compiler generated code to misbehave.  Unfortunately I don't know 
how to figure out what might be making the difference.