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 <thera...@sucs.org> 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 <gnustep_li...@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_li...@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-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 >> >> _______________________________________________ >> Gnustep-dev mailing list >> Gnustep-dev@gnu.org >> https://lists.gnu.org/mailman/listinfo/gnustep-dev > > > _______________________________________________ > 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
