bug#23462: 25.0.93; Crash on OS X when suspending main frame

bug#23462: 25.0.93; Crash on OS X when suspending main frame

[Ivan Cibrario Bertolotti]

Emacs crashes when using the suspend-frame command (bound
to C-z by default) on the main frame.  It works correctly when the frame
is minimized by clicking on the GUI button.

Recipe: Start emacs -Q; type C-z; Emacs crashes with:
Fatal error 11: Segmentation faultAbort trap: 6

Partial crash dump from OS X console follows.  Please let me know if I can
be of further assistance.

Thanks in advance and best regards,
ICB


Process:               Emacs-x86_64-10_9 [11397]
Path:                  /Users/USER/*/Emacs.app/Contents/MacOS/Emacs-x86_64-10_9
Identifier:            org.gnu.Emacs
Version:               Version 25.0.93 (9.0)
Code Type:             X86-64 (Native)
Parent Process:        bash [6662]
Responsible:           Terminal [319]
User ID:               501

Date/Time:             2016-05-05 23:11:24.931 +0200
OS Version:            Mac OS X 10.11.4 (15E65)
Report Version:        11
Anonymous UUID:        12F2E9FF-07EA-3C6C-2998-78FF89BB8F8C

Sleep/Wake UUID:       C53CD2D3-8D26-403E-BC4F-5F9D2B5AFC48

Time Awake Since Boot: 200000 seconds
Time Since Wake:       5200 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGABRT)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000010

VM Regions Near 0x10:
--> 
    __TEXT                 0000000100000000-000000010020d000 [ 2100K] r-x/rwx SM=COW  /Users/USER/*/Emacs.app/Contents/MacOS/Emacs-x86_64-10_9

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fff8ac5a8ea __kill + 10
1   Emacs-x86_64-10_9             	0x00000001000b9aa0 terminate_due_to_signal + 144
2   Emacs-x86_64-10_9             	0x00000001000d62a3 emacs_abort + 19
3   Emacs-x86_64-10_9             	0x00000001001a61ec ns_term_shutdown + 124
4   Emacs-x86_64-10_9             	0x00000001000b9c65 shut_down_emacs + 261
5   Emacs-x86_64-10_9             	0x00000001000b9a65 terminate_due_to_signal + 85
6   Emacs-x86_64-10_9             	0x00000001000d7be6 deliver_fatal_thread_signal + 134
7   Emacs-x86_64-10_9             	0x00000001000d8936 handle_sigsegv + 150
8   libsystem_platform.dylib      	0x00007fff98d9f52a _sigtramp + 26
9   ???                           	000000000000000000 0 + 0
10  com.apple.QuartzCore          	0x00007fff974c4987 CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 87
11  com.apple.CoreFoundation      	0x00007fff995f2067 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
12  com.apple.CoreFoundation      	0x00007fff995f1fd7 __CFRunLoopDoObservers + 391
13  com.apple.CoreFoundation      	0x00007fff995d0ef8 CFRunLoopRunSpecific + 328
14  com.apple.HIServices          	0x00007fff84c4571e waitForTransaction + 204
15  com.apple.AppKit              	0x00007fff92c12b07 minimizeItemsMaybeBatching + 89
16  com.apple.AppKit              	0x00007fff92c45f29 -[NSWindow(NSWindow_Theme) _minimizeToDock] + 192
17  Emacs-x86_64-10_9             	0x00000001001a267e x_iconify_frame + 430
18  Emacs-x86_64-10_9             	0x0000000100010587 Ficonify_frame + 135
19  Emacs-x86_64-10_9             	0x0000000100139ec8 Ffuncall + 1016
20  Emacs-x86_64-10_9             	0x00000001001720f5 exec_byte_code + 2277
21  Emacs-x86_64-10_9             	0x0000000100139d4f Ffuncall + 639
22  Emacs-x86_64-10_9             	0x00000001001720f5 exec_byte_code + 2277
23  Emacs-x86_64-10_9             	0x0000000100139d4f Ffuncall + 639
24  Emacs-x86_64-10_9             	0x0000000100133faa Ffuncall_interactively + 58
25  Emacs-x86_64-10_9             	0x0000000100139de7 Ffuncall + 791
26  Emacs-x86_64-10_9             	0x00000001001397f8 Fapply + 136
27  Emacs-x86_64-10_9             	0x00000001001347ba Fcall_interactively + 2042
28  Emacs-x86_64-10_9             	0x0000000100139efb Ffuncall + 1067
29  Emacs-x86_64-10_9             	0x00000001001720f5 exec_byte_code + 2277
30  Emacs-x86_64-10_9             	0x0000000100139d4f Ffuncall + 639
31  Emacs-x86_64-10_9             	0x000000010013a57d call1 + 45
32  Emacs-x86_64-10_9             	0x00000001000bd66a command_loop_1 + 1962
33  Emacs-x86_64-10_9             	0x0000000100138946 internal_condition_case + 70
34  Emacs-x86_64-10_9             	0x00000001000cdf60 command_loop_2 + 48
35  Emacs-x86_64-10_9             	0x00000001001384a6 internal_catch + 54
36  Emacs-x86_64-10_9             	0x00000001000bc58e command_loop + 158
37  Emacs-x86_64-10_9             	0x00000001000bc4a9 recursive_edit_1 + 105
38  Emacs-x86_64-10_9             	0x00000001000bc6cc Frecursive_edit + 220
39  Emacs-x86_64-10_9             	0x00000001000bb3ae main + 5854
40  libdyld.dylib                 	0x00007fff85d4a5ad start + 1


In GNU Emacs 25.0.93.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 (Build 13F1603))
of 2016-04-22 built on builder10-9.local
Windowing system distributor 'Apple', version 10.3.1404
Configured using:
'configure --with-ns '--enable-locallisppath=/Library/Application
Support/Emacs/${version}/site-lisp:/Library/Application
Support/Emacs/site-lisp''

Configured features:
NOTIFY ACL LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS

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

Major mode: Emacs-Lisp

Minor modes in effect:
  type-break-mode: t
  show-paren-mode: t
  recentf-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Loading /Users/cibrario/.recentf...done
Cleaning up the recentf list...done (0 removed)
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark saved where search started [3 times]
Saving file /Users/cibrario/.emacs...
Wrote /Users/cibrario/.emacs
ls does not support --dired; see ‘dired-use-ls-dired’ for more details.
Deleting...done
user-error: No mark set in this buffer
Undo!

Load-path shadows:
None found.

Features:
(shadow sort flyspell ispell mail-extr emacsbug message format-spec
rfc822 mml mml-sec password-cache epg gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr mail-utils dired
misearch multi-isearch server printing ps-print ps-def lpr type-break
paren recentf tree-widget wid-edit cus-start cus-load
exec-path-from-shell finder-inf info tex-site package epg-config seq
byte-opt gv bytecomp byte-compile cl-extra help-mode easymenu cconv
cl-loaddefs pcase cl-lib time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel ns-win ucs-normalize
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core 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 charscript case-table epa-hook jka-cmpr-hook help
simple abbrev 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
kqueue cocoa ns multi-tty make-network-process emacs)

Memory information:
((conses 16 245607 9453)
(symbols 48 24063 0)
(miscs 40 89 541)
(strings 32 29703 9388)
(string-bytes 1 900638)
(vectors 16 43786)
(vector-slots 8 1414432 167453)
(floats 8 448 88)
(intervals 56 801 63)
(buffers 976 19))

bug#23462: 25.0.93; Crash on OS X when suspending main frame

[Alan Third]

On Thu, May 05, 2016 at 11:25:06PM +0200, Ivan Cibrario Bertolotti wrote:
> Emacs crashes when using the suspend-frame command (bound
> to C-z by default) on the main frame.  It works correctly when the frame
> is minimized by clicking on the GUI button.
> 
> Recipe: Start emacs -Q; type C-z; Emacs crashes with:
> Fatal error 11: Segmentation faultAbort trap: 6

I can confirm this happens in Emacs 25 and the master branch.
-- 
Alan Third

bug#23462: 25.0.93; Crash on OS X when suspending main frame

[Eli Zaretskii]

> Date: Sun, 8 May 2016 10:53:03 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: 23462@debbugs.gnu.org
> 
> On Thu, May 05, 2016 at 11:25:06PM +0200, Ivan Cibrario Bertolotti wrote:
> > Emacs crashes when using the suspend-frame command (bound
> > to C-z by default) on the main frame.  It works correctly when the frame
> > is minimized by clicking on the GUI button.
> > 
> > Recipe: Start emacs -Q; type C-z; Emacs crashes with:
> > Fatal error 11: Segmentation faultAbort trap: 6
> 
> I can confirm this happens in Emacs 25 and the master branch.

