GNU bug report logs - #39343
27.0.50; Thrad signal crashes Emacs with sgmentation fault

Previous Next

Full log

Message #11 received at 39343 <at> debbugs.gnu.org (full text, mbox):

From: Christian Johansson <christian <at> cvj.se>
To: Alan Third <alan <at> idiocy.org>
Cc: 39343 <at> debbugs.gnu.org
Subject: Re: bug#39343: 27.0.50;
 Thrad signal crashes Emacs with sgmentation fault
Date: Wed, 29 Jan 2020 22:05:57 +0100

Hi

I understand, wish I had the skills to help with that but my C is weak and my macOS internals is even weaker.

Sometimes I get another thread issue on macOS. It also crashes Emacs but the error is something about try to clear a pointer that doesn’t point to anything anymore. Would it be helpful if I try to find a reproducable way of causing that and file another issue? It seems to occur non-determinstically so I haven’t been able to reproduce it yet. Could perhaps depend on garbage collector and maybe some kind of race-condition..

I have two plugins for Emacs that would improve significantly with stable thread support but at the moment it seems threads are unstable on macOS. I have not experienced any issues on Linux. Async.el works but it adds unecessary overhead by launching a separate Emacs process and it would be nice to not need it.

Kind regards
Christian

> 29 jan. 2020 kl. 21:42 skrev Alan Third <alan <at> idiocy.org>:
> 
>> On Wed, Jan 29, 2020 at 12:27:19PM +0100, Christian Johansson wrote:
>> Running following works on Linux but not on macOS.
>> 
>> (let ((loop t)
>>       (iterations 1))
>>   (while loop
>>     (make-thread
>>      (lambda()
>>        (message "Thread %d" iterations)
>>        (signal 'error (list "My error"))))
>>     (setq iterations (1+ iterations))))
>> 
>> Error in console: Fatal error 11: Segmentation faultAbort trap: 6
>> 
>> It seems to be some kind of issue with quitting threads on macOS which is
>> not present on Linux
> 
> It’s a stack overflow caused by the main thread getting stuck in a
> loop processing calls to ns_send_appdefined which must be coming from
> the 2000‐odd threads the script starts.
> 
> Presumably it’s the call to ns_run_loop_break in sys_cond_broadcast
> that’s doing it.
> 
> I don’t think there’s really any way round this other than the massive
> rewrite the NS port needs to make it handle threads correctly.
> 
> -- 
> Alan Third

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.