bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#57751: 29.0.50; crash in GC


From: Sam Steingold
Subject: bug#57751: 29.0.50; crash in GC
Date: Wed, 14 Sep 2022 14:36:30 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin)

> * Gerd Möllmann <treq.zbryyznaa@tznvy.pbz> [2022-09-14 07:46:00 +0200]:
>
> Sam Steingold <sds@gnu.org> writes:
>
>> 2022-09-13 10:48:30.934108-0400 emacs[18589:5791720] 
>> SecTaskCopyDebugDescription: emacs[18589]/0#-1 LF=0
>> Process 18589 stopped
>> * thread #1, queue = 'com.apple.main-thread', stop reason =
>> EXC_BAD_ACCESS (code=1, address=0x7ff8c11d6f70)
>
> That's not so good.  It means the address sanitizer couldn't catch
> anything before Emacs crashed.
>
>>     frame #0: 0x00000001006dc4e5 emacs`symbol_marked_p(s=0x00007ff8c11d6f70) 
>> at alloc.c:4020:14
>>    4017 {
>>    4018   return pdumper_object_p (s)
>>    4019     ? pdumper_marked_p (s)
>> -> 4020     : s->u.s.gcmarkbit;
>>    4021 }
>>    4022
>>    4023 static void
>> Target 0: (emacs) stopped.
>
> Hm, it's a fake Lisp symbol this time.  Last time it was a fake float.
> Which fits the hypothesis of something writing "randomly" to the heap.  
>
> Or it could be uninitialized memory, maybe.

I _think_ that Tramp does something with a BAD FD and corrupts the
memory (see my previous message: tramp appears to be broken recently).

> - Does it also crash when you run emacs on a terminal (-nw)?  If not, it
>   could be a hint that the cuöprit is in the NS GUI code.

--8<---------------cut here---------------start------------->8---
(lldb) run -nw
There is a running process, kill it and restart?: [Y/n] y
Process 18589 exited with status = 9 (0x00000009) 
Process 53208 launched: '/Users/sdsg/src/emacs/trunk/src/emacs' (x86_64)
emacs(53208,0x101748600) malloc: nano zone abandoned due to inability to 
preallocate reserved vm space.
Process 53208 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGTTOU
    frame #0: 0x00007ff81575bec6 libsystem_kernel.dylib`__ioctl + 10
libsystem_kernel.dylib`__ioctl:
->  0x7ff81575bec6 <+10>: jae    0x7ff81575bed0            ; <+20>
    0x7ff81575bec8 <+12>: movq   %rax, %rdi
    0x7ff81575becb <+15>: jmp    0x7ff815759db9            ; cerror
    0x7ff81575bed0 <+20>: retq   
Target 0: (emacs) stopped.
--8<---------------cut here---------------end--------------->8---


> - Could you please see if it crashes consistently in different runs?
>   What I mean is that is crashes in the same function with the same
>   backtrace and the same pointer value of the symbol in frame#0?  I
>   guess I would quit LLDB between between runs, for no good reason
>   :-), just to make sure it's reproducible that way.

I restarted lldb and run Emacs.
This time I let it finish restoring desktop _completely_ before moving
the frame - it did __NOT__ crash. I moved the frame around, no crash.

Then I quit it and restarted and moved the frame while it was in the
process of re-creating *vc-dir* buffers.

--8<---------------cut here---------------start------------->8---
(lldb) run
Process 53726 launched: '/Users/sdsg/src/emacs/trunk/src/emacs' (x86_64)
emacs(53726,0x101748600) malloc: nano zone abandoned due to inability to 
preallocate reserved vm space.
2022-09-14 14:30:05.960741-0400 emacs[53726:6357538] SecTaskLoadEntitlements 
failed error=22 cs_flags=20, pid=53726
2022-09-14 14:30:05.960890-0400 emacs[53726:6357538] 
SecTaskCopyDebugDescription: emacs[53726]/0#-1 LF=0
2022-09-14 14:30:06.092509-0400 emacs[53726:6357538] SecTaskLoadEntitlements 
failed error=22 cs_flags=20, pid=53726
2022-09-14 14:30:06.092656-0400 emacs[53726:6357538] 
SecTaskCopyDebugDescription: emacs[53726]/0#-1 LF=0
2022-09-14 14:30:06.291206-0400 emacs[53726:6357538] SecTaskLoadEntitlements 
failed error=22 cs_flags=20, pid=53726
2022-09-14 14:30:06.291334-0400 emacs[53726:6357538] 
SecTaskCopyDebugDescription: emacs[53726]/0#-1 LF=0
2022-09-14 14:30:06.292448-0400 emacs[53726:6357538] SecTaskLoadEntitlements 
failed error=22 cs_flags=20, pid=53726
2022-09-14 14:30:06.292534-0400 emacs[53726:6357538] 
SecTaskCopyDebugDescription: emacs[53726]/0#-1 LF=0
Process 53726 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
(code=1, address=0x7ff8c11d2f50)
    frame #0: 0x00000001006dc4e5 emacs`symbol_marked_p(s=0x00007ff8c11d2f50) at 