Thanks.

Could one of you please show a more detailed backtrace, preferably
from GDB, showing exactly which source line crashed, and perhaps also
what data was invalid and caused the crash?

Also, does iconify-frame at all work on OS X?

bug#23462: 25.0.93; Crash on OS X when suspending main frame

[Ivan Cibrario Bertolotti]

> On 8 May 2016, at 17:58, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> Date: Sun, 8 May 2016 10:53:03 +0100
>> From: Alan Third <alan@idiocy.org>
>> Cc: 23462@debbugs.gnu.org
>> 
>> On Thu, May 05, 2016 at 11:25:06PM +0200, Ivan Cibrario Bertolotti wrote:
>>> Emacs crashes when using the suspend-frame command (bound
>>> to C-z by default) on the main frame.  It works correctly when the frame
>>> is minimized by clicking on the GUI button.
>>> 
>>> Recipe: Start emacs -Q; type C-z; Emacs crashes with:
>>> Fatal error 11: Segmentation faultAbort trap: 6
>> 
>> I can confirm this happens in Emacs 25 and the master branch.
> 
> Thanks.
> 
> Could one of you please show a more detailed backtrace, preferably
> from GDB, showing exactly which source line crashed, and perhaps also
> what data was invalid and caused the crash?

Thank you for your reply.  At the bottom of this email there is a backtrace taken with lldb (case #1), OS X does not have gdb by default.

I’m wandering into unfamiliar territory, but it seems to me that the crash is due to a NULL pointer dereference within GUI-related system libraries, probably an Objective C object pointer.

On occasion, I also get a different kind of crash in the same scenario, which leads me to suspect a memory corruption issue.  The lldb backtrace is also at the bottom of this email (case #2).  In case #2, the following error message is dumped onto stderr just before crashing:

objc[13904]: autorelease pool page 0x101067000 corrupted
  magic     0x00000000 0x00000000 0x101106c0 0xe0000000
  should be 0xa1a1a1a1 0x4f545541 0x454c4552 0x21455341
  pthread   0x7fff776e3000
  should be 0x7fff776e3000

As you can see, the pre-built executable I’m currently using does not have symbolic debugging information, I’ll try to build from sources and get back to you with more information soon.


> Also, does iconify-frame at all work on OS X?

When invoked manually, from M-x, it works correctly only sometimes.  In other cases, it crashes Emacs as above (case #1).  With low probability, Emacs may also get trapped in a busy loop between itself and the kernel (they both take about 50% of CPU time).  I saw it but, unfortunately, I was unable to reproduce this issue within lldb so far.

Best regards,
ICB
   

— lldb backtrace, case #1 —
Process 13817 stopped
* thread #1: tid = 0x7ee728, 0x00007fff8584da7a libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop(void*) + 402, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
    frame #0: 0x00007fff8584da7a libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop(void*) + 402
libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop:
->  0x7fff8584da7a <+402>: movq   0x10(%rbx), %rax
    0x7fff8584da7e <+406>: leaq   0x38(%rbx), %rcx
    0x7fff8584da82 <+410>: cmpq   %rcx, %rax
    0x7fff8584da85 <+413>: jne    0x7fff8584daa7            ; <+447>

(lldb) bt all
* thread #1: tid = 0x7ee728, 0x00007fff8584da7a libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop(void*) + 402, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
  * frame #0: 0x00007fff8584da7a libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop(void*) + 402
    frame #1: 0x00007fff974c4987 QuartzCore`CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 87
    frame #2: 0x00007fff995f2067 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
    frame #3: 0x00007fff995f1fd7 CoreFoundation`__CFRunLoopDoObservers + 391
    frame #4: 0x00007fff995d0ef8 CoreFoundation`CFRunLoopRunSpecific + 328
    frame #5: 0x00007fff84c4571e HIServices`waitForTransaction + 204
    frame #6: 0x00007fff92c12b07 AppKit`minimizeItemsMaybeBatching + 89
    frame #7: 0x00007fff92c45f29 AppKit`-[NSWindow(NSWindow_Theme) _minimizeToDock] + 192
    frame #8: 0x00000001001a267e Emacs-x86_64-10_9`x_iconify_frame + 430
    frame #9: 0x0000000100010587 Emacs-x86_64-10_9`Ficonify_frame + 135
    frame #10: 0x0000000100139ec8 Emacs-x86_64-10_9`Ffuncall + 1016
    frame #11: 0x00000001001720f5 Emacs-x86_64-10_9`exec_byte_code + 2277
    frame #12: 0x0000000100139d4f Emacs-x86_64-10_9`Ffuncall + 639
    frame #13: 0x00000001001720f5 Emacs-x86_64-10_9`exec_byte_code + 2277
    frame #14: 0x0000000100139d4f Emacs-x86_64-10_9`Ffuncall + 639
    frame #15: 0x0000000100133faa Emacs-x86_64-10_9`Ffuncall_interactively + 58
    frame #16: 0x0000000100139de7 Emacs-x86_64-10_9`Ffuncall + 791
    frame #17: 0x00000001001397f8 Emacs-x86_64-10_9`Fapply + 136
    frame #18: 0x00000001001347ba Emacs-x86_64-10_9`Fcall_interactively + 2042
    frame #19: 0x0000000100139efb Emacs-x86_64-10_9`Ffuncall + 1067
    frame #20: 0x00000001001720f5 Emacs-x86_64-10_9`exec_byte_code + 2277
    frame #21: 0x0000000100139d4f Emacs-x86_64-10_9`Ffuncall + 639
    frame #22: 0x000000010013a57d Emacs-x86_64-10_9`call1 + 45
    frame #23: 0x00000001000bd66a Emacs-x86_64-10_9`command_loop_1 + 1962
    frame #24: 0x0000000100138946 Emacs-x86_64-10_9`internal_condition_case + 70
    frame #25: 0x00000001000cdf60 Emacs-x86_64-10_9`command_loop_2 + 48
    frame #26: 0x00000001001384a6 Emacs-x86_64-10_9`internal_catch + 54
    frame #27: 0x00000001000bc58e Emacs-x86_64-10_9`command_loop + 158
    frame #28: 0x00000001000bc4a9 Emacs-x86_64-10_9`recursive_edit_1 + 105
    frame #29: 0x00000001000bc6cc Emacs-x86_64-10_9`Frecursive_edit + 220
    frame #30: 0x00000001000bb3ae Emacs-x86_64-10_9`main + 5854
    frame #31: 0x00007fff85d4a5ad libdyld.dylib`start + 1


— lldb backtrace, case #2 —
objc[13904]: autorelease pool page 0x101067000 corrupted
  magic     0x00000000 0x00000000 0x101106c0 0xe0000000
  should be 0xa1a1a1a1 0x4f545541 0x454c4552 0x21455341
  pthread   0x7fff776e3000
  should be 0x7fff776e3000

Process 13904 stopped
* thread #1: tid = 0x7f05cc, 0x00007fff8585be50 libobjc.A.dylib`_objc_trap(), queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
    frame #0: 0x00007fff8585be50 libobjc.A.dylib`_objc_trap()
libobjc.A.dylib`_objc_trap:
->  0x7fff8585be50 <+0>: ud2    

libobjc.A.dylib`__objc_error:
    0x7fff8585be52 <+0>: pushq  %rbp
    0x7fff8585be53 <+1>: movq   %rsp, %rbp
    0x7fff8585be56 <+4>: subq   $0xd0, %rsp

(lldb) bt all
* thread #1: tid = 0x7f05cc, 0x00007fff8585be50 libobjc.A.dylib`_objc_trap(), queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
  * frame #0: 0x00007fff8585be50 libobjc.A.dylib`_objc_trap()
    frame #1: 0x00007fff8585bf90 libobjc.A.dylib`_objc_fatal(char const*, ...) + 195
    frame #2: 0x00007fff85868875 libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::busted(bool) + 137
    frame #3: 0x00007fff8584d92e libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop(void*) + 70
    frame #4: 0x00007fff974c4987 QuartzCore`CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 87
    frame #5: 0x00007fff995f2067 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
    frame #6: 0x00007fff995f1fd7 CoreFoundation`__CFRunLoopDoObservers + 391
    frame #7: 0x00007fff995d0ef8 CoreFoundation`CFRunLoopRunSpecific + 328
    frame #8: 0x00007fff84c4571e HIServices`waitForTransaction + 204
    frame #9: 0x00007fff92c12b07 AppKit`minimizeItemsMaybeBatching + 89
    frame #10: 0x00007fff92c45f29 AppKit`-[NSWindow(NSWindow_Theme) _minimizeToDock] + 192
    frame #11: 0x00000001001a267e Emacs-x86_64-10_9`x_iconify_frame + 430
    frame #12: 0x0000000100010587 Emacs-x86_64-10_9`Ficonify_frame + 135
    frame #13: 0x0000000100139ec8 Emacs-x86_64-10_9`Ffuncall + 1016
    frame #14: 0x00000001001720f5 Emacs-x86_64-10_9`exec_byte_code + 2277
    frame #15: 0x0000000100139d4f Emacs-x86_64-10_9`Ffuncall + 639
    frame #16: 0x00000001001720f5 Emacs-x86_64-10_9`exec_byte_code + 2277
    frame #17: 0x0000000100139d4f Emacs-x86_64-10_9`Ffuncall + 639
    frame #18: 0x0000000100133faa Emacs-x86_64-10_9`Ffuncall_interactively + 58
    frame #19: 0x0000000100139de7 Emacs-x86_64-10_9`Ffuncall + 791
    frame #20: 0x00000001001397f8 Emacs-x86_64-10_9`Fapply + 136
    frame #21: 0x00000001001347ba Emacs-x86_64-10_9`Fcall_interactively + 2042
    frame #22: 0x0000000100139efb Emacs-x86_64-10_9`Ffuncall + 1067
    frame #23: 0x00000001001720f5 Emacs-x86_64-10_9`exec_byte_code + 2277
    frame #24: 0x0000000100139d4f Emacs-x86_64-10_9`Ffuncall + 639
    frame #25: 0x000000010013a57d Emacs-x86_64-10_9`call1 + 45
    frame #26: 0x00000001000bd66a Emacs-x86_64-10_9`command_loop_1 + 1962
    frame #27: 0x0000000100138946 Emacs-x86_64-10_9`internal_condition_case + 70
    frame #28: 0x00000001000cdf60 Emacs-x86_64-10_9`command_loop_2 + 48
    frame #29: 0x00000001001384a6 Emacs-x86_64-10_9`internal_catch + 54
    frame #30: 0x00000001000bc58e Emacs-x86_64-10_9`command_loop + 158
    frame #31: 0x00000001000bc4a9 Emacs-x86_64-10_9`recursive_edit_1 + 105
    frame #32: 0x00000001000bc6cc Emacs-x86_64-10_9`Frecursive_edit + 220
    frame #33: 0x00000001000bb3ae Emacs-x86_64-10_9`main + 5854
    frame #34: 0x00007fff85d4a5ad libdyld.dylib`start + 1

bug#23462: 25.0.93; Crash on OS X when suspending main frame

[Alan Third]

On Thu, May 05, 2016 at 11:25:06PM +0200, Ivan Cibrario Bertolotti wrote:
> Emacs crashes when using the suspend-frame command (bound
> to C-z by default) on the main frame.  It works correctly when the frame
> is minimized by clicking on the GUI button.
> 
> Recipe: Start emacs -Q; type C-z; Emacs crashes with:
> Fatal error 11: Segmentation faultAbort trap: 6

The last thing it does before crashing (but after minimizing) is:

[EmacsView drawRect:(X:578 Y:4)/(W:15 H:472)]

Which is a rather tall and narrow box.

If I turn off scroll-bars it doesn't crash.

Emacs really shouldn't be trying to draw scroll-bars to the screen
when it's minimized, I'd think.

I'll look into it more when I've got some time.

-- 
Alan Third

bug#23462: 25.0.93; Crash on OS X when suspending main frame

[Ivan Cibrario Bertolotti]

> On 9 May 2016, at 00:41, Alan Third <alan@idiocy.org> wrote:
> 
> On Thu, May 05, 2016 at 11:25:06PM +0200, Ivan Cibrario Bertolotti wrote:
>> Emacs crashes when using the suspend-frame command (bound
>> to C-z by default) on the main frame.  It works correctly when the frame
>> is minimized by clicking on the GUI button.
>> 
>> Recipe: Start emacs -Q; type C-z; Emacs crashes with:
>> Fatal error 11: Segmentation faultAbort trap: 6
> 
> The last thing it does before crashing (but after minimizing) is:
> 
> [EmacsView drawRect:(X:578 Y:4)/(W:15 H:472)]

Just to give it a try (I know this is far away from being a proper patch and I’m not an expert on Cocoa), I added

|| !FRAME_VISIBLE_P (emacsframe)

to the predicate at nsterm.m:7593.  This should short-circuit drawRect when the frame is not visible and Emacs no longer crashes.

Best regards,
ICB

bug#23462: 25.0.93; Crash on OS X when suspending main frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

Hi Ivan and Alan!

I'm not sure that is the correct place for the patch.

Could you enable NSTRACE (by uncommenting the line defining NSTRACE_ENABLED
in nsterm.h) and see which function calls `drawRect` (if possible). If that
is in a function that is part of Emacs, it's better to check that the frame
is visible higher up in the call chain.

You will have to start Emacs from a terminal window in order to see the
trace output. You can do this by running
"./nextstep/Emacs.app/Content/MacOS/Emacs".

    -- Anders

[-- Attachment #2: Type: text/html, Size: 668 bytes --]

bug#23462: 25.0.93; Crash on OS X when suspending main frame

[Ivan Cibrario Bertolotti]

Hi Anders,

> On 10 May 2016, at 20:56, Anders Lindgren <andlind@gmail.com> wrote:
> 
> Hi Ivan and Alan!
> 
> I'm not sure that is the correct place for the patch.
> 
> Could you enable NSTRACE (by uncommenting the line defining NSTRACE_ENABLED in nsterm.h) and see which function calls `drawRect` (if possible). If that is in a function that is part of Emacs, it's better to check that the frame is visible higher up in the call chain.
> 
> You will have to start Emacs from a terminal window in order to see the trace output. You can do this by running "./nextstep/Emacs.app/Content/MacOS/Emacs”.

here is the relevant part of the trace output:

nsterm.m  : 1595: [ 6322]  x_iconify_frame
nsterm.m  : 6770: [ 6323]  | [EmacsView windowWillMiniaturize:]
nsterm.m  : 6735: [ 6324]  | [EmacsView windowDidResignKey:]
nsterm.m  : 1504: [ 6325]  | | ns_frame_rehighlight
nsterm.m  : 7121: [ 6326]  | [EmacsView windowDidMiniaturize:]
nsterm.m  : 7591: [ 6327]  | [EmacsView drawRect:(X:578 Y:4)/(W:15 H:472)]

If I understand it correctly, the top-level function involved (within nsterm.m) is x_iconify_frame.  The only explicit call pertinent to the issue that I see within it is:

[[view window] miniaturize: NSApp];

at nsterm.m:1615.  I think that the others, from windowWillMiniaturize to drawRect, are callbacks.  The reason why a miniaturize request triggers a drawRect escapes me at this time, but I’m definitely not an expert on this GUI.

Thank you and please let me know if I can be of further assistance.

Best regards,
Ivan

bug#23462: 25.0.93; Crash on OS X when suspending main frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 2117 bytes --]

Hi!

Thanks for the trace output.

As far as I can tell, I don't see a better location to place the test. (I
have to include myself in the group who have no idea why drawRect is being
called when the frame is miniatured.) I would suggest that we add it as you
originally suggested.

Alan, what do you say? Have you looked into this?

    -- Anders


On Tue, May 10, 2016 at 10:13 PM, Ivan Cibrario Bertolotti <
ivan.cibrario@polito.it> wrote:

> Hi Anders,
>
> > On 10 May 2016, at 20:56, Anders Lindgren <andlind@gmail.com> wrote:
> >
> > Hi Ivan and Alan!
> >
> > I'm not sure that is the correct place for the patch.
> >
> > Could you enable NSTRACE (by uncommenting the line defining
> NSTRACE_ENABLED in nsterm.h) and see which function calls `drawRect` (if
> possible). If that is in a function that is part of Emacs, it's better to
> check that the frame is visible higher up in the call chain.
> >
> > You will have to start Emacs from a terminal window in order to see the
> trace output. You can do this by running
> "./nextstep/Emacs.app/Content/MacOS/Emacs”.
>
> here is the relevant part of the trace output:
>
> nsterm.m  : 1595: [ 6322]  x_iconify_frame
> nsterm.m  : 6770: [ 6323]  | [EmacsView windowWillMiniaturize:]
> nsterm.m  : 6735: [ 6324]  | [EmacsView windowDidResignKey:]
> nsterm.m  : 1504: [ 6325]  | | ns_frame_rehighlight
> nsterm.m  : 7121: [ 6326]  | [EmacsView windowDidMiniaturize:]
> nsterm.m  : 7591: [ 6327]  | [EmacsView drawRect:(X:578 Y:4)/(W:15 H:472)]
>
> If I understand it correctly, the top-level function involved (within
> nsterm.m) is x_iconify_frame.  The only explicit call pertinent to the
> issue that I see within it is:
>
> [[view window] miniaturize: NSApp];
>
> at nsterm.m:1615.  I think that the others, from windowWillMiniaturize to
> drawRect, are callbacks.  The reason why a miniaturize request triggers a
> drawRect escapes me at this time, but I’m definitely not an expert on this
> GUI.
>
> Thank you and please let me know if I can be of further assistance.
>
> Best regards,
> Ivan
>
>

[-- Attachment #2: Type: text/html, Size: 2675 bytes --]

bug#23462: 25.0.93; Crash on OS X when suspending main frame

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 478 bytes --]

On 10 May 2016 10:57 p.m., "Anders Lindgren" <andlind@gmail.com> wrote:
>
> As far as I can tell, I don't see a better location to place the test. (I
have to include myself in the group who have no idea why drawRect is being
called when the frame is miniatured.) I would suggest that we add it as you
originally suggested.
>
> Alan, what do you say? Have you looked into this?

Not yet. I'll be able to have a look on Thursday or Friday if you want, but
I'm very busy just now.

[-- Attachment #2: Type: text/html, Size: 612 bytes --]

bug#23462: 25.0.93; Crash on OS X when suspending main frame

[Alan Third]

On Tue, May 10, 2016 at 11:57:47PM +0200, Anders Lindgren wrote:
> 
> As far as I can tell, I don't see a better location to place the test. (I
> have to include myself in the group who have no idea why drawRect is being
> called when the frame is miniatured.) I would suggest that we add it as you
> originally suggested.
> 
> Alan, what do you say? Have you looked into this?

I've had a very quick look into this and it seems to actually be one,
or both, of the calls to block_input and unblock_input in drawRect
that are causing the crash.

I don't know what they do or why they're causing the crash.
-- 
Alan Third

bug#23462: 25.0.93; Crash on OS X when suspending main frame

[Alan Third]

On Tue, May 10, 2016 at 11:57:47PM +0200, Anders Lindgren wrote:
>
> As far as I can tell, I don't see a better location to place the test. (I
> have to include myself in the group who have no idea why drawRect is being
> called when the frame is miniatured.) I would suggest that we add it as you
> originally suggested.
> 
> Alan, what do you say? Have you looked into this?

Right, on a hunch that it's something to do with Emacs receiving and
processing signals or input of some sort during or immediately after
minimization, I tried wrapping

    [[view window] miniaturize: NSApp];

in x_iconify_frame with block_input and unblock_input:

    block_input();
    [[view window] miniaturize: NSApp];
    unblock_input();

which seems to have solved the crash.

I'm not super-happy with this as the error message implies that
something is being created in Objective C, then either clobbered or
released elsewhere, *then* Objective C tries to release it
automatically and it's already clobbered/gone. But I can't trace it
back to find out what's actually going on. It appears to be related to
unblock_input forcing the processing of "pending" signals or input
when drawRect runs, but why is that breaking Objective C's garbage
collection routines?

I guess it probably doesn't matter, as long as it works.
-- 
Alan Third

bug#23462: 25.0.93; Crash on OS X when suspending main frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

Hi!


> Right, on a hunch that it's something to do with Emacs receiving and
> processing signals or input of some sort during or immediately after
> minimization, I tried wrapping
>
>     [[view window] miniaturize: NSApp];
>
> in x_iconify_frame with block_input and unblock_input:
>
>     block_input();
>     [[view window] miniaturize: NSApp];
>     unblock_input();
>
> which seems to have solved the crash.
>

This seems like a much cleaner solution than the earlier.

It looks very similar to the startup crash I tracked down a fixed about a
year ago, when input events started to arrive before emacs had finished its
initialization.

    -- Anders

[-- Attachment #2: Type: text/html, Size: 1003 bytes --]

bug#23462: [PATCH] Block input while minimizing on NS (bug#23462)

[Alan Third]

* src/nsterm.m (x_iconify_frame): Block input while miniaturize is
running.
---
 src/nsterm.m | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/src/nsterm.m b/src/nsterm.m
index 1d48c04..840c9c1 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -1612,7 +1612,12 @@ static void hide_bell ()
       [[view window] orderOut: NSApp];
       [[view window] setFrame: t display: NO];
     }
+
+  /* Processing input while Emacs is being minimized can cause a
+     crash, so block it for the duration. */
+  block_input();
   [[view window] miniaturize: NSApp];
+  unblock_input();
 }
 
 /* Free X resources of frame F.  */
