From: Christian Johansson <christian@cvj.se>
To: Alan Third <alan@idiocy.org>
Cc: 39343@debbugs.gnu.org
Subject: bug#39343: 27.0.50; Thrad signal crashes Emacs with sgmentation fault
Date: Wed, 29 Jan 2020 22:05:57 +0100 [thread overview]
Message-ID: <7315DC66-E8E5-4876-9BE0-F9FDC1EC3D78@cvj.se> (raw)
In-Reply-To: <20200129204234.GB60190@breton.holly.idiocy.org>
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@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
next prev parent reply other threads:[~2020-01-29 21:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-29 11:27 bug#39343: 27.0.50; Thrad signal crashes Emacs with sgmentation fault Christian Johansson
2020-01-29 20:42 ` Alan Third
2020-01-29 21:05 ` Christian Johansson [this message]
2021-10-20 3:05 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-10-20 20:43 ` NS port thread problems Alan Third
2021-10-21 0:35 ` Po Lu
2021-10-23 10:27 ` Alan Third
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7315DC66-E8E5-4876-9BE0-F9FDC1EC3D78@cvj.se \
--to=christian@cvj.se \
--cc=39343@debbugs.gnu.org \
--cc=alan@idiocy.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.