Re: Segmentation Faults - OpenBSD

[Richard Frith-Macdonald]

> On 13 Apr 2018, at 00:31, Riccardo Mottola <address@hidden> wrote:
> 
> Hi,
> 
> Richard just commited some promising fixes.
> 
> Things seem better, but not stable. Here a summary of the current status. 
> OpenBSD seems fine on x86, on amd64 I get some strange issues that might not 
> be related
> 
> FreeBSD/amd64/clang
> - seems to work with all apps I tried
> - One test failure:
> base/NSException/basic.m:
> Failed test:     basic.m:51 ... addresses and symbols match

Pretty harmles ... the system doesn't have the code needed to generate 
backtrace symbols.  I've added a change to report the addresses an the fact 
that symbols are not available ... it'll stop the test complaining.

> OpenBSD/i386/gcc
> - seems to work fine
> - Two test failures
> base/NSException/basic.m:
> Failed test:     basic.m:51 ... addresses and symbols match
> base/NSProcessInfo/general.m:
> Failed test:     general.m:48 ... -systemUptime works

That looks like simple missing information (we lack system specific code to get 
the information), and has presumably never passed on that platform.

> NetBSD/amd64/gcc
> things mostly work, but apps spit out an incredible number of errors, like 
> below:
> 
> 2018-04-13 01:03:53.147 Ink[6322:126204759418048] autorelease called without 
> pool for object (0x72c8521602f0) of class GSDictionary in thread <NSThread: 
> 0x72c855daa4c0>{name = (null), num = 126204759418048}
> 2018-04-13 01:03:53.147 Ink[6322:126204759418048] autorelease called without 
> pool for object (0x72c852161c60) of class GSNotification in thread <NSThread: 
> 0x72c855daa4c0>{name = (null), num = 126204759418048}
> 2018-04-13 01:03:53.147 Ink[6322:126204759418048] autorelease called without 
> pool for object (0x72c854dfed90) of class NSFont in thread <NSThread: 
> 0x72c855daa4c0>{name = (null), num = 126204759418048}
> 2018-04-13 01:03:53.147 Ink[6322:126204759418048] autorelease called without 
> pool for object (0x72c854dfe790) of class NSFont in thread <NSThread: 
> 0x72c855daa4c0>{name = (null), num = 126204759418048}

It would be good to know why this system doesn't have an autorelease pool in 
place when others do.  You could try setting a breakpoint where this is logged 
and looking at the stacktrace to see how that point in the code was reached.

> NetBSD/i386/gcc
> plmerge "works" however all gui apps crash

This is the only one that looks really concerning.  The log doesn't report the 
reason for the crash, but it appears to be in the pthread library code ... 
suggesting some form of memory corruption or perhaps linking issue.  You might 
try running under valgrind to see if that gives any clues.