-- 

I've tried this on GNUStep as well and it doesn't break it any more
than it's already broken.

-- 
Alan Third

bug#23462: [PATCH] Block input while minimizing on NS (bug#23462)

[Ivan Cibrario Bertolotti]

Hi,

> On 12 May 2016, at 13:52, Alan Third <alan@idiocy.org> wrote:
> 
> […]
> 
> I've tried this on GNUStep as well and it doesn't break it any more
> than it's already broken.

Thank you so much!  I applied your patch to 25.0.93 and tried it on OS X, both with and without NSTRACE_ENABLED.  It does not count as a formal test, but I can confirm no crashes after minimizing/restoring about 20 times each.  I did it because here Emacs crashed most of the time, but not always, and it seemed to depend on timings.

Best regards,
Ivan

bug#23462: [PATCH] Block input while minimizing on NS (bug#23462)

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]

Hi!

This is good news! I can't recreate the problem here, most likely because
I'm still on 10.10. However, it works for Alan and Ivan, who originally
reported the problem, has confirmed that the patch corrects the problem.

Unless anybody objects, I will push the patch to "emacs-25" in a day or
two. John?

Thanks everybody!

    -- Anders

On Thu, May 12, 2016 at 6:38 PM, Ivan Cibrario Bertolotti <
ivan.cibrario@polito.it> wrote:

