Re: Newbie back again...

[Josh Freeman]

Hi Bertrand,

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

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

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


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

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

   * Where did the 32 come from?

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

   * How does the 32 move from _autorelease_vars to _gcontext?

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

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

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

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

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

Cheers,

Josh

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

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

> Preamble : sorry for the noise on gnustep-dev mailing list. I've  
> reposted the messages here.
>
> And...finally, it still doesn't work.
>
> I thought that the problem had disappeared because I could compile  
> and run a sample 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep