Re: Newbie back again...

[David Chisnall]

On 19 Jun 2017, at 23:43, Josh Freeman  wrote:
> 
>   The segmentation fault happens after Base sets the value of an NSThread 
> ivar, because the memory location it writes to overlaps the area in memory 
> where GUI expects to find a different ivar, due to the mismatched layouts; 
> When GUI reads its ivar, it finds a nonzero value (garbage), and when the 
> garbage value is sent an objc message, it crashes.

This sounds like a compiler bug.  The ivar accesses should both be using the 
same offset variable.  Are you sure that both are being compiled with the same 
ABI?  If so, would it be possible for you to compile the relevant -gui file and 
NSThread.m with -S (produce assembly, don’t compile) and send me the resulting 
output?

David


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Newbie back again...

[Matt Butch]

-Matt

--

Sent from my iPhone 6S Plus
> On Jun 19, 2017, at 18:43, Josh Freeman  
> wrote:
> 
>  
> * Removed 'ninja' package from install requirements (package no longer exists 
> in 17.04 - probably wasn't the correct package anyways; 'ninja' package was a 
> privilege-escalation detector)

Weird I thought I removed that from the script when I updated it for 17.04, 
because I noticed the same thing. It was copied from the 14.04 script which is 
why it was there. 

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Newbie back again...

[David Chisnall]

> On 19 Jun 2017, at 11:11, Richard Frith-Macdonald 
>  wrote:
> 
> 
>> On 19 Jun 2017, at 10:10, David Chisnall  wrote:
>> 
>> On 24 Apr 2017, at 09:57, Richard Frith-Macdonald 
>>  wrote:
>>> 
>>> Setting variables in make is fairly straightforward, but I think only you 
>>> (and clang geeks) understand how these flags are actually supposed to work.
>>> 
>>> How are you supposed to turn use of the non-fragile ABI on/off  what flags 
>>> do you need to supply at compile time and what (if any) are supplied at 
>>> link time for
>>> a. building with the non-fragile ABI and
>>> b. building without non-fragile ABI
>> 
>> Non-fragile ABI is the default with all modern runtimes.  The correct way of 
>> specifying a runtime is with -fobjc-runtime={name}-{version}.  So, for a 
>> recent GNUstep runtime, you’d pass -fobjc-runtime=gnustep-1.7.  The compiler 
>> will then enable all of the features that it knows that this version of the 
>> runtime supports.  For example, it will use objc_msgSend on architectures 
>> where the runtime supports this, but use the two-stage lookup on other 
>> platforms.
> 
> Thanks ... that sounds clear but forgive me for wasting time 
> dopuble-checking;  We should remove support for specifying the 
> fragile/nonfragile option from gnustep make since it doesn't work on any new 
> systems?

Yes, probably.  That’s still supported in clang as a legacy compat option, but 
I think it just expands to the equivalent of something like 
-fobjc-runtime=gnustep-1.0.

> I'm happy with that (while I'd dearly like to be able to inspect variables 
> under debug without having to make explicit function calls to the runtime, 
> I'm sure people can live with that limitation).

It probably isn’t too hard to teach gdb to make those calls for you, if there’s 
someone we can persuade to do it.  I plan on looking at LLDB at some point, now 
it’s working reliably on non-Apple platforms as well.  The Apple runtimes have 
a bunch of functions that are intended to be called by the debugger that we 
don’t currently implement, which perform various operations without acquiring 
locks (on the basis that the debugger may have hit a breakpoint with the 
relevant lock held).  It’s probably worth my implementing them (or equivalents).

David


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Newbie back again...

[Richard Frith-Macdonald]

> On 19 Jun 2017, at 10:10, David Chisnall  wrote:
> 
> On 24 Apr 2017, at 09:57, Richard Frith-Macdonald 
>  wrote:
>> 
>> Setting variables in make is fairly straightforward, but I think only you 
>> (and clang geeks) understand how these flags are actually supposed to work.
>> 
>> How are you supposed to turn use of the non-fragile ABI on/off  what flags 
>> do you need to supply at compile time and what (if any) are supplied at link 
>> time for
>> a. building with the non-fragile ABI and
>> b. building without non-fragile ABI
> 
> Non-fragile ABI is the default with all modern runtimes.  The correct way of 
> specifying a runtime is with -fobjc-runtime={name}-{version}.  So, for a 
> recent GNUstep runtime, you’d pass -fobjc-runtime=gnustep-1.7.  The compiler 
> will then enable all of the features that it knows that this version of the 
> runtime supports.  For example, it will use objc_msgSend on architectures 
> where the runtime supports this, but use the two-stage lookup on other 
> platforms.

Thanks ... that sounds clear but forgive me for wasting time dopuble-checking;  
We should remove support for specifying the fragile/nonfragile option from 
gnustep make since it doesn't work on any new systems?
I'm happy with that (while I'd dearly like to be able to inspect variables 
under debug without having to make explicit function calls to the runtime, I'm 
sure people can live with that limitation).
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Newbie back again...

[David Chisnall]

On 24 Apr 2017, at 09:57, Richard Frith-Macdonald 
 wrote:
> 
> Setting variables in make is fairly straightforward, but I think only you 
> (and clang geeks) understand how these flags are actually supposed to work.
> 
> How are you supposed to turn use of the non-fragile ABI on/off  what flags do 
> you need to supply at compile time and what (if any) are supplied at link 
> time for
> a. building with the non-fragile ABI and
> b. building without non-fragile ABI