> Hi,
>
> > On 12 May 2016, at 13:52, Alan Third <alan@idiocy.org> wrote:
> >
> > […]
> >
> > I've tried this on GNUStep as well and it doesn't break it any more
> > than it's already broken.
>
> Thank you so much!  I applied your patch to 25.0.93 and tried it on OS X,
> both with and without NSTRACE_ENABLED.  It does not count as a formal test,
> but I can confirm no crashes after minimizing/restoring about 20 times
> each.  I did it because here Emacs crashed most of the time, but not
> always, and it seemed to depend on timings.
>
> Best regards,
> Ivan
>
>

[-- Attachment #2: Type: text/html, Size: 1552 bytes --]

bug#23462: [PATCH] Block input while minimizing on NS (bug#23462)

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 1401 bytes --]

Hi!

I got OK from John to commit this to the emacs-25 branch. See
http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-25&id=06cb28ff3f24a29fa140d8af747d10abeed44293
for details.

Everybody -- thanks!

    -- Anders

On Thu, May 12, 2016 at 8:28 PM, Anders Lindgren <andlind@gmail.com> wrote:

> Hi!
>
> This is good news! I can't recreate the problem here, most likely because
> I'm still on 10.10. However, it works for Alan and Ivan, who originally
> reported the problem, has confirmed that the patch corrects the problem.
>
> Unless anybody objects, I will push the patch to "emacs-25" in a day or
> two. John?
>
> Thanks everybody!
>
>     -- Anders
>
> On Thu, May 12, 2016 at 6:38 PM, Ivan Cibrario Bertolotti <
> ivan.cibrario@polito.it> wrote:
>
>> Hi,
>>
>> > On 12 May 2016, at 13:52, Alan Third <alan@idiocy.org> wrote:
>> >
>> > […]
>> >
>> > I've tried this on GNUStep as well and it doesn't break it any more
>> > than it's already broken.
>>
>> Thank you so much!  I applied your patch to 25.0.93 and tried it on OS X,
>> both with and without NSTRACE_ENABLED.  It does not count as a formal test,
>> but I can confirm no crashes after minimizing/restoring about 20 times
>> each.  I did it because here Emacs crashed most of the time, but not
>> always, and it seemed to depend on timings.
>>
>> Best regards,
>> Ivan
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 2460 bytes --]