[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#23462: 25.0.93; Crash on OS X when suspending main frame
From: |
Ivan Cibrario Bertolotti |
Subject: |
bug#23462: 25.0.93; Crash on OS X when suspending main frame |
Date: |
Sun, 8 May 2016 18:56:15 +0200 |
> 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, Ivan Cibrario Bertolotti, 2016/05/05
- bug#23462: 25.0.93; Crash on OS X when suspending main frame, Alan Third, 2016/05/08
- bug#23462: 25.0.93; Crash on OS X when suspending main frame, Alan Third, 2016/05/08
- bug#23462: 25.0.93; Crash on OS X when suspending main frame, Anders Lindgren, 2016/05/10
- bug#23462: 25.0.93; Crash on OS X when suspending main frame, Ivan Cibrario Bertolotti, 2016/05/10
- bug#23462: 25.0.93; Crash on OS X when suspending main frame, Anders Lindgren, 2016/05/10
- bug#23462: 25.0.93; Crash on OS X when suspending main frame, Alan Third, 2016/05/10
- bug#23462: 25.0.93; Crash on OS X when suspending main frame, Alan Third, 2016/05/10
- bug#23462: 25.0.93; Crash on OS X when suspending main frame, Alan Third, 2016/05/11
- bug#23462: 25.0.93; Crash on OS X when suspending main frame, Anders Lindgren, 2016/05/12
- bug#23462: [PATCH] Block input while minimizing on NS (bug#23462), Alan Third, 2016/05/12