Non-fragile ABI is the default with all modern runtimes.  The correct way of 
specifying a runtime is with -fobjc-runtime={name}-{version}.  So, for a recent 
GNUstep runtime, you’d pass -fobjc-runtime=gnustep-1.7.  The compiler will then 
enable all of the features that it knows that this version of the runtime 
supports.  For example, it will use objc_msgSend on architectures where the 
runtime supports this, but use the two-stage lookup on other platforms.

> To what extent are other features dependent on it?  eg. can you have ARC 
> without nonfragile ABI?

No, ARC requires the non-fragile ABI.

David



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Newbie back again...

[Patryk Laurent]

Hi folks,

Just wanted to let you know this issue appears to remain unresolved. Today I 
checked out and built all sources from the git repo under Ubuntu 16.04. The 
simple GUI test[1] built with a Makefile and run with openapp ./GUItest.app 
segfaults. 

(But it runs fine if I compile it by hand with

clang `gnustep-config --objc-flags` `gnustep-config --objc-libs`  
-fobjc-runtime=gnustep -fblocks -lobjc -fobjc-arc -ldispatch -lgnustep-base 
-lgnustep-gui  guitest.m

and then run the resulting ./a.out
)

Could anyone say how to fix it?

Thank you,
Patryk

[1] GUI test from http://wiki.gnustep.org/index.php/GNUstep_under_Ubuntu_Linux

> On Apr 24, 2017, at 00:42, David Chisnall  wrote:
> 
> -fobjc-nonfragile-abi has been a deprecated flag for 2-3 years.  Please can 
> someone who understands GNUstep Make fix the build system to use 
> -fobjc-runtime= instead?
> 
> David
> 
>> On 23 Apr 2017, at 23:34, Josh Freeman  
>> wrote:
>> 
>>  Turns out the issue is with the placement of the objc-nonfragile-abi build 
>> flag in common.make, line 670: For some reason, the affected distros (seen 
>> so far on: Ubuntu 16.04, Mint 18.1, Debian Jessie; 32bit, perhaps 64bit?) 
>> will build base & gui with mismatched and/or broken ABIs if 
>> -fobjc-nonfragile-abi is added to INTERNAL_OBJCFLAGS. It works fine, 
>> however, if fobjc-nonfragile-abi is instead added to INTERNAL_LDFLAGS, which 
>> is how it was in the trunk until a couple weeks ago:
>> https://github.com/gnustep/make/commit/d0263e4fb47d6529ac2dd1de913e5061618eb15f
>> 
>>  Reverting that change fixes the crashes, however, that will also break ARC, 
>> according to https://savannah.gnu.org/bugs/?50751 . I also tried installing 
>> with fobjc-nonfragile-abi added to both INTERNAL_OBJCFLAGS and 
>> INTERNAL_LDFLAGS (matching the pattern used for fobjcexceptions at 
>> common.make:662), but the crashes came back; Seems the problem is 
>> specifically with adding fobjc-nonfragile-abi to INTERNAL_OBJCFLAGS, 
>> regardless of whether it's also added to INTERNAL_LDFLAGS.
>> 
>>  Until we can find a permanent solution that hopefully fixes both the broken 
>> ABIs and ARC, here are some short-term workarounds to build a working 
>> GNUstep with clang/objc2 on the affected distros:
>> 
>> 1) Build with the fragile ABI: Remove the --enable-objc-nonfragile-abi flag 
>> from the GS make's ./configure commands (both of them) in the build script. 
>> This also means you'll need to recompile your apps whenever you install new 
>> versions of the GS frameworks.
>> 
>> 2) Build with an earlier version of make (though this will break ARC): In 
>> the build script, after changing to the make directory, but before 
>> configuring make (the first time it's built), add a git checkout command to 
>> force it to use a source-tree snapshot from before April 7:
>> 
>> ...
>> cd make
>> git checkout `git rev-list -1 --first-parent --before=2017-04-06`
>> ./configure --enable-debug-by-default --with-layout=gnustep 
>> --enable-objc-nonfragile-abi --enable-objc-arc
>> ...
>> 
>> 3) I attached a modified "16.04 & 16.10" script for Ubuntu/Mint from the 
>> wiki, which lets you build GS/objc2/libdispatch using checkouts from a 
>> particular date, set in the script's CHECKOUT_DATE var. (This automates the 
>> workaround in #2 above, but for all the source trees, not just make). It was 
>> useful in figuring out the abi issue, because then it just became a question 
>> of finding when the problem first appeared. It can also be helpful for 
>> testing apps on older GS versions (on Ubuntu or related distros).
>> 
>> 
>> Cheers,
>> 
>> Josh
>> 
>> 
>> 
>> 
>> 
>> 
>> 
 On Apr 23, 2017, at 4:18 PM, Fred Kiefer wrote:
