GNU bug report logs - #32812
27.0.50; macOS Mojave GNU Emacs crash after 5-10 minutes or so

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 32812 in the body.
You can then email your comments to 32812 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: "Zack Piper" <zack <at> apertron.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; macOS Mojave GNU Emacs crash after 5-10 minutes or so
Date: Sun, 23 Sep 2018 16:21:13 +0100

[Message part 1 (text/plain, inline)]

Hi!

(Replacing my post in #31904 with this since they're separate issues(?))

I've applied a slightly modified (i.e. updated) version of Alan's patch 
from bug #31904
(attached) to fix an issue concerning the buffer and mode-line not being 
rendered. The patch works great, everything is now rendered.

Now I notice that after 5-10 minutes (or even before), Emacs crashes 
with the below:

```
objc[82784]: Invalid or prematurely-freed autorelease pool 0x1030032e0.
```

This started occurring since upgrading to macOS Mojave, so possibly 
there's a bug with Mojave or just some incompatibility, not really sure!


(I'm hoping I got it compiled with the appropriate parameters for 
debugging)

The crash isn't intermittent, just takes a variable amount of time to 
trigger. It
can trigger regardless of me using Emacs (i.e. typing) or not.

Also worthy to note this happens with the original patch applied to the 
emacs-26 branch.


Below is a backtrace of the issue:

```
objc[95306]: Invalid or prematurely-freed autorelease pool 0x103e60378.
Process 95306 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal 
SIGABRT
    frame #0: 0x00007fff7679b01e 
libsystem_kernel.dylib`__abort_with_payload + 10
libsystem_kernel.dylib`__abort_with_payload:
->  0x7fff7679b01e <+10>: jae    0x7fff7679b028            ; <+20>
    0x7fff7679b020 <+12>: movq   %rax, %rdi
    0x7fff7679b023 <+15>: jmp    0x7fff7677de67            ; 
cerror_nocancel
    0x7fff7679b028 <+20>: retq
Target 0: (Emacs) stopped.
(lldb) bt all
* thread #1, queue = 'com.apple.main-thread', stop reason = signal 
SIGABRT
  * frame #0: 0x00007fff7679b01e 
libsystem_kernel.dylib`__abort_with_payload + 10
    frame #1: 0x00007fff76796561 
libsystem_kernel.dylib`abort_with_payload_wrapper_internal + 82
    frame #2: 0x00007fff7679650f 
libsystem_kernel.dylib`abort_with_reason + 22
    frame #3: 0x00007fff75579674 libobjc.A.dylib`_objc_fatalv(unsigned 
long long, unsigned long long, char const*, __va_list_tag*) + 108
    frame #4: 0x00007fff75579526 libobjc.A.dylib`_objc_fatal(char 
const*, ...) + 135
    frame #5: 0x00007fff7556bd73 libobjc.A.dylib`(anonymous 
namespace)::AutoreleasePoolPage::pop(void*) + 957
    frame #6: 0x00007fff46c2d232 AppKit`-[NSView(NSInternal) 
_recursive:displayRectIgnoringOpacity:inContext:shouldChangeFontReferenceColor:stopAtLayerBackedViews:] 
+ 3454
    frame #7: 0x00007fff46c2c4a2 AppKit`__46-[NSView(NSLayerKitGlue) 
drawLayer:inContext:]_block_invoke + 192
    frame #8: 0x00007fff46c2c201 AppKit`-[NSView(NSLayerKitGlue) 
_drawViewBackingLayer:inContext:drawingHandler:] + 1769
    frame #9: 0x00007fff54540aaf QuartzCore`CABackingStoreUpdate_ + 577
    frame #10: 0x00007fff545a2325 
QuartzCore`___ZN2CA5Layer8display_Ev_block_invoke + 53
    frame #11: 0x00007fff5453fc90 QuartzCore`-[CALayer _display] + 1839
    frame #12: 0x00007fff46c2b75a AppKit`_NSBackingLayerDisplay + 531
    frame #13: 0x00007fff46c0fcc9 AppKit`-[_NSViewBackingLayer display] 
+ 811
    frame #14: 0x00007fff46c0f949 AppKit`_NSBackingLayerDisplayIfNeeded 
+ 40
    frame #15: 0x00007fff46c0f2a4 AppKit`-[NSView displayIfNeeded] + 
130
    frame #16: 0x0000000100026514 Emacs`echo_area_display + 593
    frame #17: 0x00000001000261ca Emacs`message3_nolog + 393
    frame #18: 0x0000000100025fe3 Emacs`message3 + 399
    frame #19: 0x0000000100106a03 Emacs`Fmessage + 67
    frame #20: 0x000000010010f525 Emacs`Ffuncall + 665
    frame #21: 0x0000000100145e02 Emacs`exec_byte_code + 1486
    frame #22: 0x0000000100110040 Emacs`funcall_lambda + 648
    frame #23: 0x000000010010f4c2 Emacs`Ffuncall + 566
    frame #24: 0x000000010010f704 Emacs`funcall_nil + 9
    frame #25: 0x000000010010f6a0 Emacs`run_hook_with_args + 198
    frame #26: 0x000000010010f58b Emacs`Frun_hooks + 60
    frame #27: 0x000000010010f525 Emacs`Ffuncall + 665
    frame #28: 0x0000000100145e02 Emacs`exec_byte_code + 1486
    frame #29: 0x000000010010f4c2 Emacs`Ffuncall + 566
    frame #30: 0x0000000100145e02 Emacs`exec_byte_code + 1486
    frame #31: 0x000000010010f4c2 Emacs`Ffuncall + 566
    frame #32: 0x0000000100145e02 Emacs`exec_byte_code + 1486
    frame #33: 0x000000010010f4c2 Emacs`Ffuncall + 566
    frame #34: 0x0000000100145e02 Emacs`exec_byte_code + 1486
    frame #35: 0x000000010010f4c2 Emacs`Ffuncall + 566
    frame #36: 0x0000000100145e02 Emacs`exec_byte_code + 1486
    frame #37: 0x000000010010f4c2 Emacs`Ffuncall + 566
    frame #38: 0x0000000100145e02 Emacs`exec_byte_code + 1486
    frame #39: 0x000000010010ee62 Emacs`apply_lambda + 369
    frame #40: 0x000000010010c484 Emacs`eval_sub + 845
    frame #41: 0x000000010012d294 Emacs`readevalloop + 1773
    frame #42: 0x000000010012d502 Emacs`Feval_buffer + 368
    frame #43: 0x000000010010fcfe Emacs`funcall_subr + 367
    frame #44: 0x000000010010f525 Emacs`Ffuncall + 665
    frame #45: 0x0000000100145e02 Emacs`exec_byte_code + 1486
    frame #46: 0x0000000100110040 Emacs`funcall_lambda + 648
    frame #47: 0x000000010010f4c2 Emacs`Ffuncall + 566
    frame #48: 0x000000010010f9d1 Emacs`call4 + 58
    frame #49: 0x000000010012b845 Emacs`Fload + 1373
    frame #50: 0x000000010010fcfe Emacs`funcall_subr + 367
    frame #51: 0x000000010010f525 Emacs`Ffuncall + 665
    frame #52: 0x0000000100145e02 Emacs`exec_byte_code + 1486
    frame #53: 0x000000010010f4c2 Emacs`Ffuncall + 566
    frame #54: 0x0000000100145e02 Emacs`exec_byte_code + 1486
    frame #55: 0x000000010010f4c2 Emacs`Ffuncall + 566
    frame #56: 0x0000000100145e02 Emacs`exec_byte_code + 1486
    frame #57: 0x000000010010ee62 Emacs`apply_lambda + 369
    frame #58: 0x000000010010c484 Emacs`eval_sub + 845
    frame #59: 0x000000010010ec69 Emacs`Feval + 96
    frame #60: 0x000000010010dffd Emacs`internal_condition_case + 87
    frame #61: 0x00000001000b17be Emacs`top_level_1 + 45
    frame #62: 0x000000010010db85 Emacs`internal_catch + 74
    frame #63: 0x00000001000a4a90 Emacs`command_loop + 141
    frame #64: 0x00000001000a49c1 Emacs`recursive_edit_1 + 115
    frame #65: 0x00000001000a4bdd Emacs`Frecursive_edit + 226
    frame #66: 0x00000001000a3aa9 Emacs`main + 5211
    frame #67: 0x00007fff76645085 libdyld.dylib`start + 1
    frame #68: 0x00007fff76645085 libdyld.dylib`start + 1
  thread #2
    frame #0: 0x00007fff7677f5be 
libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x6874656d00000000
    frame #2: 0x00007fff76836415 libsystem_pthread.dylib`start_wqthread 
+ 13
  thread #3
    frame #0: 0x00007fff7677f5be 
libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x00007fff76836641 
libsystem_pthread.dylib`_pthread_wqthread + 446
    frame #2: 0x00007fff76836415 libsystem_pthread.dylib`start_wqthread 
+ 13
  thread #4, name = 'gmain'
    frame #0: 0x00007fff76784e82 libsystem_kernel.dylib`__select + 10
    frame #1: 0x0000000100a083da libglib-2.0.0.dylib`g_poll + 405
    frame #2: 0x00000001009fc123 
libglib-2.0.0.dylib`g_main_context_iterate + 340
    frame #3: 0x00000001009fc1d1 
libglib-2.0.0.dylib`g_main_context_iteration + 55
    frame #4: 0x00000001009fd2b0 libglib-2.0.0.dylib`glib_worker_main + 
30
    frame #5: 0x0000000100a1dcb7 libglib-2.0.0.dylib`g_thread_proxy + 
90
    frame #6: 0x00007fff7683733d libsystem_pthread.dylib`_pthread_body 
+ 126
    frame #7: 0x00007fff7683a2a7 libsystem_pthread.dylib`_pthread_start 
+ 70
    frame #8: 0x00007fff76836425 libsystem_pthread.dylib`thread_start + 
13
  thread #5
    frame #0: 0x00007fff7677f5be 
libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x00007fff76836721 
libsystem_pthread.dylib`_pthread_wqthread + 670
    frame #2: 0x00007fff76836415 libsystem_pthread.dylib`start_wqthread 
+ 13
  thread #7
    frame #0: 0x00007fff76784e82 libsystem_kernel.dylib`__select + 10
    frame #1: 0x000000010017c408 Emacs`-[EmacsApp fd_handler:] + 214
    frame #2: 0x00007fff4b902234 Foundation`__NSThread__start__ + 1218
    frame #3: 0x00007fff7683733d libsystem_pthread.dylib`_pthread_body 
+ 126
    frame #4: 0x00007fff7683a2a7 libsystem_pthread.dylib`_pthread_start 
+ 70
    frame #5: 0x00007fff76836425 libsystem_pthread.dylib`thread_start + 
13
  thread #9, name = 'com.apple.NSEventThread'
    frame #0: 0x00007fff7677dc2a libsystem_kernel.dylib`mach_msg_trap + 
10
    frame #1: 0x00007fff7677e174 libsystem_kernel.dylib`mach_msg + 60
    frame #2: 0x00007fff495ad05e 
CoreFoundation`__CFRunLoopServiceMachPort + 337
    frame #3: 0x00007fff495ac5ad CoreFoundation`__CFRunLoopRun + 1654
    frame #4: 0x00007fff495abce4 CoreFoundation`CFRunLoopRunSpecific + 
463
    frame #5: 0x00007fff46b0b581 AppKit`_NSEventThread + 160
    frame #6: 0x00007fff7683733d libsystem_pthread.dylib`_pthread_body 
+ 126
    frame #7: 0x00007fff7683a2a7 libsystem_pthread.dylib`_pthread_start 
+ 70
    frame #8: 0x00007fff76836425 libsystem_pthread.dylib`thread_start + 
13
(lldb)
```






In GNU Emacs 27.0.50 (build 1, x86_64-apple-darwin18.0.0, NS 
appkit-1671.00 Version 10.14 (Build 18A389))
 of 2018-09-19 built on zoral
Repository revision: 75d9a55fae1c484aa6d213064931bfe3b65cf5dd
Windowing system distributor 'Apple', version 10.3.1671
System Description:  Mac OS X 10.14

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --disable-dependency-tracking --disable-silent-rules
 --enable-locallisppath=/usr/local/share/emacs/site-lisp
 --enable-check-lisp-object-type
 --infodir=/usr/local/Cellar/emacs-plus/HEAD-75d9a55/share/info/emacs
 --prefix=/usr/local/Cellar/emacs-plus/HEAD-75d9a55 --with-xml2
 --without-dbus --with-gnutls --with-imagemagick --with-modules
 --with-rsvg --with-ns --disable-ns-self-contained 'CFLAGS=-O0 -g3''

Configured features:
RSVG IMAGEMAGICK GLIB NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS
NS MODULES THREADS LCMS2 GMP

Important settings:
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv dired dired-loaddefs format-spec rfc822 mml
easymenu mml-sec password-cache epa derived epg epg-config gnus-util
rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/ns-win ns-win ucs-normalize mule-util term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core term/tty-colors frame cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads kqueue cocoa ns
lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 204840 9831)
 (symbols 48 20275 1)
 (strings 32 29150 2191)
 (string-bytes 1 776518)
 (vectors 16 35468)
 (vector-slots 8 735114 19448)
 (floats 8 46 70)
 (intervals 56 229 0)
 (buffers 992 12))

[Message part 2 (text/html, inline)]

[0001-nsterm.m.patch (text/plain, attachment)]

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

From: Alan Third <alan <at> idiocy.org>
To: Zack Piper <zack <at> apertron.com>
Cc: 32812 <at> debbugs.gnu.org
Subject: Re: bug#32812: 27.0.50; macOS Mojave GNU Emacs crash after 5-10
 minutes or so
Date: Mon, 24 Sep 2018 11:17:06 +0100

[Message part 1 (text/plain, inline)]

On Sun, Sep 23, 2018 at 04:21:13PM +0100, Zack Piper wrote:
> Hi!
> 
> (Replacing my post in #31904 with this since they're separate issues(?))

Sorry, I somehow missed that previous email.

> I've applied a slightly modified (i.e. updated) version of Alan's patch from
> bug #31904
> (attached) to fix an issue concerning the buffer and mode-line not being
> rendered. The patch works great, everything is now rendered.
> 
> Now I notice that after 5-10 minutes (or even before), Emacs crashes with
> the below:
> 
> ```
> objc[82784]: Invalid or prematurely-freed autorelease pool 0x1030032e0.
> ```
> 
> This started occurring since upgrading to macOS Mojave, so possibly there's
> a bug with Mojave or just some incompatibility, not really sure!

It’s a bit strange looking, and autorelease pools are something of a
mystery to me.

I have a suspicion, though, that just creating a new autorelease pool
may solve this. I’ve attached a patch. It’s for emacs-26, but should
apply OK to master, or without too much work anyway.

It simply wraps the call to displayIfNeeded in a new pool:

static void
ns_flush_display (struct frame *f)
/* Force the frame to redisplay.  If areas have previously been marked
   dirty by setNeedsDisplayInRect (in ns_focus), then this will call
   draw_rect: which will "expose" those areas.  */
{
  NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
  [FRAME_NS_VIEW (f) displayIfNeeded];
  [pool release];
}

Thanks for testing the patch and raising this issue. There’s not been
a lot of feedback so far and I think we’re going to have to commit the
patch soon given that Mojave is out today.
-- 
Alan Third

[0001-Fix-crash-when-flushing-to-screen-bug-32812.patch (text/plain, attachment)]

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

From: Alan Third <alan <at> idiocy.org>
To: Zack Piper <zack <at> apertron.com>
Cc: 32812 <at> debbugs.gnu.org
Subject: Re: bug#32812: 27.0.50; macOS Mojave GNU Emacs crash after 5-10
 minutes or so
Date: Mon, 24 Sep 2018 11:24:33 +0100

On Mon, Sep 24, 2018 at 11:17:06AM +0100, Alan Third wrote:
> 
> It’s a bit strange looking, and autorelease pools are something of a
> mystery to me.
> 
> I have a suspicion, though, that just creating a new autorelease pool
> may solve this. I’ve attached a patch. It’s for emacs-26, but should
> apply OK to master, or without too much work anyway.

This patch doesn’t help, I finally reproduced the crash with it in
place.
-- 
Alan Third

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

From: "Zack Piper" <zack <at> apertron.com>
To: 32812 <at> debbugs.gnu.org
Subject: Re: bug#32812: 27.0.50; macOS Mojave GNU Emacs crash after 5-10
 minutes or so
Date: Mon, 24 Sep 2018 12:39:22 +0100

(Final attempt at sending, TLS was being enforced for my outgoing 
emails, sorry Alan for the spam!)

Hi Alan,


On 24 Sep 2018, at 11:17, Alan Third wrote:

> On Sun, Sep 23, 2018 at 04:21:13PM +0100, Zack Piper wrote:
>> Hi!
>>
>> (Replacing my post in #31904 with this since they're separate 
>> issues(?))
>
> Sorry, I somehow missed that previous email.

No worries at all!


>> I've applied a slightly modified (i.e. updated) version of Alan's 
>> patch from
>> bug #31904
>> (attached) to fix an issue concerning the buffer and mode-line not 
>> being
>> rendered. The patch works great, everything is now rendered.
>>
>> Now I notice that after 5-10 minutes (or even before), Emacs crashes 
>> with
>> the below:
>>
>> ```
>> objc[82784]: Invalid or prematurely-freed autorelease pool 
>> 0x1030032e0.
>> ```
>>
>> This started occurring since upgrading to macOS Mojave, so possibly 
>> there's
>> a bug with Mojave or just some incompatibility, not really sure!
>
> It’s a bit strange looking, and autorelease pools are something of a
> mystery to me.
>
> I have a suspicion, though, that just creating a new autorelease pool
> may solve this. I’ve attached a patch. It’s for emacs-26, but 
> should
> apply OK to master, or without too much work anyway.

>
> It simply wraps the call to displayIfNeeded in a new pool:
>
> static void
> ns_flush_display (struct frame *f)
> /* Force the frame to redisplay.  If areas have previously been marked
>    dirty by setNeedsDisplayInRect (in ns_focus), then this will call
>    draw_rect: which will "expose" those areas.  */
> {
>   NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>   [FRAME_NS_VIEW (f) displayIfNeeded];
>   [pool release];
> }

>
> Thanks for testing the patch and raising this issue. There’s not 
> been
> a lot of feedback so far and I think we’re going to have to commit 
> the
> patch soon given that Mojave is out today.

You're very welcome, and thanks for providing the additional patch!


(Later email):


> This patch doesn’t help, I finally reproduced the crash with it in
> place.

Oh, damn.

I truly wish I could help somewhat, if you need anything additional from 
me let me know.

I've never really meddled Objective C before, so I'd likely not be able 
to help much.

Obviously I'm more than happy to test any patches you throw at me! :-)

I did look at the autorelease pool thing and tried to see where it would 
fit in, to no avail.

Let me know if you need anything.



> -- 
> Alan Third

Thanks,
Zack

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

From: Alan Third <alan <at> idiocy.org>
To: Zack Piper <zack <at> apertron.com>
Cc: 32812 <at> debbugs.gnu.org
Subject: Re: bug#32812: 27.0.50; macOS Mojave GNU Emacs crash after 5-10
 minutes or so
Date: Mon, 24 Sep 2018 14:11:33 +0100

[Message part 1 (text/plain, inline)]

On Mon, Sep 24, 2018 at 12:39:22PM +0100, Zack Piper wrote:
> (Final attempt at sending, TLS was being enforced for my outgoing emails,
> sorry Alan for the spam!)

I think I actually did receive all the emails. No big deal, though.

> > This patch doesn’t help, I finally reproduced the crash with it in
> > place.
> 
> Oh, damn.

I think I’ve got it this time. I haven’t managed to reproduce the
crash, but I may just have been lucky.

> I truly wish I could help somewhat, if you need anything additional from me
> let me know.

That’s OK, just testing the patches is helpful.

-- 
Alan Third

[0001-Fix-crash-on-flush-to-display-bug-32812.patch (text/plain, attachment)]

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

From: "Zack Piper" <zack <at> apertron.com>
To: "Alan Third" <alan <at> idiocy.org>
Cc: 32812 <at> debbugs.gnu.org
Subject: Re: bug#32812: 27.0.50; macOS Mojave GNU Emacs crash after 5-10
 minutes or so
Date: Mon, 24 Sep 2018 15:16:59 +0100

Hi Alan,

On 24 Sep 2018, at 14:11, Alan Third wrote:

> On Mon, Sep 24, 2018 at 12:39:22PM +0100, Zack Piper wrote:
>> (Final attempt at sending, TLS was being enforced for my outgoing 
>> emails,
>> sorry Alan for the spam!)
>
> I think I actually did receive all the emails. No big deal, though.
>

I forgot to take you out of the CC when trying to get the email to go to 
debbugs

Seems debbugs.gnu.org SMTP doesn't offer TLS, according to my mail 
server
at least.

I just disabled the setting to strictly enforce TLS outbound.

>>> This patch doesn’t help, I finally reproduced the crash with it in
>>> place.
>>
>> Oh, damn.
>
> I think I’ve got it this time. I haven’t managed to reproduce the
> crash, but I may just have been lucky.
>

It's been an hour of use and it hasn't crashed. I can't thank you 
enough!

>> I truly wish I could help somewhat, if you need anything additional 
>> from me
>> let me know.
>
> That’s OK, just testing the patches is helpful.
>
> -- 
> Alan Third

Thanks,
Zack

Message #25 received at 32812-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Zack Piper <zack <at> apertron.com>
Cc: 32812-done <at> debbugs.gnu.org
Subject: Re: bug#32812: 27.0.50;
 macOS Mojave GNU Emacs crash after 5-10 minutes or so
Date: Fri, 30 Nov 2018 10:17:02 +0000

Alan Third <alan <at> idiocy.org> writes:

> On Mon, Sep 24, 2018 at 12:39:22PM +0100, Zack Piper wrote:
>> (Final attempt at sending, TLS was being enforced for my outgoing emails,
>> sorry Alan for the spam!)
>
> I think I actually did receive all the emails. No big deal, though.
>
>> > This patch doesn’t help, I finally reproduced the crash with it in
>> > place.
>> 
>> Oh, damn.
>
> I think I’ve got it this time. I haven’t managed to reproduce the
> crash, but I may just have been lucky.
>
>> I truly wish I could help somewhat, if you need anything additional from me
>> let me know.
>
> That’s OK, just testing the patches is helpful.

The code that was causing this crash has been completely removed now, so
I'm closing this bug report.
-- 
Alan Third

Previous Next

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