* bug#23462: 25.0.93; Crash on OS X when suspending main frame
@ 2016-05-05 21:25 Ivan Cibrario Bertolotti
2016-05-08 9:53 ` Alan Third
` (2 more replies)
0 siblings, 3 replies; 17+ messages in thread
From: Ivan Cibrario Bertolotti @ 2016-05-05 21:25 UTC (permalink / raw)
To: 23462
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))
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#23462: 25.0.93; Crash on OS X when suspending main frame
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 22:41 ` Alan Third
2016-05-10 18:56 ` Anders Lindgren
2 siblings, 1 reply; 17+ messages in thread
From: Alan Third @ 2016-05-08 9:53 UTC (permalink / raw)
To: Ivan Cibrario Bertolotti; +Cc: 23462
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#23462: 25.0.93; Crash on OS X when suspending main frame
2016-05-08 9:53 ` Alan Third
@ 2016-05-08 15:58 ` Eli Zaretskii
2016-05-08 16:56 ` Ivan Cibrario Bertolotti
0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2016-05-08 15:58 UTC (permalink / raw)
To: Alan Third; +Cc: 23462, ivan.cibrario
> 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?
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#23462: 25.0.93; Crash on OS X when suspending main frame
2016-05-08 15:58 ` Eli Zaretskii
@ 2016-05-08 16:56 ` Ivan Cibrario Bertolotti
0 siblings, 0 replies; 17+ messages in thread
From: Ivan Cibrario Bertolotti @ 2016-05-08 16:56 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 23462, Alan Third
> 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
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#23462: 25.0.93; Crash on OS X when suspending main frame
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 22:41 ` Alan Third
2016-05-09 8:49 ` Ivan Cibrario Bertolotti
2016-05-10 18:56 ` Anders Lindgren
2 siblings, 1 reply; 17+ messages in thread
From: Alan Third @ 2016-05-08 22:41 UTC (permalink / raw)
To: Ivan Cibrario Bertolotti; +Cc: 23462
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#23462: 25.0.93; Crash on OS X when suspending main frame
2016-05-08 22:41 ` Alan Third
@ 2016-05-09 8:49 ` Ivan Cibrario Bertolotti
0 siblings, 0 replies; 17+ messages in thread
From: Ivan Cibrario Bertolotti @ 2016-05-09 8:49 UTC (permalink / raw)
To: Alan Third; +Cc: 23462
> 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
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#23462: 25.0.93; Crash on OS X when suspending main frame
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 22:41 ` Alan Third
@ 2016-05-10 18:56 ` Anders Lindgren
2016-05-10 20:13 ` Ivan Cibrario Bertolotti
2 siblings, 1 reply; 17+ messages in thread
From: Anders Lindgren @ 2016-05-10 18:56 UTC (permalink / raw)
To: ivan.cibrario, 23462, Alan Third
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#23462: 25.0.93; Crash on OS X when suspending main frame
2016-05-10 18:56 ` Anders Lindgren
@ 2016-05-10 20:13 ` Ivan Cibrario Bertolotti
2016-05-10 21:57 ` Anders Lindgren
0 siblings, 1 reply; 17+ messages in thread
From: Ivan Cibrario Bertolotti @ 2016-05-10 20:13 UTC (permalink / raw)
To: Anders Lindgren; +Cc: 23462, Alan Third
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#23462: 25.0.93; Crash on OS X when suspending main frame
2016-05-10 20:13 ` Ivan Cibrario Bertolotti
@ 2016-05-10 21:57 ` Anders Lindgren
2016-05-10 22:08 ` Alan Third
` (2 more replies)
0 siblings, 3 replies; 17+ messages in thread
From: Anders Lindgren @ 2016-05-10 21:57 UTC (permalink / raw)
To: Ivan Cibrario Bertolotti; +Cc: 23462, Alan Third
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#23462: 25.0.93; Crash on OS X when suspending main frame
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
2 siblings, 0 replies; 17+ messages in thread
From: Alan Third @ 2016-05-10 22:08 UTC (permalink / raw)
To: Anders Lindgren; +Cc: 23462, Ivan Cibrario Bertolotti
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#23462: 25.0.93; Crash on OS X when suspending main frame
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
2 siblings, 0 replies; 17+ messages in thread
From: Alan Third @ 2016-05-10 23:16 UTC (permalink / raw)
To: Anders Lindgren; +Cc: 23462, Ivan Cibrario Bertolotti
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#23462: 25.0.93; Crash on OS X when suspending main frame
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
2 siblings, 1 reply; 17+ messages in thread
From: Alan Third @ 2016-05-11 22:28 UTC (permalink / raw)
To: Anders Lindgren; +Cc: 23462, Ivan Cibrario Bertolotti
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#23462: 25.0.93; Crash on OS X when suspending main frame
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
0 siblings, 1 reply; 17+ messages in thread
From: Anders Lindgren @ 2016-05-12 5:39 UTC (permalink / raw)
To: Alan Third; +Cc: 23462, Ivan Cibrario Bertolotti
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#23462: [PATCH] Block input while minimizing on NS (bug#23462)
2016-05-12 5:39 ` Anders Lindgren
@ 2016-05-12 11:52 ` Alan Third
2016-05-12 16:38 ` Ivan Cibrario Bertolotti
0 siblings, 1 reply; 17+ messages in thread
From: Alan Third @ 2016-05-12 11:52 UTC (permalink / raw)
To: Anders Lindgren; +Cc: 23462, Ivan Cibrario Bertolotti
* 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
^ permalink raw reply related [flat|nested] 17+ messages in thread
* bug#23462: [PATCH] Block input while minimizing on NS (bug#23462)
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
0 siblings, 1 reply; 17+ messages in thread
From: Ivan Cibrario Bertolotti @ 2016-05-12 16:38 UTC (permalink / raw)
To: Alan Third; +Cc: 23462, Anders Lindgren
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#23462: [PATCH] Block input while minimizing on NS (bug#23462)
2016-05-12 16:38 ` Ivan Cibrario Bertolotti
@ 2016-05-12 18:28 ` Anders Lindgren
2016-05-16 18:45 ` Anders Lindgren
0 siblings, 1 reply; 17+ messages in thread
From: Anders Lindgren @ 2016-05-12 18:28 UTC (permalink / raw)
To: Ivan Cibrario Bertolotti; +Cc: 23462, Alan Third
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#23462: [PATCH] Block input while minimizing on NS (bug#23462)
2016-05-12 18:28 ` Anders Lindgren
@ 2016-05-16 18:45 ` Anders Lindgren
0 siblings, 0 replies; 17+ messages in thread
From: Anders Lindgren @ 2016-05-16 18:45 UTC (permalink / raw)
To: Ivan Cibrario Bertolotti; +Cc: 23462-done, Alan Third
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2016-05-16 18:45 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).