alloc.c:4020:14
   4017 {
   4018   return pdumper_object_p (s)
   4019     ? pdumper_marked_p (s)
-> 4020     : s->u.s.gcmarkbit;
   4021 }
   4022
   4023 static void
Target 0: (emacs) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
(code=1, address=0x7ff8c11d2f50)
  * frame #0: 0x00000001006dc4e5 emacs`symbol_marked_p(s=0x00007ff8c11d2f50) at 
alloc.c:4020:14
    frame #1: 0x00000001006db869 emacs`process_mark_stack(base_sp=0) at 
alloc.c:6943:10
    frame #2: 0x00000001006d9a79 emacs`mark_object(obj=0x00007ff7bfee59b0) at 
alloc.c:7035:3
    frame #3: 0x000000010052bf20 emacs`mark_kboards at keyboard.c:13266:4
    frame #4: 0x00000001006d7adc emacs`garbage_collect at alloc.c:6187:3
    frame #5: 0x00000001006d70b6 emacs`maybe_garbage_collect at alloc.c:6090:5
    frame #6: 0x00000001008a6939 emacs`maybe_gc at lisp.h:5564:5
    frame #7: 0x0000000100892632 emacs`exec_byte_code(fun=0x00006210009589b5, 
args_template=770, nargs=3, args=0x000000010d002000) at bytecode.c:782:6
    frame #8: 0x00000001007980e7 
emacs`fetch_and_exec_byte_code(fun=0x000062100038356d, args_template=2953, 
nargs=11, args=0x00007ff7bfef2040) at eval.c:3101:10
    frame #9: 0x0000000100790587 emacs`funcall_lambda(fun=0x000062100038356d, 
nargs=11, arg_vector=0x00007ff7bfef2040) at eval.c:3173:9
    frame #10: 0x00000001007858e2 emacs`apply_lambda(fun=0x000062100038356d, 
args=0x00006290005dee03, count=(bytes = 1216)) at eval.c:3123:9
    frame #11: 0x0000000100772d3f emacs`eval_sub(form=0x00006290005dedf3) at 
eval.c:2564:12
    frame #12: 0x00000001008512f3 
emacs`readevalloop_eager_expand_eval(val=0x00006290005dedf3, 
macroexpand=0x0000000005208950) at lread.c:2154:13
    frame #13: 0x00000001008396e5 
emacs`readevalloop(readcharfun=0x0000621000952dd5, infile0=0x0000000000000000, 
sourcename=0x0000619002892a04, printflag=false, unibyte=0x0000000000000000, 
readfun=0x0000000000000000, start=0x0000000000000000, end=0x0000000000000000) 
at lread.c:2337:15
    frame #14: 0x000000010083af03 emacs`Feval_buffer(buffer=0x0000621000952dd5, 
printflag=0x0000000000000000, filename=0x0000619002892a04, 
unibyte=0x0000000000000000, do_allow_print=0x0000000000000030) at lread.c:2410:3
    frame #15: 0x000000010078f5c2 emacs`funcall_subr(subr=0x0000000100cc8320, 
numargs=5, args=0x000000010d001a70) at eval.c:3060:15
    frame #16: 0x00000001008928de emacs`exec_byte_code(fun=0x0000000106018325, 
args_template=257, nargs=1, args=0x000000010d001a78) at bytecode.c:809:14
    frame #17: 0x00000001007980e7 
emacs`fetch_and_exec_byte_code(fun=0x00000001061fae75, args_template=1282, 
nargs=4, args=0x00007ff7bfef6608) at eval.c:3101:10
    frame #18: 0x0000000100790587 emacs`funcall_lambda(fun=0x00000001061fae75, 
nargs=4, arg_vector=0x00007ff7bfef6608) at eval.c:3173:9
    frame #19: 0x000000010078e703 emacs`funcall_general(fun=0x00000001061fae75, 
numargs=4, args=0x00007ff7bfef6608) at eval.c:2964:12
    frame #20: 0x000000010077af9b emacs`Ffuncall(nargs=5, 
args=0x00007ff7bfef6600) at eval.c:3014:21
    frame #21: 0x00000001008365e2 emacs`call4(fn=0x0000000004f0d8a0, 
arg1=0x0000619002892a04, arg2=0x0000619002892a04, arg3=0x0000000000000030, 
arg4=0x0000000000000030) at lisp.h:3261:10
    frame #22: 0x0000000100830809 emacs`Fload(file=0x000061900282ef84, 
noerror=0x0000000000000030, nomessage=0x0000000000000030, 
nosuffix=0x0000000000000030, must_suffix=0x0000000000000000) at lread.c:1477:10
    frame #23: 0x000000010078f5c2 emacs`funcall_subr(subr=0x0000000100cc82c0, 
numargs=4, args=0x000000010d0019a0) at eval.c:3060:15
    frame #24: 0x00000001008928de emacs`exec_byte_code(fun=0x00006210000fabb5, 
args_template=256, nargs=0, args=0x000000010d0019a8) at bytecode.c:809:14
    frame #25: 0x00000001007980e7 
emacs`fetch_and_exec_byte_code(fun=0x00006210003ab0dd, args_template=0, 
nargs=0, args=0x00007ff7bfefa728) at eval.c:3101:10
    frame #26: 0x0000000100790587 emacs`funcall_lambda(fun=0x00006210003ab0dd, 
nargs=0, arg_vector=0x00007ff7bfefa728) at eval.c:3173:9
    frame #27: 0x000000010078e703 emacs`funcall_general(fun=0x00006210003ab0dd, 
numargs=0, args=0x00007ff7bfefa728) at eval.c:2964:12
    frame #28: 0x000000010077af9b emacs`Ffuncall(nargs=1, 
args=0x00007ff7bfefa720) at eval.c:3014:21
    frame #29: 0x000000010078dc4d emacs`funcall_nil(nargs=1, 
args=0x00007ff7bfefa720) at eval.c:2696:3
    frame #30: 0x000000010078dba8 emacs`run_hook_with_args(nargs=1, 
args=0x00007ff7bfefa720, funcall=(emacs`funcall_nil at eval.c:2695)) at 
eval.c:2873:14
    frame #31: 0x000000010078d5b4 emacs`Frun_hook_with_args(nargs=1, 
args=0x00007ff7bfefa720) at eval.c:2738:10
    frame #32: 0x000000010078d524 emacs`run_hook(hook=0x00006210003ab0dd) at 
eval.c:2886:3
    frame #33: 0x000000010078d3fd emacs`Frun_hooks(nargs=2, 
args=0x000000010d0018a8) at eval.c:2720:5
    frame #34: 0x000000010078ff1c emacs`funcall_subr(subr=0x0000000100cc3dc0, 
numargs=2, args=0x000000010d0018a8) at eval.c:3079:9
    frame #35: 0x00000001008928de emacs`exec_byte_code(fun=0x00000001061fdb8d, 
