> On 13 Apr 2018, at 00:31, Riccardo Mottola <riccardo.mott...@libero.it> 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. _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev