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 <gnustep_lists@twilightedge.com> 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
> 
> 
> <install-gnustep-with-clang-from-date.sh>
> 
> 
> 
> 
> 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 
>>> <gnustep_lists@twilightedge.com>:
>>> 
>>> 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>
>>> 
>>> 
>>> 
>>> 
>>> 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 program given on the ubuntu installation notes on the gnustep 
>>>> wiki.
>>>> 
>>>> This is this program : guitest.m
>>>> 
>>>> #import <AppKit/AppKit.h> int main() { NSApplication *app; // Without 
>>>> these 2 lines, seg fault may occur app = [NSApplication 
>>>> sharedApplication]; NSAlert * alert = [[NSAlert alloc] init]; [alert 
>>>> setMessageText:@"Hello alert"]; [alert addButtonWithTitle:@"All done"]; 
>>>> int result = [alert runModal]; if (result == NSAlertFirstButtonReturn) { 
>>>> NSLog(@"First button pressed"); } }
>>>> 
>>>> 
>>>> This compiles and run fine it i use this command :
>>>> 
>>>> clang `gnustep-config --objc-flags` `gnustep-config --objc-libs` 
>>>> -fobjc-runtime=gnustep -fblocks -lobjc -fobjc-arc -ldispatch 
>>>> -lgnustep-base -lgnustep-gui guitest.m
>>>> 
>>>> But iif I use the following makefile to compile it (given in the wiki 
>>>> also), running GUItest.app will segfault :
>>>> 
>>>> GNUmakefile :
>>>> include \$(GNUSTEP_MAKEFILES)/common.make
>>>> 
>>>> APP_NAME = GUITest
>>>> GUITest_OBJC_FILES = guitest.m
>>>> 
>>>> include \$(GNUSTEP_MAKEFILES)/application.make
>>>> 
>>>> 
>>>> GUItest.app segfaults with this :
>>>> 
>>>> Program received signal SIGSEGV, Segmentation fault.
>>>> 
>>>> 0x00007ffff63cc500 in objc_msgSend_fpret ()
>>>> 
>>>> Backtrace attached.
>>>> 
>>>> Then every compilation of a program (projectcenter, gorm etc) fails.
>>>> 
>>>> I'm stuck.
>>>> 
>>>> I've attached my installation scripts again and the backtrace to this mail.
>>>> 
>>>> There seems to be some problem with the compilation options in my setup. 
>>>> This is way beyond my skills.
>>>> 
>>>> Cheers, Bertrand Dekoninck.
>>>> 
>>>> <my_install_gnustep_first_stage.sh><my_install_gnustep_second_stage.sh><backtrace.txt>_______________________________________________
>>>> Discuss-gnustep mailing list
>>>> Discuss-gnustep@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
>> 
>> 
> 
> _______________________________________________
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev