From: Ivan Cibrario Bertolotti <ivan.cibrario@polito.it>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 23462@debbugs.gnu.org, Alan Third <alan@idiocy.org>
Subject: bug#23462: 25.0.93; Crash on OS X when suspending main frame
Date: Sun, 8 May 2016 18:56:15 +0200 [thread overview]
Message-ID: <E3C6F1A9-0209-4770-9C85-5819907522E9@polito.it> (raw)
In-Reply-To: <83futsee39.fsf@gnu.org>
> 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
next prev parent reply other threads:[~2016-05-08 16:56 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-05 21:25 bug#23462: 25.0.93; Crash on OS X when suspending main frame Ivan Cibrario Bertolotti
2016-05-08 9:53 ` Alan Third
2016-05-08 15:58 ` Eli Zaretskii
2016-05-08 16:56 ` Ivan Cibrario Bertolotti [this message]
2016-05-08 22:41 ` Alan Third
2016-05-09 8:49 ` Ivan Cibrario Bertolotti
2016-05-10 18:56 ` Anders Lindgren
2016-05-10 20:13 ` Ivan Cibrario Bertolotti
2016-05-10 21:57 ` Anders Lindgren
2016-05-10 22:08 ` Alan Third
2016-05-10 23:16 ` Alan Third
2016-05-11 22:28 ` Alan Third
2016-05-12 5:39 ` Anders Lindgren
2016-05-12 11:52 ` bug#23462: [PATCH] Block input while minimizing on NS (bug#23462) Alan Third
2016-05-12 16:38 ` Ivan Cibrario Bertolotti
2016-05-12 18:28 ` Anders Lindgren
2016-05-16 18:45 ` Anders Lindgren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E3C6F1A9-0209-4770-9C85-5819907522E9@polito.it \
--to=ivan.cibrario@polito.it \
--cc=23462@debbugs.gnu.org \
--cc=alan@idiocy.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.