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

[Richard Frith-Macdonald]

> On 21 Dec 2017, at 23:01, Ivan Vučica <ivan@vucica.net> wrote:
> 
> On Thu, Dec 21, 2017 at 7:53 PM, Richard Frith-Macdonald 
> <richard.frith-macdonald@theengagehub.com> wrote:
> >>> gnustep-make has been using -fobjc-runtime= rather than 
> >>> -fobjc-nonfragile-abi for quita long time, but I just found that the 
> >>> gnustep-base configure script was still adding the obsolete 
> >>> -fobjc-nonfragile-abi flag when building nonfragile
> >>> I've just removed that addition of  -fobjc-nonfragile-abi from the 
> >>> current gnustep-base in git, so if gnustep is built for the new runtime 
> >>> with clang (the ng-gnu-gnu library combo) neither make nor base should 
> >>> add ther old flag.
> >>>
> >>
> >>   Just tried the Ubuntu script from the wiki on a clean, up-to-date Ubuntu 
> >> 16.04 VM (32bit), but changed the script to use the current gnustep-make 
> >> instead of the old version (removed the workaround for the ivar-offset 
> >> issue). Gnustep-base now fails to build, with the following error(s):
> >>
> >> Compiling file GSConcreteValue.m ...
> >> In file included from In file included from In file included from 
> >> GSBlocks.m:23:
> >> In file included from ../Headers/Foundation/NSObject.h:30:
> >> In file included from ../Headers/Foundation/NSObjCRuntime.h:38:
> >> ../Headers/GNUstepBase/GSVersionMacros.h:290:10: error: "You are building 
> >> gnustep-base using the objc-nonfragile-abi but your
> >>      gnustep-base was not configured to use it."
> >> #        error "You are building gnustep-base using the 
> >> objc-nonfragile-abi but your gnustep-base was not configured to use it."
> >
> > That would seem to suggest you have gnustep-make trying to use clang and 
> > the new runtime but gnustep-base expecting to use gcc and the gnu runtime.
> > Could it be that you forgot to set the library combo for the modern 
> > compiler/runtime rather than the traditional one?
> > The gnustep-base configure script should recognise the library combo (from 
> > the environment or from gnustep-make) when figuring out how to configure 
> > itself;
> > traditional (gnu runtime in the library combo) implies traditional abi
> > modern, next-generation (ng runtime in the library combo) implies the 
> > nonfragile abi
> 
> I am able to reproduce this on clang 3.8.0, using latest versions of 
> everything from Git.
> 
> Steps:
> - libobjc2 configured with cmake -DCMAKE_INSTALL_PREFIX=/GNUstep ..
>   - for some reason that now ends up in 
> /GNUstep/Local/Library/{Headers,Libraries} instead of /GNUstep/include and 
> /GNUstep/lib like it did when I wrote my old scripts for building everything 
> from scratch; either way I now need to teach the rest of the environment how 
> to find it
> 
> - export CFLAGS=-I/GNUstep/Local/Library/Headers 
> CXXFLAGS=-I/GNUstep/Local/Library/Headers 
> OBJCFLAGS=-I/GNUstep/Local/Library/Headers 
> LDFLAGS=-L/GNUstep/Local/Library/Libraries 
> LD_LIBRARY_PATH=-L/GNUstep/Local/Library/Libraries:$LD_LIBRARY_PATH
> 
> - configure make with: CC=clang CXX=clang++ OBJC=clang ./configure  
> --with-layout=gnustep --enable-debug-by-default 
> --with-library-combo=ng-gnu-gnu --prefix=/GNUstep 
> --with-config-file=/etc/GNUstep/GNUstep.conf
>   - my understanding is that ng-gnu-gnu should correctly use the nonfragile 
> abi, that it should disable mixed abi and all else, so I omitted all that
> 
> - install base into system domain after configuring it with: ./configure 
> --with-ffi-include=/usr/include/`gcc -dumpmachine`
> 
> - install gui into system domain after configuring it with: ./configure 
> --disable-cups
> 
> - install back into system domain after configuring it with: ./configure 
> --enable-graphics=cairo
> 
> A bunch of -gui tests fail, and Zcode is failing to start with identical 
> backtrace.
> 
> Sample -base build command:
> clang NSPropertyList+GNUstepBase.m -c \
>       -MMD -MP -Wall -Wdeclaration-after-statement -DNO_GNUSTEP=1 -DGNUSTEP 
> -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNUSTEP_RUNTIME=1 
> -D_NONFRAGILE_ABI=1 -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing 
> -fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS -pthread -fPIC -g 
> -DDEBUG -fno-omit-frame-pointer -Wall -DGSWARN -DGSDIAGNOSE -Wno-import 
> -I/GNUstep/Local/Library/Headers -I/GNUstep/Local/Library/Headers 
> -I/GNUstep/Local/Library/Headers -fobjc-runtime=gnustep-1.8 -fblocks 
> -fconstant-string-class=NSConstantString -I../. -I../ -I../../Headers -I. 
> -I/home/ivucica/GNUstep/Library/Headers -I/GNUstep/Local/Library/Headers 
> -I/GNUstep/System/Library/Headers -I/GNUstep/Local/Library/Headers 
> -I/GNUstep/Local/Library/Headers -I/GNUstep/System/Library/Headers 
> -I/GNUstep/Local/Library/Headers -I/usr/include/x86_64-linux-gnu 
> -I/usr/include/libxml2 -I/usr/include/p11-kit-1 \
>        -o obj/Additions.obj/NSPropertyList+GNUstepBase.m.o
> 
> Sample -gui build command:
> clang NSAlert.m -c \
>       -MMD -MP -DGNUSTEP_TARGET_DIR=\".\" -DGNUSTEP_TARGET_CPU=\"x86_64\" 
> -DGNUSTEP_TARGET_OS=\"linux-gnu\" -DLIBRARY_COMBO=\"ng-gnu-gnu\" 
> -DGNUSTEP_BASE_HAVE_LIBXML=1 -DBACKEND_BUNDLE=1 -DGNUSTEP 
> -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNUSTEP_RUNTIME=1 
> -D_NONFRAGILE_ABI=1 -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing 
> -fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS -pthread -fPIC -g 
> -DDEBUG -fno-omit-frame-pointer -Wall -DGSWARN -DGSDIAGNOSE -Wno-import 
> -I/GNUstep/Local/Library/Headers -I/GNUstep/Local/Library/Headers 
> -fobjc-runtime=gnustep-1.8 -fblocks -Wall 
> -fconstant-string-class=NSConstantString -I../Headers/Additions -I../Headers 
> -I./. -I. -I/home/ivucica/GNUstep/Library/Headers 
> -I/GNUstep/Local/Library/Headers -I/GNUstep/System/Library/Headers 
> -I/usr/include/libpng12 \
>        -o obj/libgnustep-gui.obj/NSAlert.m.o
> 
> Sample -back build command:
> clang CairoSurface.m -c \
>       -MMD -MP -Wall -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 
> -DGNUSTEP_RUNTIME=1 -D_NONFRAGILE_ABI=1 -GNUSTEP_BASE_LIBRARY=1 
> -fno-strict-aliasing -fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS 
> -pthread -fPIC -g -DDEBUG -fno-omit-frame-pointer -Wall -DGSWARN -DGSDIAGNOSE 
> -Wno-import -I/GNUstep/Local/Library/Headers -I/GNUstep/Local/Library/Headers 
> -fobjc-runtime=gnustep-1.8 -fblocks -fconstant-string-class=NSConstantString 
> -I../../Headers -I../. -I/usr/include/cairo -I/usr/include/glib-2.0 
> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 
> -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/freetype2 
> -I/usr/include/cairo -I/usr/include/glib-2.0 
> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 
> -I/usr/include/freetype2 -I/usr/include/libpng12 -I. 
> -I/home/ivucica/GNUstep/Library/Headers -I/GNUstep/Local/Library/Headers 
> -I/GNUstep/System/Library/Headers \
>        -o obj/cairo.obj/CairoSurface.m.o
> 
> Sample zcode build command:
> clang IDE/ZCPBXTargetList+ViewRelated.m -c \
>       -MMD -MP -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 
> -DGNUSTEP_RUNTIME=1 -D_NONFRAGILE_ABI=1 -DGNUSTEP_BASE_LIBRARY=1 
> -fno-strict-aliasing -fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS 
> -pthread -fPIC -g -DDEBUG -fno-omit-frame-pointer -Wall -DGSWARN -DGSDIAGNOSE 
> -Wno-import -I/GNUstep/Local/Library/Headers -I/GNUstep/Local/Library/Headers 
> -fobjc-runtime=gnustep-1.8 -fblocks -g3 -O0 -Wno-deprecated-declarations 
> -fconstant-string-class=NSConstantString -IPBXProjLib -I. -IIDE -IPlugins 
> -IBuilder -I/usr/lib/gcc/x86_64-linux-gnu/5/include -I. 
> -I/home/ivucica/GNUstep/Library/Headers -I/GNUstep/Local/Library/Headers 
> -I/GNUstep/System/Library/Headers \
>        -o obj/Zcode.obj/IDE/ZCPBXTargetList+ViewRelated.m.o
> 
> As far as I can tell, all the important flags have propagated from -make and 
> do match. Or are they? What am I missing?