args_template=512, nargs=2, args=0x000000010d001940) at bytecode.c:809:14
    frame #36: 0x00000001007980e7 
emacs`fetch_and_exec_byte_code(fun=0x00000001061bfb75, args_template=0, 
nargs=0, args=0x00007ff7bfefdac0) at eval.c:3101:10
    frame #37: 0x0000000100790587 emacs`funcall_lambda(fun=0x00000001061bfb75, 
nargs=0, arg_vector=0x00007ff7bfefdac0) at eval.c:3173:9
    frame #38: 0x00000001007858e2 emacs`apply_lambda(fun=0x00000001061bfb75, 
args=0x0000000000000000, count=(bytes = 128)) at eval.c:3123:9
    frame #39: 0x0000000100772d3f emacs`eval_sub(form=0x0000000106abe8bb) at 
eval.c:2564:12
    frame #40: 0x0000000100782a67 emacs`Feval(form=0x0000000106abe8bb, 
lexical=0x0000000000000000) at eval.c:2375:28
    frame #41: 0x000000010052c40b emacs`top_level_2 at keyboard.c:1141:10
    frame #42: 0x000000010077d829 
emacs`internal_condition_case(bfun=(emacs`top_level_2 at keyboard.c:1140), 
handlers=0x0000000000000090, hfun=(emacs`cmd_error at keyboard.c:935)) at 
eval.c:1497:25
    frame #43: 0x000000010052c300 emacs`top_level_1(ignore=0x0000000000000000) 
at keyboard.c:1149:5
    frame #44: 0x000000010077bb4d emacs`internal_catch(tag=0x000000000000ea00, 
func=(emacs`top_level_1 at keyboard.c:1146), arg=0x0000000000000000) at 
eval.c:1220:25
    frame #45: 0x00000001004e6984 emacs`command_loop at keyboard.c:1109:2
    frame #46: 0x00000001004e6496 emacs`recursive_edit_1 at keyboard.c:719:9
    frame #47: 0x00000001004e737f emacs`Frecursive_edit at keyboard.c:802:3
    frame #48: 0x00000001004debe6 emacs`main(argc=1, argv=0x00007ff7bfeff220) 
at emacs.c:2517:3
    frame #49: 0x00000001016cd52e dyld`start + 462
(lldb) f 3
frame #3: 0x000000010052bf20 emacs`mark_kboards at keyboard.c:13266:4
   13263                  mark_object (event->ie.x);
   13264                  mark_object (event->ie.y);
   13265                  mark_object (event->ie.frame_or_window);
-> 13266                  mark_object (event->ie.arg);
   13267
   13268                  /* This should never be allocated for a single event, 
but
   13269                     mark it anyway in the situation where the list of 
devices
(lldb) p *event
(buffered_input_event) $0 = {
  kind = MOVE_FRAME_EVENT
  ie = {
    kind = MOVE_FRAME_EVENT
    part = scroll_bar_nowhere
    code = 0
    modifiers = 801101
    x = 0x00000000000006ea
    y = 0xfffffffffffff78a
    timestamp = 0
    frame_or_window = 0x00006210000d9135
    arg = 0x00007ff7bfee59b0
    device = 0x0000000102211ff0
  }
}
(lldb) 
--8<---------------cut here---------------end--------------->8---

looks consistent with the previous crash.

> - I think you mentioned that the crashes started not so long ago?  Do
>   you perhaps know a commit which is still "good"?  Or maybe a time,
>   like 4 weeks ago, or so?  We would need a good commit for git bisect
>   anyway.

I am "pretty sure" that 2 weeks ago it was good.

> (If I'm trying the be too "helpful", please just tekk ne.  I Know that
> I'm sometimes doing that.  No problem.)

You are very helpful, and I appreciate your attention!

Thank you very much!

-- 
Sam Steingold (https://aphar.dreamwidth.org/) on darwin Ns 10.3.2113
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://www.dhimmitude.org https://thereligionofpeace.com https://camera.org
A slave dreams not of Freedom, but of owning his own slaves.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]