bug#25265: make-thread crashes in OS X 10.6

["Charles A. Roelli" <charles@aurox.ch>]

Well done, it works here without a crash.

I ran all the tests and 'thread-tests.el' passed.  But I couldn't find
how to rerun it.  What command did you use?


On 13/06/2017 22:46, Alan Third wrote:
> 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...