Re: Newbie back again...

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>:
>
> >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 <[hidden email]>:
> >>
> >> 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 can be pretty disastrous. This
>       error is telling you that the gnustep-base library was built using one form of exception handling, but
>       that the gnustep-make package you are using is building code to use the other form of exception handling
>       ... with the consequence that exception handling would be broken in the program you are building. So,
>       somehow your gnustep-base and gnustep-make package are incompatible, and you need to replace one of them
>       with a version configured to match the other."
> #error "There are two separate exception handling mechanisms available ... one based on the standard set...
>  ^
> ../../Headers/Foundation/NSException.h:48:2: error: "gnustep-base is configured to use 'traditional' exceptions,
>       but you are building for 'native' exceptions."
> #error  "gnustep-base is configured to use 'traditional' exceptions, but you are building for 'native' e...
>  ^
>  Compiling file GCObject.m ...
> 2 errors generated.
> make[4]: *** [obj/Additions.obj/GSObjCRuntime.m.o] Error 1
> make[4]: *** Attente des tâches non terminées....
> /usr/GNUstep/System/Library/Makefiles/rules.make:479: recipe for target 'obj/Additions.obj/GSObjCRuntime.m.o' failed
> In file included from GCObject.m:35:
> In file included from ../../Headers/Foundation/NSThread.h:35:
> ../../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 can be pretty disastrous. This
>       error is telling you that the gnustep-base library was built using one form of exception handling, but
>       that the gnustep-make package you are using is building code to use the other form of exception handling
>       ... with the consequence that exception handling would be broken in the program you are building. So,
>       somehow your gnustep-base and gnustep-make package are incompatible, and you need to replace one of them
>       with a version configured to match the other."
> #error "There are two separate exception handling mechanisms available ... one based on the standard set...
>  ^
> ../../Headers/Foundation/NSException.h:48:2: error: "gnustep-base is configured to use 'traditional' exceptions,
>       but you are building for 'native' exceptions."
> #error  "gnustep-base is configured to use 'traditional' exceptions, but you are building for 'native' e...
>  ^
> 2 errors generated.
> make[4]: *** [obj/Additions.obj/GCObject.m.o] Error 1
> /usr/GNUstep/System/Library/Makefiles/rules.make:479: recipe for target 'obj/Additions.obj/GCObject.m.o' failed
> make[3]: *** [internal-subproject-all_] Error 2
> /usr/GNUstep/System/Library/Makefiles/Instance/subproject.make:45: recipe for target 'internal-subproject-all_' failed
> make[2]: *** [Additions.all.subproject.variables] Error 2
> /usr/GNUstep/System/Library/Makefiles/Master/rules.make:297: recipe for target 'Additions.all.subproject.variables' failed
> make[1]: *** [internal-all] Error 2
> /usr/GNUstep/System/Library/Makefiles/Master/serial-subdirectories.make:53: recipe for target 'internal-all' failed
> make: *** [internal-all] Error 2
> /usr/GNUstep/System/Library/Makefiles/Master/serial-subdirectories.make:53: recipe for target 'internal-all' failed
>
> I've compile  and install libobjc2-1.8.x from github/gnustep
> Done the same with libdispatch I've got from the same git repo.
> Done svn co (2 hours ago) for all other modules (base, back, documentation, gui, make & scripts)
>
> I've llvm/clang 3.9 installed, also gcc-4.9 is installed both seems correctly configured and usable since I've been using them for over a year on other projects with no issues...
>
> Hope this helps
> Yan
>
> 2017-04-22 18:16 GMT+02:00 Fred Kiefer <[hidden email]>:
> Hi,
>
> I surely won’t be able to fix all your problem but will try my best to understand what you are doing.
> Let’s start from the end:
>
> > My questions are:
> > Is GNUstep project still alive?
>
> Yes, GNUstep still seems to be alive. There just was a shared release of make, base, gun and back just a few days ago. You find this from the link on our homepage (I must admit I just edited the instruction for the backend, as it was correct, but the comment was out of date)
>
> http://wwwmain.gnustep.org/resources/downloads.php?site=ftp%3A%2F%2Fftp.gnustep.org%2Fpub%2Fgnustep%2F
>
> > Where is the "official repo" from where to get some recently updated/synchronized material to successfully build (for eventually help to debug) the GNUstep Libraries?
>
>
> The "official repo“ i still and has been for many years the SVN on
>
> http://svn.gna.org/viewcvs/gnustep/
>
> As for installation instruction I would use this from the wiki:
>
> http://wiki.gnustep.org/index.php/GNUstep_SVN_Installation_Guide
>
>
> > I've also noticed that there're multiple "official" INSTALL/BUILD instructions files but none none seems to be able acheive its goals at least for me (the real newbie) on my Debian 8 based system (clang3.9/llvm 3.9, libobjc2 & libdispatch other required packages also being installed).
>
> There is nothing bad about having multiple installation instructions. People prefer different tools and therefor may need different instructions. I for example, don’t use clang and could not be able to help you with that.
>
> > After only 3 attempts at building GNUstep from sources, I eventually notice that there're several ways to download the
> > "official" current GNUstep packages/modules whatever we call it: at least svn and git.
> > It seems also that these two spots are not really synchronized, isn't it?
>
> I think for a beginner it would be best not to start of with code that has been officially released. With the current source code there may always be tiny issues, but at the moment release and SVN are almost the same.
> The GIT repository is in synch most of the time, but that synchronisation process may from time to time have problems. We will announce it, when we completely switch over to GIT.
>
> Now to your actual problems:
>
> > Am 22.04.2017 um 16:47 schrieb Yan Le Guen <[hidden email]>:
> >
> > 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.
>
> > 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.
>
> > 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“
>
> This should display the actual line that goes wrong, most likely clang trying to compile its first Objective-C file. Perhaps your system is a bit confused whether it should be using gcc or clang. But this is only guessing.
>
> Hope this helps,
> Fred
>
>
>


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Newbie back again...

