On Mon, Jun 12, 2017 at 09:32:21PM +0200, Charles A. Roelli wrote:
The issue seems to be improved now (not sure what changed it).
I tried this sample code, and it worked without a crash:
(dotimes (i 100)
(make-thread (lambda () "string")))
Then I tried this code, and there's a crash every few runs (or
sometimes, an infinite loop that can't be exited without killing the
process). The crash normally happens when I supply input (via the
keyboard), and the loop seems to be happen randomly.
(make-thread (lambda ()
(dotimes (i 10)
(sit-for 1)
(goto-char (random (buffer-size))))))
I went back and noticed an approach Eli suggested that I had given up
on, but understood this time round.
I’ve attached a patch that seems to not crash. It introduces a warning
or two, and test/src/thread-tests.el randomly fails up to two tests,
but no crashes afaics.
I also noticed GDB's I/O buffer printing many of these warnings as
soon as the `make-thread' form was called:
2017-06-12 21:13:55.943 Emacs[10829:6683] *** __NSAutoreleaseNoPool():
Object 0x10216bf50 of class NSBezierPath autoreleased with no pool in place
- just leaking
2017-06-12 21:13:55.944 Emacs[10829:6683] *** __NSAutoreleaseNoPool():
Object 0x101ec41b0 of class NSBezierPath autoreleased with no pool in place
- just leaking
2017-06-12 21:13:56.443 Emacs[10829:6683] *** __NSAutoreleaseNoPool():
Object 0x10216c0f0 of class NSBezierPath autoreleased with no pool in place
- just leaking
2017-06-12 21:13:56.444 Emacs[10829:6683] *** __NSAutoreleaseNoPool():
Object 0x101ec43e0 of class NSBezierPath autoreleased with no pool in place
- just leaking
It must be a sub‐thread running some objective c code without an
autorelease pool. It would be nice to be able to work out where that’s
happening. Perhaps threads will need to define an autorelease pool on
creation, and drain it on ending...