>>> 
>>> Thank you Josh,
>>> 
>>> this was an excellent analysis. Did you try to unset GNUSTEP_BASE_LIBRARY 
>>> in NSGraphicsContext.m? That should switch to the other code path that 
>>> won’t use internal structures from base.
>>> 
>>> As for the problem with the NSThread ivars. What has changed on your test 
>>> system? Do you think the change in on the GNUstep side or was there a 
>>> behaviour change in clang?
>>> 
>>> Fred
>>> 
>>> 
 Am 23.04.2017 um 09:39 schrieb Josh Freeman 
 :
 
 Hi Bertrand,
 
 Thanks for the info! I'm seeing the same issue - after making a clean 
 GNUstep install from the trunk, any app built from it segfaults 
 immediately, always in the same location: +[NSGraphicsContext 
 setCurrentContext:]. This is on two different virtual machines, one with 
 Ubuntu 16.04, the other with Linux Mint MATE 18.1 (both up-to-date, 
 32-bit, Clang 3.8).
 
 I've tried a few different ways of installing GS, including some old 
 scripts that used to work, as well as the current "16.04 & 16.10" script 
 from the "GNUstep under Ubuntu Linux" wiki page. I also tried disabling 
 blocks & ARC, but still get the same problem: the 

Re: Newbie back again...

[Patryk Laurent]

I can confirm that for a successful GNUstep build on Ubuntu 16.04, it is 
sufficient to check out the older version of GNUstep Make -- no need to check 
out older versions of the other repositories.  

openapp ./GUITest worked without crashing.

Patryk



On Apr 23, 2017, at 04:22 PM, Josh Freeman  
wrote:

Sorry, the git checkout command for workaround #2 in my previous 
message is missing "master" at the end:



git checkout `git rev-list -1 --first-parent --before=2017-04-06`

should be:

git checkout `git rev-list -1 --first-parent --before=2017-04-06 master`


On Apr 23, 2017, at 6:34 PM, Josh Freeman wrote:

2) Build with an earlier version of make (though this will break
ARC): In the build script, after changing to the make directory, but
before configuring make (the first time it's built), add a git
checkout command to force it to use a source-tree snapshot from
before April 7:

...
cd make
git checkout `git rev-list -1 --first-parent --before=2017-04-06`
./configure --enable-debug-by-default --with-layout=gnustep --enable-
objc-nonfragile-abi --enable-objc-arc
...


___
Discuss-gnustep mailing list
discuss-gnus...@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Newbie back again...

[Richard Frith-Macdonald]

> On 24 Apr 2017, at 08:42, David Chisnall  wrote:
> 
> -fobjc-nonfragile-abi has been a deprecated flag for 2-3 years.  Please can 
> someone who understands GNUstep Make fix the build system to use 
> -fobjc-runtime= instead?

The build system already uses -fobjc-runtime= ... but also still has options 
that look like they were/are intended to turn nonfragile ABI on/off.

Setting variables in make is fairly straightforward, but I think only you (and 
clang geeks) understand how these flags are actually supposed to work.

How are you supposed to turn use of the non-fragile ABI on/off  what flags do 
you need to supply at compile time and what (if any) are supplied at link time 
for
a. building with the non-fragile ABI and
b. building without non-fragile ABI

To what extent are other features dependent on it?  eg. can you have ARC 
without nonfragile ABI?

Incidentally, we really need a patch to make nonfragile abi work with gdb (ie 
so that looking at object instance variable works with the nonfragile ABI), so 
that we can make nonfagile ABI the default.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Newbie back again...

[David Chisnall]

-fobjc-nonfragile-abi has been a deprecated flag for 2-3 years.  Please can 
someone who understands GNUstep Make fix the build system to use 
-fobjc-runtime= instead?

David

> On 23 Apr 2017, at 23:34, Josh Freeman  wrote:
> 
>   Turns out the issue is with the placement of the objc-nonfragile-abi build 
> flag in common.make, line 670: For some reason, the affected distros (seen so 
> far on: Ubuntu 16.04, Mint 18.1, Debian Jessie; 32bit, perhaps 64bit?) will 
> build base & gui with mismatched and/or broken ABIs if -fobjc-nonfragile-abi 
> is added to INTERNAL_OBJCFLAGS. It works fine, however, if 
> fobjc-nonfragile-abi is instead added to INTERNAL_LDFLAGS, which is how it 
> was in the trunk until a couple weeks ago:
> https://github.com/gnustep/make/commit/d0263e4fb47d6529ac2dd1de913e5061618eb15f
> 
>   Reverting that change fixes the crashes, however, that will also break ARC, 
> according to https://savannah.gnu.org/bugs/?50751 . I also tried installing 
> with fobjc-nonfragile-abi added to both INTERNAL_OBJCFLAGS and 
> INTERNAL_LDFLAGS (matching the pattern used for fobjcexceptions at 
> common.make:662), but the crashes came back; Seems the problem is 
> specifically with adding fobjc-nonfragile-abi to INTERNAL_OBJCFLAGS, 
> regardless of whether it's also added to INTERNAL_LDFLAGS.
> 
>   Until we can find a permanent solution that hopefully fixes both the broken 
> ABIs and ARC, here are some short-term workarounds to build a working GNUstep 
> with clang/objc2 on the affected distros:
> 
> 1) Build with the fragile ABI: Remove the --enable-objc-nonfragile-abi flag 
> from the GS make's ./configure commands (both of them) in the build script. 
> This also means you'll need to recompile your apps whenever you install new 
> versions of the GS frameworks.
> 
> 2) Build with an earlier version of make (though this will break ARC): In the 
> build script, after changing to the make directory, but before configuring 
> make (the first time it's built), add a git checkout command to force it to 
> use a source-tree snapshot from before April 7:
> 
> ...
> cd make
> git checkout `git rev-list -1 --first-parent --before=2017-04-06`
> ./configure --enable-debug-by-default --with-layout=gnustep 
> --enable-objc-nonfragile-abi --enable-objc-arc
> ...
> 
> 3) I attached a modified "16.04 & 16.10" script for Ubuntu/Mint from the 
> wiki, which lets you build GS/objc2/libdispatch using checkouts from a 
> particular date, set in the script's CHECKOUT_DATE var. (This automates the 
> workaround in #2 above, but for all the source trees, not just make). It was 
> useful in figuring out the abi issue, because then it just became a question 
> of finding when the problem first appeared. It can also be helpful for 
> testing apps on older GS versions (on Ubuntu or related distros).
> 
> 
> Cheers,
> 
> Josh
> 
> 
> 
> 
> 
> 
> 
> On Apr 23, 2017, at 4:18 PM, Fred Kiefer wrote:
> 
>> Thank you Josh,
>> 
>> this was an excellent analysis. Did you try to unset GNUSTEP_BASE_LIBRARY in 
>> NSGraphicsContext.m? That should switch to the other code path that won’t 
>> use internal structures from base.
>> 
>> As for the problem with the NSThread ivars. What has changed on your test 
>> system? Do you think the change in on the GNUstep side or was there a 
>> behaviour change in clang?
>> 
>> Fred
>> 
>> 
>>> Am 23.04.2017 um 09:39 schrieb Josh Freeman 
>>> :
>>> 
>>> Hi Bertrand,
>>> 
>>> Thanks for the info! I'm seeing the same issue - after making a clean 
>>> GNUstep install from the trunk, any app built from it segfaults 
>>> immediately, always in the same location: +[NSGraphicsContext 
>>> setCurrentContext:]. This is on two different virtual machines, one with 
>>> Ubuntu 16.04, the other with Linux Mint MATE 18.1 (both up-to-date, 32-bit, 
>>> Clang 3.8).
>>> 
>>> I've tried a few different ways of installing GS, including some old 
>>> scripts that used to work, as well as the current "16.04 & 16.10" script 
>>> from the "GNUstep under Ubuntu Linux" wiki page. I also tried disabling 
>>> blocks & ARC, but still get the same problem: the apps (ProjectCenter, 
>>> Gorm, GWorkspace, SystemPreferences, PikoPixel) build fine, then crash when 
>>> run.
>>> 
>>> One thing that still works is building with GCC & its runtime, though this 
>>> means no blocks, ARC, etc. I've attached a modified version of the "16.04 & 
>>> 16.10" wiki script that builds successfully with gcc on both of my 
>>> machines. It doesn't have the 'sudo dpkg --add-architecture i386' line you 
>>> added, so you might need to put that in (though it might no longer be an 
>>> issue with the different runtime). Also, the script has libxft-dev 
>>> uncapitalized, unlike yours where it's libXft-dev (didn't work on 
>>> Ubuntu/Mint), so you might need to change it back for your machine.
>>> 
>>> 
>>> Regarding the crashes, here's what I've figured out so far:
>>> 
>>> - The crash is 