Bertrand Dekoninck
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

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev

my_install_gnustep_first_stage.sh (956 bytes) Download Attachment
my_install_gnustep_second_stage.sh (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Newbie back again...

Bertrand Dekoninck
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

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev

my_install_gnustep_first_stage.sh (1010 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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








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
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev

install-current-gnustep-with-gcc.sh (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>:
>
> 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
>> [hidden email]
>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
>
> _______________________________________________
> Gnustep-dev mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/gnustep-dev


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

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








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 <[hidden email]
>> >:
>>
>> 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
>>> [hidden email]
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
>>
>> _______________________________________________
>> Gnustep-dev mailing list
>> [hidden email]
>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
>

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev

install-gnustep-with-clang-from-date.sh (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Newbie back again...

David Chisnall
In reply to this post by Josh Freeman
-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 <[hidden email]> 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 <[hidden email]>:
>>>
>>> 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
>>>> [hidden email]
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
>>>
>>> _______________________________________________
>>> Gnustep-dev mailing list
>>> [hidden email]
>>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>>
>>
>
> _______________________________________________
> Gnustep-dev mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/gnustep-dev


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Newbie back again...

Richard Frith-Macdonald-9

> On 24 Apr 2017, at 08:42, David Chisnall <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Newbie back again...

Patryk Laurent
In reply to this post by David Chisnall
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


On Apr 24, 2017, at 00:42, David Chisnall <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:

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
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev



_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Newbie back again...

Josh Freeman
    To recap: Base & GUI each modify NSThread instance variables  
directly. The expectation is that the layout of NSThread's ivars as  
seen by Base is identical to the layout as seen by GUI.

    However, this expectation is not met if -fobjc-nonfragile-abi is  
added to GNUstep-make's INTERNAL_OBJCFLAGS when compiling with clang  
on Debian-based distros; On the affected distros, Base & GUI compile  
without error, but despite both compiling with the same abi flag  
(nonfragile), at runtime they no longer agree on NSThread's ivar  
layout (NSThread's ivar offset now differs between Base & GUI by 8  
bytes).

    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.

---

    I've attached a zip file with some files that might provide some  
helpful info: install scripts & verbose build outputs (including all  
compiler commands & flags for base, gui, & back) for both working &  
broken versions of gnustep-make. These are from a virtual machine  
(VirtualBox 5.1.22), running a clean, up-to-date install of Ubuntu  
17.04.

gnustep_ubuntu1704_build_output.tar.gz contains 4 files:

1) install_gnustep_ubuntu_original.sh:
    The current version of the "16.04, 16.10, & 17.04" Ubuntu build  
script found at http://wiki.gnustep.org/index.php/GNUstep_under_Ubuntu_Linux 
  (this wasn't run, just used as the starting point for  
install_gnustep_ubuntu_modified.sh)

2) install_gnustep_ubuntu_modified.sh:
    This script generated the build output files (sudo prompts were  
manually removed from the output). Modifications from the original  
script:
* Changed values of APPS & PROMPT vars from true to false (don't build  
apps, don't require <RET> after each build phase)
* 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)
* Added prompt to choose gnustep-make version: new (broken) version  
(2017-04-08), or old version (2017-04-06)
* Makes base, gui, & back using `make SHELL='sh -x'` command, so the  
compiler commands are written to the output
* Added a gui make check at the end (fails on gnustep-make 2017-04-08,  
succeeds on gnustep-make 2017-04-06)
    The script was run until the gnustep-make prompt (after build  
dependencies are installed) - a VM snapshot was taken, then the build  
continued with the first (working) make-version (2017-04-06). The  
second version (2017-04-08) was built by restoring the VM to the make-
version-prompt snapshot of the first build, then continuing after  
choosing the prompt's other option (so all installed packages &  
sources were identical between both runs).

3) gnustep_build_output_with_make_2017-04-06.txt:
    Build output of a successful build, with gnustep-make from Apr. 6th.

4) gnustep_build_output_with_make_2017-04-08.txt
    Build output of a broken build, with gnustep-make from Apr. 8th.


SHA1(gnustep_ubuntu1704_build_output.tar.gz)=  
1f4053e86233eb577ae39e927fddf66a39064ecf


Cheers,

Josh







On Jun 19, 2017, at 1:27 AM, Patryk Laurent wrote:

> 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 <[hidden email]> 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 <[hidden email]
>>> > 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 <[hidden email]
>>>>> >:
>>>>>
>>>>> 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
>>>>>> [hidden email]
>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
>>>>>
>>>>> _______________________________________________
>>>>> Gnustep-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Gnustep-dev mailing list
>>> [hidden email]
>>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>>
>>
>> _______________________________________________
>> Discuss-gnustep mailing list
>> [hidden email]
>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev

gnustep_ubuntu1704_build_output.tar.gz (131K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Newbie back again...

Josh Freeman

On Jun 20, 2017, at 5:30 AM, David Chisnall wrote:

> On 19 Jun 2017, at 23:43, Josh Freeman  
> <[hidden email]> 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?
    Both Base's & GUI's sources are compiled with -fobjc-nonfragile-
abi; Here are two compile commands from yesterday's build output  
(gnustep-make 2017-04-08):

Base:
+ clang NSThread.m -c -MMD -MP -DGNUSTEP_TARGET_DIR="." -
DGNUSTEP_TARGET_CPU="ix86" -DGNUSTEP_TARGET_OS="linux-gnu" -
DGNUSTEP_IS_FLATTENED="yes" -DLIBRARY_COMBO="gnu-gnu-gnu" -
DGNUSTEP_BASE_INTERNAL=1 -Wall -Wdeclaration-after-statement -Wcast-
align -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_RUNTIME=1 -
DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -fexceptions -fobjc-
exceptions -D_NATIVE_OBJC_EXCEPTIONS -fobjc-nonfragile-abi -
D_NONFRAGILE_ABI -pthread -fPIC -DDEBUG -fno-omit-frame-pointer -Wall -
DGSWARN -DGSDIAGNOSE -Wno-import -g -fgnu-runtime -fgnu-runtime -
fconstant-string-class=NSConstantString -I../Headers -I./. -I. -I/home/
josh/GNUstep/Library/Headers -I/usr/GNUstep/Local/Library/Headers -I/
usr/GNUstep/System/Library/Headers -I/usr/GNUstep/Local/Library/
Headers -I/usr/GNUstep/Local/Library/Headers -I/usr/GNUstep/System/
Library/Headers -I/usr/GNUstep/Local/Library/Headers -I/usr/include/
libxml2 -I/usr/include/p11-kit-1 -o obj/libgnustep-base.obj/NSThread.m.o

GUI:
+ clang NSGraphicsContext.m -c -MMD -MP -DGNUSTEP_TARGET_DIR="." -
DGNUSTEP_TARGET_CPU="ix86" -DGNUSTEP_TARGET_OS="linux-gnu" -
DLIBRARY_COMBO="gnu-gnu-gnu" -DGNUSTEP_BASE_HAVE_LIBXML=1 -
DBACKEND_BUNDLE=1 -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -
DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -fno-
strict-aliasing -fexceptions -fobjc-exceptions -
D_NATIVE_OBJC_EXCEPTIONS -fobjc-nonfragile-abi -D_NONFRAGILE_ABI -
pthread -fPIC -DDEBUG -fno-omit-frame-pointer -Wall -DGSWARN -
DGSDIAGNOSE -Wno-import -g -fgnu-runtime -Wall -fconstant-string-
class=NSConstantString -I../Headers/Additions -I../Headers -I./. -I. -
I/home/josh/GNUstep/Library/Headers -I/usr/GNUstep/Local/Library/
Headers -I/usr/GNUstep/System/Library/Headers -I/usr/include/libpng16 -
o obj/libgnustep-gui.obj/NSGraphicsContext.m.o


> 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?


    The attached assembly files were created by building the GS  
frameworks with the --save-temps option added to gnustep-make's  
INTERNAL_OBJCFLAGS.

gs-assembly.tar.gz contains 3 files: NSAutoreleasePool.s,  
NSGraphicsContext.s, NSThread.s

The segmentation fault is the result of two events:
-[NSAutoreleasePool dealloc] in Base gets the address of  
GSCurrentThread()->_autorelease_vars (struct), and passes it through  
several local functions, which overwrite its struct values.
-[NSGraphicsContext setCurrentContext:] in GUI assigns a value to  
GSCurrentThread()->_gcontext (the ivar right after _autorelease_vars),  
and crashes when sending a release message to its previous value.

SHA1(gs-assembly.tar.gz)= a7a4f3c4a0dd45a4c284e29a29d3cd8a03bb2383


Cheers,

Josh







_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev

gs-assembly.tar.gz (279K) Download Attachment