I have just confirmed that with a similar test on CentOS-7 64bit using clang 
version 3.4.2

My build process, using all latest code from git, was:
export CC=clang
export CXX-clang++
export OBJC=clang

cd gnustep-make
./configure ./configure --with-library-combo=ng-gnu-gnu 
--enable-debug-by-default --prefix=/home/richard/gnustep-ng 
--with-layout=gnustep
make install
. /home/richard/gnustep-ng/System/Library/Makefiles/GNUstep.sh

cd ../libobjcd2
mkdir Build
cd Build
cmake ..
make -j8
make install

cd ../gnustep-base
./configure
make install

cd ../gnustel-gui --disable-cups
./configure
make install

# at this point the build wouldfail with: /usr/include/cups/cups.h:34:14: fatal 
error: 'dispatch/dispatch.h' file not found
# this seems to be an error in the cups system header, so disabling cups 
support avoides the build failure.

cd ../gnustep-back
./configure
make install


Looking at the failure of a GUI testcase I see the problem is a segmentation 
fault here;

(gdb) where
#0  0x00007ffff60acd10 in objc_msgSend_fpret ()
   from /home/richard/gnustep-ng/Local/Library/Libraries/libobjc.so.4.6
#1  0x00007ffff761271a in +[NSGraphicsContext setCurrentContext:] (
    self=0x7ffff7bd5b20 <_OBJC_CLASS_NSGraphicsContext>, 
    _cmd=0x7ffff7b60040 <.objc_selector_list+1088>, context=0xa17988)
    at NSGraphicsContext.m:169
#2  0x00007ffff7535213 in -[NSApplication _init] (self=0x9b81c8, 
    _cmd=0x7ffff7b60600 <.objc_selector_list+2560>) at NSApplication.m:892
#3  0x00007ffff69259b1 in -[NSObject performSelector:withObject:] (
    self=0x9b81c8, _cmd=0x7ffff6ea3bf0 <.objc_selector_list+128>, 
    aSelector=0x7ffff7b60600 <.objc_selector_list+2560>, anObject=0x9b81c8)
    at NSObject.m:2000

I then checked that both NSThread.m and NSGraphicsContext.m were compiled by 
clang with  -D_NONFRAGILE_ABI=1 and -fobjc-runtime=gnustep-1.8

On a hunch, I looked at the ivar layout in NSThread and swapped the order of 
_gcontext and _autorelease_vars  ... after rebuilding with the id before the 
struct rather than after it, the GUI testcases passed.
Reverting to the original order of ivars and rebuilding again ... the testcases 
failed again.

I think that's a possible indication of a bug in the compiler/runtime 
nonfragile API support;  it looks as if there may be an inconsistency in 
calculating the size of a structure used as an ivar.