Re: Newbie back again...

[Josh Freeman]

Sorry, the git checkout command for workaround #2 in my previous  
message is missing "master" at the end:



git checkout `git rev-list -1 --first-parent --before=2017-04-06`

should be:

git checkout `git rev-list -1 --first-parent --before=2017-04-06 master`


On Apr 23, 2017, at 6:34 PM, Josh Freeman wrote:

2) Build with an earlier version of make (though this will break  
ARC): In the build script, after changing to the make directory, but  
before configuring make (the first time it's built), add a git  
checkout command to force it to use a source-tree snapshot from  
before April 7:


...
cd make
git checkout `git rev-list -1 --first-parent --before=2017-04-06`
./configure --enable-debug-by-default --with-layout=gnustep --enable- 
objc-nonfragile-abi --enable-objc-arc

...



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Newbie back again...

[Josh Freeman]

   Turns out the issue is with the placement of the objc-nonfragile- 
abi build flag in common.make, line 670: For some reason, the affected  
distros (seen so far on: Ubuntu 16.04, Mint 18.1, Debian Jessie;  
32bit, perhaps 64bit?) will build base & gui with mismatched and/or  
broken ABIs if -fobjc-nonfragile-abi is added to INTERNAL_OBJCFLAGS.  
It works fine, however, if fobjc-nonfragile-abi is instead added to  
INTERNAL_LDFLAGS, which is how it was in the trunk until a couple  
weeks ago:

https://github.com/gnustep/make/commit/d0263e4fb47d6529ac2dd1de913e5061618eb15f

   Reverting that change fixes the crashes, however, that will also  
break ARC, according to https://savannah.gnu.org/bugs/?50751 . I also  
tried installing with fobjc-nonfragile-abi added to both  
INTERNAL_OBJCFLAGS and INTERNAL_LDFLAGS (matching the pattern used for  
fobjcexceptions at common.make:662), but the crashes came back; Seems  
the problem is specifically with adding fobjc-nonfragile-abi to  
INTERNAL_OBJCFLAGS, regardless of whether it's also added to  
INTERNAL_LDFLAGS.


   Until we can find a permanent solution that hopefully fixes both  
the broken ABIs and ARC, here are some short-term workarounds to build  
a working GNUstep with clang/objc2 on the affected distros:


1) Build with the fragile ABI: Remove the --enable-objc-nonfragile-abi  
flag from the GS make's ./configure commands (both of them) in the  
build script. This also means you'll need to recompile your apps  
whenever you install new versions of the GS frameworks.


