* bug#43973: 28.0.50; [NS] Two crashes on macOS
@ 2020-10-13 7:35 Andrii Kolomoiets
2020-10-13 13:00 ` Robert Pluim
` (3 more replies)
0 siblings, 4 replies; 17+ messages in thread
From: Andrii Kolomoiets @ 2020-10-13 7:35 UTC (permalink / raw)
To: 43973
Update to recent trunk brought me everyone's favorite random crashes.
In an attempt to find the recipe for reproduce the bug somehow, I spot
two crashes that I actually can reproduce in 'emacs -Q'.
The first one is more "stable":
With this code in scratch and point at '|':
(make-frame `((parent-frame . ,(selected-frame))
(width . 0.5)
(height . 0.5)
(top . 0.5)
(left . 0.5)))|
1. C-x C-e
2. s-w
Repeating these two steps 3-5 times leads to crash. Most of the time
the only meaningfull record in the 'bt' is:
Thread 3 received signal SIGSEGV, Segmentation fault.
0x00007fff6fa97678 in ?? ()
(gdb) bt full
#0 0x00007fff6fa97678 in ?? ()
No symbol table info available.
#1 0x0000000100476338 in -[EmacsImage dealloc] (self=0x1014c77f0, _cmd=0x7fff7afcdc58) at nsimage.m:286
No locals.
It may be tool bar related, because Emacs is not crashing with
tool-bar-mode turned of.
The second one is not reproducible every time:
1. M-x tool-bar-mode
2. Evaluate
(let ((params `((parent-frame . ,(selected-frame))
(undecorated . t))))
(dotimes (_z 100)
(set-face-background 'internal-border "black"
(make-frame params))))
3. Move the frame
Thread 3 received signal SIGSEGV, Segmentation fault.
0x0000000100456e88 in ns_clear_under_internal_border (f=0x13cedafe8) at nsterm.m:3052
3052 [ns_lookup_indexed_color (NS_FACE_BACKGROUND (face), f) set];
(gdb) bt full
#0 0x0000000100456e88 in ns_clear_under_internal_border (f=0x13cedafe8) at nsterm.m:3052
frame_rect = {origin = {x = 0, y = 0}, size = {width = 595, height = 508}}
face_id = 15
border_width = 2
view = 0x10bfb2b70
edge_rect = {origin = {x = 0, y = 6.9529314086768113e-310}, size = {width = 2.6133677750952917e-314,
height = 2.6133668897296544e-314}}
edge = {NSRectEdgeMinX, NSRectEdgeMinY, NSRectEdgeMaxX, NSRectEdgeMaxY}
face = 0x0
#1 0x0000000100067b8d in redisplay_internal () at xdisp.c:16014
gcscrollbars = false
f_redisplay_flag = false
f = 0x13cedafe8
w = 0x105046430
sw = 0x105046430
fr = 0x10503b430
pending = false
must_finish = true
match_p = true
tlbufpos = {charpos = 304, bytepos = 304}
tlendpos = {charpos = 0, bytepos = 0}
number_of_visible_frames = 101
count = 3
sf = 0x10503b430
polling_stopped_here = true
tail = {i = 0x102227d93}
frame = {i = 0x13cedafed}
hscroll_retries = 0
garbaged_frame_retries = 0
consider_all_windows_p = true
update_miniwindow_p = false
#2 0x000000010006ceb9 in redisplay () at xdisp.c:15159
No locals.
(Just for the record: in my usual workflow I don't create that much
child frames)
Thanks! And hope Emacs is crashing on your side too ;)
In GNU Emacs 28.0.50 (build 3, x86_64-apple-darwin19.6.0, NS appkit-1894.60 Version 10.15.6 (Build 19G2021))
Windowing system distributor 'Apple', version 10.3.1894
System Description: Mac OS X 10.15.6
Configured using:
'configure --enable-checking=yes,glyphs --enable-check-lisp-object-type
'CFLAGS=-O0 -g3''
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#43973: 28.0.50; [NS] Two crashes on macOS
2020-10-13 7:35 bug#43973: 28.0.50; [NS] Two crashes on macOS Andrii Kolomoiets
@ 2020-10-13 13:00 ` Robert Pluim
2020-10-13 20:33 ` Alan Third
2020-10-13 19:09 ` Alan Third
` (2 subsequent siblings)
3 siblings, 1 reply; 17+ messages in thread
From: Robert Pluim @ 2020-10-13 13:00 UTC (permalink / raw)
To: Andrii Kolomoiets; +Cc: 43973
>>>>> On Tue, 13 Oct 2020 10:35:28 +0300, Andrii Kolomoiets <andreyk.mad@gmail.com> said:
Andrii> Update to recent trunk brought me everyone's favorite random crashes.
Andrii> In an attempt to find the recipe for reproduce the bug somehow, I spot
Andrii> two crashes that I actually can reproduce in 'emacs -Q'.
Andrii> The first one is more "stable":
Andrii> With this code in scratch and point at '|':
Andrii> (make-frame `((parent-frame . ,(selected-frame))
Andrii> (width . 0.5)
Andrii> (height . 0.5)
Andrii> (top . 0.5)
Andrii> (left . 0.5)))|
Andrii> 1. C-x C-e
Andrii> 2. s-w
Andrii> Repeating these two steps 3-5 times leads to crash. Most of the time
Andrii> the only meaningfull record in the 'bt' is:
Andrii> Thread 3 received signal SIGSEGV, Segmentation fault.
Andrii> 0x00007fff6fa97678 in ?? ()
Andrii> (gdb) bt full
Andrii> #0 0x00007fff6fa97678 in ?? ()
Andrii> No symbol table info available.
Andrii> #1 0x0000000100476338 in -[EmacsImage dealloc] (self=0x1014c77f0, _cmd=0x7fff7afcdc58) at nsimage.m:286
Andrii> No locals.
Andrii> It may be tool bar related, because Emacs is not crashing with
Andrii> tool-bar-mode turned of.
I think you may be right:
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x20)
* frame #0: 0x00007fff6be26678 libobjc.A.dylib`objc_release + 24
frame #1: 0x00000001001f5d1f emacs`-[EmacsImage dealloc](self=0x0000000102ac8ff0, _cmd=<unavailable>) at nsimage.m:286:3 [opt]
frame #2: 0x00007fff6be2beb3 libobjc.A.dylib`objc_object::sidetable_release(bool) + 229
frame #3: 0x00007fff301e46e1 AppKit`-[NSMenuItem dealloc] + 108
frame #4: 0x00007fff304523f8 AppKit`-[NSToolbarItem dealloc] + 110
frame #5: 0x00007fff32f072a5 CoreFoundation`__RELEASE_OBJECTS_IN_THE_ARRAY__ + 118
frame #6: 0x00007fff32f071e8 CoreFoundation`-[__NSArrayM dealloc] + 279
frame #7: 0x00007fff305b1a99 AppKit`-[NSToolbarClippedItemsIndicator dealloc] + 84
frame #8: 0x00007fff6be42054 libobjc.A.dylib`AutoreleasePoolPage::releaseUntil(objc_object**) + 134
frame #9: 0x00007fff6be26dba libobjc.A.dylib`objc_autoreleasePoolPop + 175
frame #10: 0x00007fff32f69335 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
frame #11: 0x00007fff32f69267 CoreFoundation`__CFRunLoopDoObservers + 457
frame #12: 0x00007fff32f68805 CoreFoundation`__CFRunLoopRun + 874
frame #13: 0x00007fff32f67e3e CoreFoundation`CFRunLoopRunSpecific + 462
frame #14: 0x00007fff31b94abd HIToolbox`RunCurrentEventLoopInMode + 292
frame #15: 0x00007fff31b946f4 HIToolbox`ReceiveNextEventCommon + 359
frame #16: 0x00007fff31b94579 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 64
frame #17: 0x00007fff301da039 AppKit`_DPSNextEvent + 883
frame #18: 0x00007fff301d8880 AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1352
frame #19: 0x00007fff301ca58e AppKit`-[NSApplication run] + 658
frame #20: 0x00000001001d708d emacs`-[EmacsApp run](self=0x0000000102a10a70, _cmd=<unavailable>) at nsterm.m:5765:9 [opt]
frame #21: 0x00000001001e3a1e emacs`ns_read_socket(terminal=<unavailable>, hold_quit=<unavailable>) at nsterm.m:4741:11 [opt]
frame #22: 0x00000001000d11cd emacs`gobble_input at keyboard.c:6889:17 [opt]
which is nsimage.m:
- (void)dealloc
{
[stippleMask release];
[bmRep release];
[transform release]; <====
[super dealloc];
}
Alan?
Andrii> The second one is not reproducible every time:
Andrii> 1. M-x tool-bar-mode
Andrii> 2. Evaluate
Andrii> (let ((params `((parent-frame . ,(selected-frame))
Andrii> (undecorated . t))))
Andrii> (dotimes (_z 100)
Andrii> (set-face-background 'internal-border "black"
Andrii> (make-frame params))))
Andrii> 3. Move the frame
And this I see as well, however lldb does warn us:
2020-10-13 14:54:46.765446+0200 emacs[65592:8296279] [Window] WARNING: NSWindow has detected an excessive live window count of 101. Window 0x2e668 of class 'EmacsWindow' created after passing the threshold of 100. This window is not necessarily the cause, and this warning will only be shown once per window class.
Andrii> Thread 3 received signal SIGSEGV, Segmentation fault.
Andrii> 0x0000000100456e88 in ns_clear_under_internal_border (f=0x13cedafe8) at nsterm.m:3052
Andrii> 3052 [ns_lookup_indexed_color (NS_FACE_BACKGROUND (face), f) set];
Andrii> (gdb) bt full
I suspect some initialization has been skipped somewhere:
frame #0: 0x00000001001e81bc emacs`ns_clear_under_internal_border(f=0x0000000132288150) at nsterm.m:3052:33 [opt]
3049 face = FRAME_DEFAULT_FACE (f);
3050
3051 ns_focus (f, &frame_rect, 1);
-> 3052 [ns_lookup_indexed_color (NS_FACE_BACKGROUND (face), f) set];
3053 for (int i = 0; i < 4 ; i++)
3054 {
3055 NSDivideRect (frame_rect, &edge_rect, &frame_rect, border_width, edge[i]);
Target 0: (emacs) stopped.
(lldb) p face
(face *) $0 = 0x0000000000000000
Robert
--
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#43973: 28.0.50; [NS] Two crashes on macOS
2020-10-13 13:00 ` Robert Pluim
@ 2020-10-13 20:33 ` Alan Third
2020-10-14 10:46 ` Robert Pluim
0 siblings, 1 reply; 17+ messages in thread
From: Alan Third @ 2020-10-13 20:33 UTC (permalink / raw)
To: Robert Pluim; +Cc: 43973, Andrii Kolomoiets
On Tue, Oct 13, 2020 at 03:00:31PM +0200, Robert Pluim wrote:
>
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x20)
> * frame #0: 0x00007fff6be26678 libobjc.A.dylib`objc_release + 24
> frame #1: 0x00000001001f5d1f emacs`-[EmacsImage dealloc](self=0x0000000102ac8ff0, _cmd=<unavailable>) at nsimage.m:286:3 [opt]
<snip>
>
> which is nsimage.m:
>
> - (void)dealloc
> {
> [stippleMask release];
> [bmRep release];
> [transform release]; <====
> [super dealloc];
> }
>
> Alan?
Are you sure it's crashing on that line? That makes no sense as
there's nowhere else that can release the transform, and if the image
doesn't have a transform set it should be nil so releasing it would be
a no-op...
But even if it's a neighbouring line, I can't see why that would be
happening...
I have no ideas.
--
Alan Third
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#43973: 28.0.50; [NS] Two crashes on macOS
2020-10-13 20:33 ` Alan Third
@ 2020-10-14 10:46 ` Robert Pluim
0 siblings, 0 replies; 17+ messages in thread
From: Robert Pluim @ 2020-10-14 10:46 UTC (permalink / raw)
To: Alan Third; +Cc: 43973, Andrii Kolomoiets
>>>>> On Tue, 13 Oct 2020 21:33:42 +0100, Alan Third <alan@idiocy.org> said:
Alan> On Tue, Oct 13, 2020 at 03:00:31PM +0200, Robert Pluim wrote:
>>
>> (lldb) bt
>> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x20)
>> * frame #0: 0x00007fff6be26678 libobjc.A.dylib`objc_release + 24
>> frame #1: 0x00000001001f5d1f emacs`-[EmacsImage dealloc](self=0x0000000102ac8ff0, _cmd=<unavailable>) at nsimage.m:286:3 [opt]
Alan> <snip>
>>
>> which is nsimage.m:
>>
>> - (void)dealloc
>> {
>> [stippleMask release];
>> [bmRep release];
>> [transform release]; <====
>> [super dealloc];
>> }
>>
>> Alan?
Alan> Are you sure it's crashing on that line? That makes no sense as
Alan> there's nowhere else that can release the transform, and if the image
Alan> doesn't have a transform set it should be nil so releasing it would be
Alan> a no-op...
If I comment out [transform release]; I canʼt make it crash.
Robert
--
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#43973: 28.0.50; [NS] Two crashes on macOS
2020-10-13 7:35 bug#43973: 28.0.50; [NS] Two crashes on macOS Andrii Kolomoiets
2020-10-13 13:00 ` Robert Pluim
@ 2020-10-13 19:09 ` Alan Third
2020-10-14 8:07 ` Andrii Kolomoiets
` (2 more replies)
2020-10-14 20:41 ` Alan Third
2020-10-24 1:37 ` Win Treese
3 siblings, 3 replies; 17+ messages in thread
From: Alan Third @ 2020-10-13 19:09 UTC (permalink / raw)
To: Andrii Kolomoiets; +Cc: 43973
On Tue, Oct 13, 2020 at 10:35:28AM +0300, Andrii Kolomoiets wrote:
> Update to recent trunk brought me everyone's favorite random crashes.
>
> In an attempt to find the recipe for reproduce the bug somehow, I spot
> two crashes that I actually can reproduce in 'emacs -Q'.
>
> The first one is more "stable":
>
> With this code in scratch and point at '|':
>
> (make-frame `((parent-frame . ,(selected-frame))
> (width . 0.5)
> (height . 0.5)
> (top . 0.5)
> (left . 0.5)))|
>
> 1. C-x C-e
> 2. s-w
>
> Repeating these two steps 3-5 times leads to crash. Most of the time
> the only meaningfull record in the 'bt' is:
>
> Thread 3 received signal SIGSEGV, Segmentation fault.
> 0x00007fff6fa97678 in ?? ()
> (gdb) bt full
> #0 0x00007fff6fa97678 in ?? ()
> No symbol table info available.
> #1 0x0000000100476338 in -[EmacsImage dealloc] (self=0x1014c77f0, _cmd=0x7fff7afcdc58) at nsimage.m:286
> No locals.
>
> It may be tool bar related, because Emacs is not crashing with
> tool-bar-mode turned of.
This is almost definitely the result of some image being released
twice. We've had a few crash reports where this has happened in the
past, but never actually managed to work out what's causing it.
I can't replicate the crash, fwiw.
> The second one is not reproducible every time:
>
> 1. M-x tool-bar-mode
> 2. Evaluate
> (let ((params `((parent-frame . ,(selected-frame))
> (undecorated . t))))
> (dotimes (_z 100)
> (set-face-background 'internal-border "black"
> (make-frame params))))
> 3. Move the frame
I can replicate this one, every time.
I'm not sure exactly what's going on, but it's resulting in face ==
NULL, so
modified src/nsterm.m
@@ -3048,6 +3048,9 @@ so some key presses (TAB) are swallowed by the system. */
if (!face)
face = FRAME_DEFAULT_FACE (f);
+ if (!face)
+ return;
+
ns_focus (f, &frame_rect, 1);
[ns_lookup_indexed_color (NS_FACE_BACKGROUND (face), f) set];
for (int i = 0; i < 4 ; i++)
"fixes" it, but leaves Emacs in a bit of a strange state where I can
only see one frame and it's incredibly slow.
I suspect Emacs thinks there are 101 frames open but for whatever
reason the OS hasn't opened them...
--
Alan Third
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#43973: 28.0.50; [NS] Two crashes on macOS
2020-10-13 19:09 ` Alan Third
@ 2020-10-14 8:07 ` Andrii Kolomoiets
2020-10-14 8:50 ` Andrii Kolomoiets
2020-10-24 10:35 ` Eli Zaretskii
2 siblings, 0 replies; 17+ messages in thread
From: Andrii Kolomoiets @ 2020-10-14 8:07 UTC (permalink / raw)
To: Alan Third; +Cc: 43973
Alan Third <alan@idiocy.org> writes:
> On Tue, Oct 13, 2020 at 10:35:28AM +0300, Andrii Kolomoiets wrote:
>> 1. M-x tool-bar-mode
>> 2. Evaluate
>> (let ((params `((parent-frame . ,(selected-frame))
>> (undecorated . t))))
>> (dotimes (_z 100)
>> (set-face-background 'internal-border "black"
>> (make-frame params))))
>> 3. Move the frame
>
> I can replicate this one, every time.
>
> + if (!face)
> + return;
>
> "fixes" it, but leaves Emacs in a bit of a strange state where I can
> only see one frame and it's incredibly slow.
It's because all child frames are undecorated. Just remove
'(undecorated . t)' from 'params' and you'll see all the frames.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#43973: 28.0.50; [NS] Two crashes on macOS
2020-10-13 19:09 ` Alan Third
2020-10-14 8:07 ` Andrii Kolomoiets
@ 2020-10-14 8:50 ` Andrii Kolomoiets
2020-10-24 10:35 ` Eli Zaretskii
2 siblings, 0 replies; 17+ messages in thread
From: Andrii Kolomoiets @ 2020-10-14 8:50 UTC (permalink / raw)
To: Alan Third; +Cc: 43973
Alan Third <alan@idiocy.org> writes:
> modified src/nsterm.m
> @@ -3048,6 +3048,9 @@ so some key presses (TAB) are swallowed by the system. */
> if (!face)
> face = FRAME_DEFAULT_FACE (f);
>
> + if (!face)
> + return;
> +
> ns_focus (f, &frame_rect, 1);
> [ns_lookup_indexed_color (NS_FACE_BACKGROUND (face), f) set];
> for (int i = 0; i < 4 ; i++)
>
>
> "fixes" it, but leaves Emacs in a bit of a strange state where I can
> only see one frame and it's incredibly slow.
Was working in Emacs under lldb for almost two days to catch my random
crash and here it is:
Process 78804 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xc0)
frame #0: 0x0000000100456e88 emacs`ns_clear_under_internal_border + 424
emacs`ns_clear_under_internal_border:
-> 0x100456e88 <+424>: movq 0xc0(%rax), %rdi
0x100456e8f <+431>: movq -0x38(%rbp), %rsi
0x100456e93 <+435>: callq 0x1004375a0 ; ns_lookup_indexed_color
0x100456e98 <+440>: movq 0xce5a1(%rip), %rsi ; "set"
Target 0: (emacs) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xc0)
* frame #0: 0x0000000100456e88 emacs`ns_clear_under_internal_border + 424
frame #1: 0x00000001000afe95 emacs`clear_garbaged_frames at xdisp.c:12110:17
Debug map object file for nsterm.o is ignored because it has changed, so
backtrace may be not so useful.
Going to work in Emacs under lldb with your patch applied to see if it
will crash again.
Thanks!
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#43973: 28.0.50; [NS] Two crashes on macOS
2020-10-13 19:09 ` Alan Third
2020-10-14 8:07 ` Andrii Kolomoiets
2020-10-14 8:50 ` Andrii Kolomoiets
@ 2020-10-24 10:35 ` Eli Zaretskii
2 siblings, 0 replies; 17+ messages in thread
From: Eli Zaretskii @ 2020-10-24 10:35 UTC (permalink / raw)
To: Alan Third; +Cc: 43973, andreyk.mad
> Date: Tue, 13 Oct 2020 20:09:46 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: 43973@debbugs.gnu.org
>
> > The second one is not reproducible every time:
> >
> > 1. M-x tool-bar-mode
> > 2. Evaluate
> > (let ((params `((parent-frame . ,(selected-frame))
> > (undecorated . t))))
> > (dotimes (_z 100)
> > (set-face-background 'internal-border "black"
> > (make-frame params))))
> > 3. Move the frame
>
> I can replicate this one, every time.
>
> I'm not sure exactly what's going on, but it's resulting in face ==
> NULL, so
>
> modified src/nsterm.m
> @@ -3048,6 +3048,9 @@ so some key presses (TAB) are swallowed by the system. */
> if (!face)
> face = FRAME_DEFAULT_FACE (f);
>
> + if (!face)
> + return;
> +
> ns_focus (f, &frame_rect, 1);
> [ns_lookup_indexed_color (NS_FACE_BACKGROUND (face), f) set];
> for (int i = 0; i < 4 ; i++)
>
>
> "fixes" it, but leaves Emacs in a bit of a strange state where I can
> only see one frame and it's incredibly slow.
Can you spot which code calls free_all_realized_faces in this case?
We could either try to prevent that, or call recompute_basic_faces,
then the behavior should be better, I think.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#43973: 28.0.50; [NS] Two crashes on macOS
2020-10-13 7:35 bug#43973: 28.0.50; [NS] Two crashes on macOS Andrii Kolomoiets
2020-10-13 13:00 ` Robert Pluim
2020-10-13 19:09 ` Alan Third
@ 2020-10-14 20:41 ` Alan Third
2020-10-14 21:01 ` Andrii Kolomoiets
2020-10-24 1:37 ` Win Treese
3 siblings, 1 reply; 17+ messages in thread
From: Alan Third @ 2020-10-14 20:41 UTC (permalink / raw)
To: Andrii Kolomoiets; +Cc: 43973
On Tue, Oct 13, 2020 at 10:35:28AM +0300, Andrii Kolomoiets wrote:
> (make-frame `((parent-frame . ,(selected-frame))
> (width . 0.5)
> (height . 0.5)
> (top . 0.5)
> (left . 0.5)))|
Out of interest, does the frame need to be smaller than default for
the crash to happen? For example if width is 1 does it still crash?
--
Alan Third
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#43973: 28.0.50; [NS] Two crashes on macOS
2020-10-14 20:41 ` Alan Third
@ 2020-10-14 21:01 ` Andrii Kolomoiets
2020-10-14 21:15 ` Alan Third
0 siblings, 1 reply; 17+ messages in thread
From: Andrii Kolomoiets @ 2020-10-14 21:01 UTC (permalink / raw)
To: Alan Third; +Cc: 43973
Alan Third <alan@idiocy.org> writes:
> On Tue, Oct 13, 2020 at 10:35:28AM +0300, Andrii Kolomoiets wrote:
>> (make-frame `((parent-frame . ,(selected-frame))
>> (width . 0.5)
>> (height . 0.5)
>> (top . 0.5)
>> (left . 0.5)))|
>
> Out of interest, does the frame need to be smaller than default for
> the crash to happen? For example if width is 1 does it still crash?
The frame must be small enough to not all the toolbar buttons fits the
toolbar:
(setq test-frame (make-frame `((parent-frame . ,(selected-frame))
(width . 41))))
The last button (isearch) is replaced by ">>".
There are no crash if '(width . 42)'.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#43973: 28.0.50; [NS] Two crashes on macOS
2020-10-14 21:01 ` Andrii Kolomoiets
@ 2020-10-14 21:15 ` Alan Third
2020-10-14 21:33 ` Andrii Kolomoiets
0 siblings, 1 reply; 17+ messages in thread
From: Alan Third @ 2020-10-14 21:15 UTC (permalink / raw)
To: Andrii Kolomoiets; +Cc: 43973
On Thu, Oct 15, 2020 at 12:01:17AM +0300, Andrii Kolomoiets wrote:
> Alan Third <alan@idiocy.org> writes:
>
> > On Tue, Oct 13, 2020 at 10:35:28AM +0300, Andrii Kolomoiets wrote:
> >> (make-frame `((parent-frame . ,(selected-frame))
> >> (width . 0.5)
> >> (height . 0.5)
> >> (top . 0.5)
> >> (left . 0.5)))|
> >
> > Out of interest, does the frame need to be smaller than default for
> > the crash to happen? For example if width is 1 does it still crash?
>
> The frame must be small enough to not all the toolbar buttons fits the
> toolbar:
>
> (setq test-frame (make-frame `((parent-frame . ,(selected-frame))
> (width . 41))))
>
> The last button (isearch) is replaced by ">>".
Funnily enough that ">>" is what I was looking at. I guess it's a
toolkit image and not something we provide with Emacs...?
> There are no crash if '(width . 42)'.
Can you try this:
modified src/nsmenu.m
@@ -1207,7 +1207,7 @@ - (BOOL) changed
enablement == prevEnablement ? NO : YES;
}
-- (void) addDisplayItemWithImage: (EmacsImage *)img
+- (void) addDisplayItemWithImage: (NSImage *)img
idx: (int)idx
tag: (int)tag
helpText: (const char *)help
modified src/nsterm.h
@@ -561,7 +561,7 @@ #define NS_DRAW_TO_BUFFER 1
- (void) clearActive;
- (void) clearAll;
- (BOOL) changed;
-- (void) addDisplayItemWithImage: (EmacsImage *)img
+- (void) addDisplayItemWithImage: (NSImage *)img
idx: (int)idx
tag: (int)tag
helpText: (const char *)help
--
Alan Third
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#43973: 28.0.50; [NS] Two crashes on macOS
2020-10-14 21:15 ` Alan Third
@ 2020-10-14 21:33 ` Andrii Kolomoiets
2021-01-02 18:25 ` Alan Third
0 siblings, 1 reply; 17+ messages in thread
From: Andrii Kolomoiets @ 2020-10-14 21:33 UTC (permalink / raw)
To: Alan Third; +Cc: 43973
Alan Third <alan@idiocy.org> writes:
>> The frame must be small enough to not all the toolbar buttons fits the
>> toolbar:
>>
>> (setq test-frame (make-frame `((parent-frame . ,(selected-frame))
>> (width . 41))))
>>
>> The last button (isearch) is replaced by ">>".
>
> Funnily enough that ">>" is what I was looking at. I guess it's a
> toolkit image and not something we provide with Emacs...?
>
>> There are no crash if '(width . 42)'.
>
> Can you try this:
Process 28381 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10c94fc8)
frame #0: 0x00007fff6fa97678 libobjc.A.dylib`objc_release + 24
libobjc.A.dylib`objc_release:
-> 0x7fff6fa97678 <+24>: testb $0x4, 0x20(%rax)
0x7fff6fa9767c <+28>: je 0x7fff6fa976e7 ; <+135>
0x7fff6fa9767e <+30>: movabsq $0x100000000000000, %rcx ; imm = 0x100000000000000
0x7fff6fa97688 <+40>: movabsq $0x40000000000000, %rdx ; imm = 0x40000000000000
Target 0: (emacs) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10c94fc8)
* frame #0: 0x00007fff6fa97678 libobjc.A.dylib`objc_release + 24
frame #1: 0x0000000100476338 emacs`-[EmacsImage dealloc](self=0x000000010178c650, _cmd="dealloc") at nsimage.m:286:3
frame #2: 0x00007fff6fa9ceb3 libobjc.A.dylib`objc_object::sidetable_release(bool) + 229
frame #3: 0x00007fff33e5a6e1 AppKit`-[NSMenuItem dealloc] + 108
frame #4: 0x00007fff340c83f8 AppKit`-[NSToolbarItem dealloc] + 110
frame #5: 0x00007fff36b7d2a5 CoreFoundation`__RELEASE_OBJECTS_IN_THE_ARRAY__ + 118
frame #6: 0x00007fff36b7d1e8 CoreFoundation`-[__NSArrayM dealloc] + 279
frame #7: 0x00007fff34227a99 AppKit`-[NSToolbarClippedItemsIndicator dealloc] + 84
frame #8: 0x00007fff6fab3054 libobjc.A.dylib`AutoreleasePoolPage::releaseUntil(objc_object**) + 134
frame #9: 0x00007fff6fa97dba libobjc.A.dylib`objc_autoreleasePoolPop + 175
frame #10: 0x00007fff36bdf335 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
frame #11: 0x00007fff36bdf267 CoreFoundation`__CFRunLoopDoObservers + 457
frame #12: 0x00007fff36bde805 CoreFoundation`__CFRunLoopRun + 874
frame #13: 0x00007fff36bdde3e CoreFoundation`CFRunLoopRunSpecific + 462
frame #14: 0x00007fff3580aabd HIToolbox`RunCurrentEventLoopInMode + 292
frame #15: 0x00007fff3580a6f4 HIToolbox`ReceiveNextEventCommon + 359
frame #16: 0x00007fff3580a579 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 64
frame #17: 0x00007fff33e50039 AppKit`_DPSNextEvent + 883
frame #18: 0x00007fff33e4e880 AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1352
frame #19: 0x00007fff33e4058e AppKit`-[NSApplication run] + 658
frame #20: 0x000000010043b9ba emacs`-[EmacsApp run](self=0x000000010152b3a0, _cmd="run") at nsterm.m:5768:9
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#43973: 28.0.50; [NS] Two crashes on macOS
2020-10-14 21:33 ` Andrii Kolomoiets
@ 2021-01-02 18:25 ` Alan Third
2021-01-02 22:03 ` Andrii Kolomoiets
0 siblings, 1 reply; 17+ messages in thread
From: Alan Third @ 2021-01-02 18:25 UTC (permalink / raw)
To: Andrii Kolomoiets; +Cc: 43973
[-- Attachment #1: Type: text/plain, Size: 763 bytes --]
On Thu, Oct 15, 2020 at 12:33:44AM +0300, Andrii Kolomoiets wrote:
> Alan Third <alan@idiocy.org> writes:
>
> >> The frame must be small enough to not all the toolbar buttons fits the
> >> toolbar:
> >>
> >> (setq test-frame (make-frame `((parent-frame . ,(selected-frame))
> >> (width . 41))))
> >>
> >> The last button (isearch) is replaced by ">>".
> >
> > Funnily enough that ">>" is what I was looking at. I guess it's a
> > toolkit image and not something we provide with Emacs...?
> >
> >> There are no crash if '(width . 42)'.
> >
> > Can you try this:
Can you please try the attached patch. It looks like NSToolbarItem
makes a copy of the image, but EmacsImage is not set up to create
copies of itself correctly.
--
Alan Third
[-- Attachment #2: 0001-Fix-crash-in-NS-toolbar-image-releasing-bug-43973.patch --]
[-- Type: text/plain, Size: 1195 bytes --]
From d111484d44744e3f68775a47b7f15ddf0d9b38c0 Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Sat, 2 Jan 2021 18:19:39 +0000
Subject: [PATCH] Fix crash in NS toolbar image releasing (bug#43973)
The toolbar fails to make a proper copy of EmacsImage objects, so
releasing the copy incorrectly released instance variables from the
original objects.
* src/nsimage.m ([EmacsImage copyWithZone:]): New function to enable
correct copying of EmacsImage.
---
src/nsimage.m | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/src/nsimage.m b/src/nsimage.m
index f0014b50b9..fa81a41a51 100644
--- a/src/nsimage.m
+++ b/src/nsimage.m
@@ -293,6 +293,18 @@ - (void)dealloc
}
+- (id)copyWithZone:(NSZone *)zone
+{
+ EmacsImage *copy = [super copyWithZone:zone];
+
+ copy->stippleMask = [stippleMask copyWithZone:zone];
+ copy->bmRep = [bmRep copyWithZone:zone];
+ copy->transform = [transform copyWithZone:zone];
+
+ return copy;
+}
+
+
/* Create image from monochrome bitmap. If both FG and BG are 0
(black), set the background to white and make it transparent. */
- (instancetype)initFromXBM: (unsigned char *)bits width: (int)w height: (int)h
--
2.29.2
^ permalink raw reply related [flat|nested] 17+ messages in thread
* bug#43973: 28.0.50; [NS] Two crashes on macOS
2021-01-02 18:25 ` Alan Third
@ 2021-01-02 22:03 ` Andrii Kolomoiets
2021-01-02 22:34 ` Alan Third
0 siblings, 1 reply; 17+ messages in thread
From: Andrii Kolomoiets @ 2021-01-02 22:03 UTC (permalink / raw)
To: Alan Third; +Cc: 43973
Alan Third <alan@idiocy.org> writes:
> On Thu, Oct 15, 2020 at 12:33:44AM +0300, Andrii Kolomoiets wrote:
>> Alan Third <alan@idiocy.org> writes:
>>
>> >> The frame must be small enough to not all the toolbar buttons fits the
>> >> toolbar:
>> >>
>> >> (setq test-frame (make-frame `((parent-frame . ,(selected-frame))
>> >> (width . 41))))
>> >>
>> >> The last button (isearch) is replaced by ">>".
>> >
>> > Funnily enough that ">>" is what I was looking at. I guess it's a
>> > toolkit image and not something we provide with Emacs...?
>> >
>> >> There are no crash if '(width . 42)'.
>> >
>> > Can you try this:
>
> Can you please try the attached patch. It looks like NSToolbarItem
> makes a copy of the image, but EmacsImage is not set up to create
> copies of itself correctly.
Since reporting that bug, I have updated my operating system and cannot
reproduce it on the latest Emacs version.
Toolbar items are now placed in the title bar. I've tried to reproduce
the bug (but with no luck) after switching to old toolbar items
placement with command:
defaults write -g NSWindowSupportsAutomaticInlineTitle -bool false
We need someone with the previous macos version to help with testing.
For me Emacs with your patch applied works fine.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#43973: 28.0.50; [NS] Two crashes on macOS
2021-01-02 22:03 ` Andrii Kolomoiets
@ 2021-01-02 22:34 ` Alan Third
0 siblings, 0 replies; 17+ messages in thread
From: Alan Third @ 2021-01-02 22:34 UTC (permalink / raw)
To: Andrii Kolomoiets; +Cc: 43973-done
On Sun, Jan 03, 2021 at 12:03:40AM +0200, Andrii Kolomoiets wrote:
>
> Since reporting that bug, I have updated my operating system and cannot
> reproduce it on the latest Emacs version.
>
> Toolbar items are now placed in the title bar. I've tried to reproduce
> the bug (but with no luck) after switching to old toolbar items
> placement with command:
>
> defaults write -g NSWindowSupportsAutomaticInlineTitle -bool false
>
> We need someone with the previous macos version to help with testing.
>
> For me Emacs with your patch applied works fine.
OK, thanks. It fixes, what is at the very least, a related crash for
me, so I'm going to assume it's the same problem and close this bug
report.
If anyone still sees this crash on master, please reopen the bug
report.
--
Alan Third
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#43973: 28.0.50; [NS] Two crashes on macOS
2020-10-13 7:35 bug#43973: 28.0.50; [NS] Two crashes on macOS Andrii Kolomoiets
` (2 preceding siblings ...)
2020-10-14 20:41 ` Alan Third
@ 2020-10-24 1:37 ` Win Treese
2020-10-24 16:59 ` Alan Third
3 siblings, 1 reply; 17+ messages in thread
From: Win Treese @ 2020-10-24 1:37 UTC (permalink / raw)
To: 43973
I got curious about what was going on with this bug after looking at other alloc/dealloc problems on the Mac, and I’m wondering if there is an initialization problem in setTranform:
The code is:
- (void)setTransform: (double[3][3]) m
{
transform = [[NSAffineTransform transform] retain];
NSAffineTransformStruct tm
= { m[0][0], m[0][1], m[1][0], m[1][1], m[2][0], m[2][1]};
[transform setTransformStruct:tm];
}
It seems to create a new NSAffineTransform object with the existing value of transform. I imagine that would be NULL the first time through. When the deallocation happens (the [transform dealloc] mentioned earlier in the thread, I think the following might happen:
[transform dealloc] essentially calls [NSAffineTransform dealloc], which then tries to dealloc the object it was initialized with, which was null, and it crashes there.
Could that be what’s going on?
- Win
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#43973: 28.0.50; [NS] Two crashes on macOS
2020-10-24 1:37 ` Win Treese
@ 2020-10-24 16:59 ` Alan Third
0 siblings, 0 replies; 17+ messages in thread
From: Alan Third @ 2020-10-24 16:59 UTC (permalink / raw)
To: Win Treese; +Cc: 43973
On Fri, Oct 23, 2020 at 09:37:43PM -0400, Win Treese wrote:
> I got curious about what was going on with this bug after looking at
> other alloc/dealloc problems on the Mac, and I’m wondering if there
> is an initialization problem in setTranform:
>
> The code is:
>
> - (void)setTransform: (double[3][3]) m
> {
> transform = [[NSAffineTransform transform] retain];
> NSAffineTransformStruct tm
> = { m[0][0], m[0][1], m[1][0], m[1][1], m[2][0], m[2][1]};
> [transform setTransformStruct:tm];
> }
>
> It seems to create a new NSAffineTransform object with the existing
> value of transform.
No, [NSAffineTransform transform] is a call to the class method
"transform", it's not actually a reference to the variable transform,
although I can see why that is confusing.
https://developer.apple.com/documentation/foundation/nsaffinetransform?language=objc
--
Alan Third
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2021-01-02 22:34 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-10-13 7:35 bug#43973: 28.0.50; [NS] Two crashes on macOS Andrii Kolomoiets
2020-10-13 13:00 ` Robert Pluim
2020-10-13 20:33 ` Alan Third
2020-10-14 10:46 ` Robert Pluim
2020-10-13 19:09 ` Alan Third
2020-10-14 8:07 ` Andrii Kolomoiets
2020-10-14 8:50 ` Andrii Kolomoiets
2020-10-24 10:35 ` Eli Zaretskii
2020-10-14 20:41 ` Alan Third
2020-10-14 21:01 ` Andrii Kolomoiets
2020-10-14 21:15 ` Alan Third
2020-10-14 21:33 ` Andrii Kolomoiets
2021-01-02 18:25 ` Alan Third
2021-01-02 22:03 ` Andrii Kolomoiets
2021-01-02 22:34 ` Alan Third
2020-10-24 1:37 ` Win Treese
2020-10-24 16:59 ` Alan Third
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.