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