2) Build with an earlier version of make (though this will break ARC):  
In the build script, after changing to the make directory, but before  
configuring make (the first time it's built), add a git checkout  
command to force it to use a source-tree snapshot from before April 7:


...
cd make
git checkout `git rev-list -1 --first-parent --before=2017-04-06`
./configure --enable-debug-by-default --with-layout=gnustep --enable- 
objc-nonfragile-abi --enable-objc-arc

...

3) I attached a modified "16.04 & 16.10" script for Ubuntu/Mint from  
the wiki, which lets you build GS/objc2/libdispatch using checkouts  
from a particular date, set in the script's CHECKOUT_DATE var. (This  
automates the workaround in #2 above, but for all the source trees,  
not just make). It was useful in figuring out the abi issue, because  
then it just became a question of finding when the problem first  
appeared. It can also be helpful for testing apps on older GS versions  
(on Ubuntu or related distros).



Cheers,

Josh




install-gnustep-with-clang-from-date.sh
Description: Binary data






On Apr 23, 2017, at 4:18 PM, Fred Kiefer wrote:


Thank you Josh,

this was an excellent analysis. Did you try to unset  
GNUSTEP_BASE_LIBRARY in NSGraphicsContext.m? That should switch to  
the other code path that won’t use internal structures from base.


As for the problem with the NSThread ivars. What has changed on your  
test system? Do you think the change in on the GNUstep side or was  
there a behaviour change in clang?


Fred


Am 23.04.2017 um 09:39 schrieb Josh Freeman :


Hi Bertrand,

 Thanks for the info! I'm seeing the same issue - after making a  
clean GNUstep install from the trunk, any app built from it  
segfaults immediately, always in the same location: + 
[NSGraphicsContext setCurrentContext:]. This is on two different  
virtual machines, one with Ubuntu 16.04, the other with Linux Mint  
MATE 18.1 (both up-to-date, 32-bit, Clang 3.8).


 I've tried a few different ways of installing GS, including some  
old scripts that used to work, as well as the current "16.04 &  
16.10" script from the "GNUstep under Ubuntu Linux" wiki page. I  
also tried disabling blocks & ARC, but still get the same problem:  
the apps (ProjectCenter, Gorm, GWorkspace, SystemPreferences,  
PikoPixel) build fine, then crash when run.


 One thing that still works is building with GCC & its runtime,  
though this means no blocks, ARC, etc. I've attached a modified  
version of the "16.04 & 16.10" wiki script that builds successfully  
with gcc on both of my machines. It doesn't have the 'sudo dpkg -- 
add-architecture i386' line you added, so you might need to put  
that in (though it might no longer be an issue with the different  
runtime). Also, the script has libxft-dev uncapitalized, unlike  
yours where it's libXft-dev (didn't work on Ubuntu/Mint), so you  
might need to change it back for your machine.



 Regarding the crashes, here's what I've figured out so far:

- The crash is from trying to send an objc message to a non-object.
- The crash happens inside +[NSGraphicsContext setCurrentContext:]  
the first time it's called.
- Before crashing, setCurrentContext:'s local var, (NSThread *) th,  
is set to the current thread (return value of GSCurrentThread()),  
which is a valid object.
- setCurrentContext:'s passed parameter value, (NSGraphicsContext  
*) context, is also a 

Re: Newbie back again...

[Fred Kiefer]

Thank you Josh,

this was an excellent analysis. Did you try to unset GNUSTEP_BASE_LIBRARY in 
NSGraphicsContext.m? That should switch to the other code path that won’t use 
internal structures from base.

As for the problem with the NSThread ivars. What has changed on your test 
system? Do you think the change in on the GNUstep side or was there a behaviour 
change in clang?

Fred


> Am 23.04.2017 um 09:39 schrieb Josh Freeman :
> 
> Hi Bertrand,
> 
>   Thanks for the info! I'm seeing the same issue - after making a clean 
> GNUstep install from the trunk, any app built from it segfaults immediately, 
> always in the same location: +[NSGraphicsContext setCurrentContext:]. This is 
> on two different virtual machines, one with Ubuntu 16.04, the other with 
> Linux Mint MATE 18.1 (both up-to-date, 32-bit, Clang 3.8).
> 
>   I've tried a few different ways of installing GS, including some old 
> scripts that used to work, as well as the current "16.04 & 16.10" script from 
> the "GNUstep under Ubuntu Linux" wiki page. I also tried disabling blocks & 
> ARC, but still get the same problem: the apps (ProjectCenter, Gorm, 
> GWorkspace, SystemPreferences, PikoPixel) build fine, then crash when run.
> 
>   One thing that still works is building with GCC & its runtime, though this 
> means no blocks, ARC, etc. I've attached a modified version of the "16.04 & 
> 16.10" wiki script that builds successfully with gcc on both of my machines. 
> It doesn't have the 'sudo dpkg --add-architecture i386' line you added, so 
> you might need to put that in (though it might no longer be an issue with the 
> different runtime). Also, the script has libxft-dev uncapitalized, unlike 
> yours where it's libXft-dev (didn't work on Ubuntu/Mint), so you might need 
> to change it back for your machine.
> 
> 
>   Regarding the crashes, here's what I've figured out so far:
> 
> - The crash is from trying to send an objc message to a non-object.
> - The crash happens inside +[NSGraphicsContext setCurrentContext:] the first 
> time it's called.
> - Before crashing, setCurrentContext:'s local var, (NSThread *) th, is set to 
> the current thread (return value of GSCurrentThread()), which is a valid 
> object.
> - setCurrentContext:'s passed parameter value, (NSGraphicsContext *) context, 
> is also a valid object.
> - th's instance var, (id) _gcontext (pointer to the current graphics 
> context), however, contains a garbage value: 32.
> - The crash happens inside the macro, ASSIGN(th->_gcontext, context) - after 
> context is sent a retain message and stored in _gcontext, _gcontext's old 
> value (32, non-object) is sent a release message.
> 
>   * Where did the 32 come from?
> 
> - Looking at NSThread.h, the instance var immediately before _gcontext is 
> _autorelease_vars, an autorelease_thread_vars struct (5-member struct, 
> defined in NSAutoreleasePool.h).
> - When the [NSAutoreleasePool dealloc] method (NSAutoreleasePool.m:561) is 
> called (every time an autorelease pool drains), a pointer to the current 
> thread object's _autorelease_vars ivar struct is stored in dealloc's local 
> var, (struct autorelease_thread_vars *) tv.
> - dealloc passes tv to the local function, push_pool_to_cache() 
> (NSAutoreleasePool.m:106), where - if the struct needs initialization - tv is 
> then passed to another local function, init_pool_cache().
> - init_pool_cache() (NSAutoreleasePool.m:98) sets the value of one of tv's 
> struct members, (int) pool_cache_size, to the value 32.
> 
>   * How does the 32 move from _autorelease_vars to _gcontext?
> 
> - Looking at the autorelease_thread_vars definition in NSAutoreleasePool.h, 
> pool_cache_size is the second-to-last member in the struct, so it's quite 
> close in memory to its neighboring instance var, _gcontext: 8 bytes away, 
> assuming no extra padding.
> 
>   * How does an address pointer lose/gain 8 bytes?
> 
>   Somehow NSAutoreleasePool.m (in base) and NSGraphicsContext.m (in gui) are 
> in disagreement about the offsets to an NSThread object's instance vars: In 
> NSAutoreleasePool.m, the statement 
> (&((GSCurrentThread())->_autorelease_vars)) results in a memory address that 
> is less than sizeof(struct autorelease_thread_vars) away from the memory 
> address NSGraphicsContext.m calculates as the location of 
> GSCurrentThread()->_gcontext; When init_pool_cache() sets the current 
> thread's _autorelease_vars' pool_cache_size member near the end of the 
> struct, it's writing the value 32 to the same address later used by 
> setCurrentContext: as the current thread's _gcontext. (I verified this with a 
> gdb memory watchpoint).
> 
>   The crash in +[NSGraphicsContext setCurrentContext:] also goes away if you 
> add some extra padding bytes in the NSThread struct between _autorelease_vars 
> & _gcontext (not that that's a solution - it just postpones the crash to a 
> later point, in GSWindowDecorationView.m).
> 
>   So I think the ivar offsets 

Re: Newbie back again...

[Josh Freeman]

Hi Bertrand,

   Thanks for the info! I'm seeing the same issue - after making a  
clean GNUstep install from the trunk, any app built from it segfaults  
immediately, always in the same location: +[NSGraphicsContext  
setCurrentContext:]. This is on two different virtual machines, one  
with Ubuntu 16.04, the other with Linux Mint MATE 18.1 (both up-to- 
date, 32-bit, Clang 3.8).


   I've tried a few different ways of installing GS, including some  
old scripts that used to work, as well as the current "16.04 & 16.10"  
script from the "GNUstep under Ubuntu Linux" wiki page. I also tried  
disabling blocks & ARC, but still get the same problem: the apps  
(ProjectCenter, Gorm, GWorkspace, SystemPreferences, PikoPixel) build  
fine, then crash when run.


   One thing that still works is building with GCC & its runtime,  
though this means no blocks, ARC, etc. I've attached a modified  
version of the "16.04 & 16.10" wiki script that builds successfully  
with gcc on both of my machines. It doesn't have the 'sudo dpkg --add- 
architecture i386' line you added, so you might need to put that in  
(though it might no longer be an issue with the different runtime).  
Also, the script has libxft-dev uncapitalized, unlike yours where it's  
libXft-dev (didn't work on Ubuntu/Mint), so you might need to change  
it back for your machine.



   Regarding the crashes, here's what I've figured out so far:

- The crash is from trying to send an objc message to a non-object.
- The crash happens inside +[NSGraphicsContext setCurrentContext:] the  
first time it's called.
- Before crashing, setCurrentContext:'s local var, (NSThread *) th, is  
set to the current thread (return value of GSCurrentThread()), which  
is a valid object.
- setCurrentContext:'s passed parameter value, (NSGraphicsContext *)  
context, is also a valid object.
- th's instance var, (id) _gcontext (pointer to the current graphics  
context), however, contains a garbage value: 32.
- The crash happens inside the macro, ASSIGN(th->_gcontext, context) -  
after context is sent a retain message and stored in _gcontext,  
_gcontext's old value (32, non-object) is sent a release message.


   * Where did the 32 come from?

- Looking at NSThread.h, the instance var immediately before _gcontext  
is _autorelease_vars, an autorelease_thread_vars struct (5-member  
struct, defined in NSAutoreleasePool.h).
- When the [NSAutoreleasePool dealloc] method (NSAutoreleasePool.m: 
561) is called (every time an autorelease pool drains), a pointer to  
the current thread object's _autorelease_vars ivar struct is stored in  
dealloc's local var, (struct autorelease_thread_vars *) tv.
- dealloc passes tv to the local function, push_pool_to_cache()  
(NSAutoreleasePool.m:106), where - if the struct needs initialization  
- tv is then passed to another local function, init_pool_cache().
- init_pool_cache() (NSAutoreleasePool.m:98) sets the value of one of  
tv's struct members, (int) pool_cache_size, to the value 32.


   * How does the 32 move from _autorelease_vars to _gcontext?

- Looking at the autorelease_thread_vars definition in  
NSAutoreleasePool.h, pool_cache_size is the second-to-last member in  
the struct, so it's quite close in memory to its neighboring instance  
var, _gcontext: 8 bytes away, assuming no extra padding.


   * How does an address pointer lose/gain 8 bytes?

   Somehow NSAutoreleasePool.m (in base) and NSGraphicsContext.m (in  
gui) are in disagreement about the offsets to an NSThread object's  
instance vars: In NSAutoreleasePool.m, the statement  
(&((GSCurrentThread())->_autorelease_vars)) results in a memory  
address that is less than sizeof(struct autorelease_thread_vars) away  
from the memory address NSGraphicsContext.m calculates as the location  
of GSCurrentThread()->_gcontext; When init_pool_cache() sets the  
current thread's _autorelease_vars' pool_cache_size member near the  
end of the struct, it's writing the value 32 to the same address later  
used by setCurrentContext: as the current thread's _gcontext. (I  
verified this with a gdb memory watchpoint).


   The crash in +[NSGraphicsContext setCurrentContext:] also goes  
away if you add some extra padding bytes in the NSThread struct  
between _autorelease_vars & _gcontext (not that that's a solution - it  
just postpones the crash to a later point, in GSWindowDecorationView.m).


   So I think the ivar offsets disagreement is the condition that  
causes the crash - any ideas what's causing the condition? Possibly a  
config issue that's causing clang to use different struct padding  
settings between base & gui?


Cheers,

Josh




install-current-gnustep-with-gcc.sh
Description: Binary data






On Apr 22, 2017, at 11:03 PM, Bertrand Gmail wrote:

Preamble : sorry for the noise on gnustep-dev mailing list. I've  
reposted the messages here.


And...finally, it still doesn't work.

I thought that the problem had disappeared because I could compile  
and run a sample 

Re: Newbie back again...

[Bertrand Gmail]

Sorry for the mistake, I didn't send the correct script (missing the 
i386 architecture option). Here it is again.


Bertrand


Le 23/04/2017 à 03:23, Bertrand Gmail a écrit :

Hi, Yan
I've spent several hours trying to reinstall again and again with 
clang, objc2, blocks and so on.


And yes, it's a real pain. But I've got now something that seems to be 
finally running.


First of all, regarding your initial question on adding the 386 
architecture on debian Jessie ; yes it's mandatory.


Without it, gui apps will segfault in Debian Jessie, due to something 
in libobjc.
I've seen on 
http://wiki.gnustep.org/index.php/GNUstep_under_Ubuntu_Linux that this 
option was set in the "ubuntu 1404 " section but not in the "ubuntu 
1604" one.


I've reworked my script and I've splitted it in two parts (one for 
installing the dependancies, the other for compilation).

They work as is.

Maybe your problem for now is that libobjc isn't in a place where 
gnustep can find it. I remembered that sometimes ago, it wasn't 
installed in /usr/GNUstep/Local/Library/Libraries and my compiler 
didn't find it. I just picked the files in /usr/local and put them at 
that place and everything worked.


But I didn't have this problem today : everything is at his place and 
run.



You can try them in a clean jessie install to avoid some common 
problems with libraries mismatched or still installed.


Final note : in the script, I didn't add "export CC=clang"  and 
"export CXX=clang++" to bashrc so you will need to pass this option 
each time you compile some other program with gnustep.


Cheers,
Bertrand




my_install_gnustep_first_stage.sh
Description: application/shellscript
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Newbie back again...

[Bertrand Gmail]

Hi, Yan
I've spent several hours trying to reinstall again and again with clang, 
objc2, blocks and so on.


And yes, it's a real pain. But I've got now something that seems to be 
finally running.


First of all, regarding your initial question on adding the 386 
architecture on debian Jessie ; yes it's mandatory.


Without it, gui apps will segfault in Debian Jessie, due to something in 
libobjc.
I've seen on 
http://wiki.gnustep.org/index.php/GNUstep_under_Ubuntu_Linux that this 
option was set in the "ubuntu 1404 " section but not in the "ubuntu 
1604" one.


I've reworked my script and I've splitted it in two parts (one for 
installing the dependancies, the other for compilation).

They work as is.

Maybe your problem for now is that libobjc isn't in a place where 
gnustep can find it. I remembered that sometimes ago, it wasn't 
installed in /usr/GNUstep/Local/Library/Libraries and my compiler didn't 
find it. I just picked the files in /usr/local and put them at that 
place and everything worked.


But I didn't have this problem today : everything is at his place and run.


You can try them in a clean jessie install to avoid some common problems 
with libraries mismatched or still installed.


Final note : in the script, I didn't add "export CC=clang"  and "export 
CXX=clang++" to bashrc so you will need to pass this option each time 
you compile some other program with gnustep.


Cheers,
Bertrand


my_install_gnustep_first_stage.sh
Description: application/shellscript


my_install_gnustep_second_stage.sh
Description: application/shellscript
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Newbie back again...

[Fred Kiefer]

Sorry, this is the point where I have to drop out. Perhaps David has time to 
take over? For this reason I send this mail again to the mailing list. That way 
you will get the best support available.

What you are getting is a mismatch between the available Objective-C runtimes. 
What I could recommend is to make sure that you have only one runtime at a time 
visible for your compilation. I would also suggest to make the compiler more 
explicit, by setting the CC variable. The mechanism to switch on the 
compilation messages didn’t work for you. I think you did forget the „s“ from 
„messages“, but you may also have to set the variable before the command, I 
really don’t remember. This also means you should have gotten the same messages 
during your last run, why didn’t you send them along?
With messages enabled we could see the actual compilation command and would be 
able to tell, which of your compilers get used and what the parameters are.

Fred




> Am 22.04.2017 um 21:54 schrieb Yan Le Guen :
> 
> >Yes, GNUstep still seems to be alive.
> Well good news ;-)
> Not going to argue about sync & multiple differents instructions files...
> 
> >Now to your actual problems:
> 
> >> Am 22.04.2017 um 16:47 schrieb Yan Le Guen :
> >>
> >> Me back again a bit desapointed... that's eventually explaining why so 
> >> long is this post...
> >>
> >> Here is attached:
> >> 1) the output file resulting after executing the following command line 
> >> after having cd $BUILD_DIR/core/make (version 2.7 from svn) :
> >> ./configure --enable-debug-by-default --with-layout=gnustep 
> >> --enable-objc-nonfragile-abi
> 
> >Did you also make and make install this package? And source the GNUstep.sh 
> >file after that? Sorry, but it is hard to guess what your did without any 
> >transcript.
> I of course did run:
> sudo -E make install
> . /usr/GNUstep/System/Library/Makefiles/GNUstep.sh
> and also update my ~/.bashrc on the fly...
> 
> >> 2) the output file resulting after executing the following command line 
> >> after having cd $BUILD_DIR/core/base (version 1.5 from svn):
> >> ./configure
> 
> >This output looks fine to me.
> well, this part of this outup point out some 'NO' that I do not really 
> understand:
> 
> checking whether objc really works... yes
> checking if the compiler supports -fconstant-string-class... yes
> checking if +load method is executed before main... yes
> checking for objc_sync_enter... yes
> checking for objc_setProperty... yes
> checking for _Block_copy... no
> checking for non-fragile-abi support... yes
> checking for objc_setUncaughtExceptionHandler() in runtime... no
> checking for objc_set_unexpected() in runtime... no
> checking for _objc_unexpected_exception in runtime... no
> configure: Disabling native Objective-C exceptions because the ObjC 
> runtime
> configure: has no way to set an uncaught exception handler.  Please 
> install
> configure: a recent Objective-C runtime if you want to use them.
> checking whether to enable native Objective-C exceptions... no
> checking for objc_sync_enter... (cached) yes
> checking for thread-safe +initialize in runtime... yes
> 
> 
> 
> >> 3) the output file resulting after executing the following command line 
> >> after having cd $BUILD_DIR/core/base :
> >> ./make -j2
> 
> >Now this is the bit that I really don’t understand and I can see why this is 
> >frustrating for you. Something goes wrong and there is no telling what or 
> >why.
> >GNUstep make is filtering off most of the output. You need to switch the 
> >display of compile messages on by calling make with the variable messages 
> >set to yes. I think this >gets done with this line, but I currently cannot 
> >test it.
> 
> >„make messages=yes“
> 
> OK, using this make command:
> 
> make -j2 message=yes | tee GUNstep-Base_make_outupt.txt
> 
> return this:
> This is gnustep-make 2.7.0. Type 'make print-gnustep-make-help' for help.
> Running in gnustep-make version 2 strict mode.
> Making all in Source ...
> rm -f dynamic-load.h
> cp simple-load.h dynamic-load.h
> /usr/GNUstep/System/Library/Makefiles/mkinstalldirs .
> cp ../Headers/GNUstepBase/config.h .
> touch ./config.h
> /usr/GNUstep/System/Library/Makefiles/mkinstalldirs ./GNUstepBase
> cp ../Headers/GNUstepBase/GSConfig.h ./GNUstepBase
> touch ./GNUstepBase/GSConfig.h
> Making all in Additions ...
> Making all for subproject Additions...
>  Compiling file GSTypeEncoding.c ...
>  Compiling file GSObjCRuntime.m ...
> In file included from GSObjCRuntime.m:39:
> ../../Headers/Foundation/NSException.h:44:2: error: "There are two separate 
> exception handling mechanisms
>   available ... one based on the standard setjmp() function (which does 
> not require special compiler
>   support), and one 'native' version where the compiler manages the 
> exception handling. If you try to use
>   both in the same executable, exception handlers will not work... which 
>