Subject: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node

From: Yuan Fu <[email-masked]>
Date: Fri, 24 Feb 2023 15:29:15 -0800

Yuan Fu <[email-masked]> writes:

> Mickey Petersen <[email-masked]> writes:
>
>> Yuan Fu <[email-masked]> writes:
>>
>>> Eli Zaretskii <[email-masked]> writes:
>>>
>>>>> From: Mickey Petersen <[email-masked]>
>>>>> Date: Wed, 21 Dec 2022 12:24:34 +0000
>>>>
>>>> Yuan, can you look into this?  The crash is in tree-sitter, so maybe
>>>> it isn't our bug, but I'd like to be sure.  And even if it is a
>>>> tree-sitter bug, maybe we can work around it to prevent Emacs from
>>>> crashing?
>>>
>>> Absolutely.
>>>
>>>>> Happens in emacs -Q (after loading some simple elisp code that uses treesit.el) and consistently and repeatedly.
>>>>>
>>>>>
>>>>> Here's the elisp. When I edebug it I can step and view all the
>>>>> variables and expressions I like. The `combobulate-' functions are
>>>>> widely used in the library and pose no issues anywhere else and do
>>>>> nothing more than fetch nodes via tree sitter. It is only this bit of
>>>>> code that blows up, and then only when invoked inside a python
>>>>> string.
>>>
>>> It would be nice if you can make a reproduce recipe. Judging from the
>>> backtrace, you can probably trigger it by printing the node with print
>>> or princ.  And does it trigger on all python strings? Or some specific
>>> string in some specific python source?
>>>
>>
>> This issue seems entirely related to `M-x treesit-explore-mode` (and
>> possibly the inspect variant also) though it is hard to reproduce
>> reliably. I get either crashes or hangs, depending on whether I have
>> edebug on or not.
>>
>> Thrown errors seem to be the common denominator?
>
> I’m stumbled on a reliably way to trigger a crash, of possibly the same cause as
> this one, by enabling the profiler and M-x garbage-collect in a
> tree-sitter mode on Mac. I tried to reproduce this on Linux but with no
> success.
>
> I was also able to trigger infinite loop by the same recipe on time, but I
> didn’t run that session under lldb. Anyway, we can focus on the crash
> first.

Maybe it will help us understand the problem better, so here is the
backtrace for the infinite loop. I’m not sure why treesit_delete_parser
would trigger gc, as it just calls two tree_sitter functions:

void
treesit_delete_parser (struct Lisp_TS_Parser *lisp_parser)
{
  ts_tree_delete (lisp_parser->tree);
  ts_parser_delete (lisp_parser->parser);
}

Date/Time:        2023-02-24 15:08:13.620 -0800
End time:         2023-02-24 15:09:53.381 -0800
OS Version:       macOS 13.2.1 (Build 22D68)
Architecture:     x86_64h
Report Version:   40
Incident Identifier: B9F9C8A6-5293-4B70-935A-FAB1EF623EB2

Data Source:      Stackshots
Shared Cache:     57815A20-AF2C-3B56-9006-23ABDE7962B0 slid base address 0x7ff81a27a000, slide 0x1a27a000 (System Primary)
Shared Cache:     E1E267C5-FE0B-3ED9-86BE-E4F329F01460 slid base address 0x7ff818076000, slide 0x18076000 (DriverKit)

Command:          emacs
Path:             /Users/USER/*/emacs
Architecture:     x86_64
Parent:           fish [11593] [unique pid 110818]
Responsible:      iTerm2 [1312]
PID:              11610
Time Since Fork:  186s

Event:            hang
Duration:         99.76s
Duration Sampled: 4.20s (process was unresponsive for 96 seconds before sampling)
Steps:            42 (100ms sampling interval)

Hardware model:   MacBookPro16,3
Active cpus:      8
HW page size:     4096
VM page size:     4096

Time Since Boot:  259463s
Time Awake Since Boot: 136664s
Time Since Wake:  1506s

Fan speed:        4411 rpm -> 4591 (+180)
Total CPU Time:   8.453s (31.1G cycles, 29.7G instructions, 1.05c/i)
Advisory levels:  Battery -> 3, User -> 2, ThermalPressure -> 1, Combined -> 2
Free disk space:  65.61 GB/465.63 GB, low space threshold 3072 MB
Vnodes Available: 73.05% (192242/263168)

Preferred User Language: en-US, zh-Hans-US
Country Code:     US
Keyboards:        ABC
OS Cryptex File Extents: 2417

--------------------------------------------------
Timeline format: stacks are sorted chronologically
Use -i and -heavy to re-report with count sorting
--------------------------------------------------

Heaviest stack for the main thread of the target process:
  42  start + 2432 (dyld + 25360) [0x7ff81a314310]
  42  main + 7399 (emacs.c:2529,3 in emacs + 1429879) [0x10fc30177]
  42  Frecursive_edit + 306 (keyboard.c:794,3 in emacs + 1442642) [0x10fc33352]
  42  recursive_edit_1 + 255 (keyboard.c:711,9 in emacs + 1441247) [0x10fc32ddf]
  42  command_loop + 282 (keyboard.c:1102,2 in emacs + 1441754) [0x10fc32fda]
  42  internal_catch + 67 (eval.c:1197,25 in emacs + 2399059) [0x10fd1cb53]
  42  command_loop_2 + 35 (keyboard.c:1124,11 in emacs + 1444963) [0x10fc33c63]
  42  internal_condition_case + 136 (eval.c:1474,25 in emacs + 2401224) [0x10fd1d3c8]
  42  command_loop_1 + 2627 (keyboard.c:1494,13 in emacs + 1447651) [0x10fc346e3]
  42  call1 + 60 (lisp.h:3247,10 in emacs + 1464844) [0x10fc38a0c]
  42  Ffuncall + 324 (eval.c:2995,21 in emacs + 2397364) [0x10fd1c4b4]
  42  funcall_general + 279 (eval.c:2945,12 in emacs + 2416807) [0x10fd210a7]
  42  funcall_lambda + 385 (eval.c:3153,9 in emacs + 2418625) [0x10fd217c1]
  42  fetch_and_exec_byte_code + 87 (eval.c:3081,10 in emacs + 2432631) [0x10fd24e77]
  42  exec_byte_code + 3739 (bytecode.c:809,14 in emacs + 2817595) [0x10fd82e3b]
  42  funcall_subr + 401 (eval.c:3038,15 in emacs + 2417601) [0x10fd213c1]
  42  Fcall_interactively + 1057 (callint.c:342,36 in emacs + 2363633) [0x10fd140f1]
  42  Fapply + 2348 (eval.c:2666,24 in emacs + 2414108) [0x10fd2061c]
  42  Ffuncall + 324 (eval.c:2995,21 in emacs + 2397364) [0x10fd1c4b4]
  42  funcall_general + 197 (eval.c:2941,12 in emacs + 2416725) [0x10fd21055]
  42  funcall_subr + 810 (eval.c:3059,9 in emacs + 2418010) [0x10fd2155a]
  42  Ffuncall_interactively + 47 (callint.c:250,32 in emacs + 2362479) [0x10fd13c6f]
  42  Ffuncall + 324 (eval.c:2995,21 in emacs + 2397364) [0x10fd1c4b4]
  42  funcall_general + 279 (eval.c:2945,12 in emacs + 2416807) [0x10fd210a7]
  42  funcall_lambda + 385 (eval.c:3153,9 in emacs + 2418625) [0x10fd217c1]
  42  fetch_and_exec_byte_code + 87 (eval.c:3081,10 in emacs + 2432631) [0x10fd24e77]
  42  exec_byte_code + 3338 (bytecode.c:782,6 in emacs + 2817194) [0x10fd82caa]
  42  maybe_gc + 26 (lisp.h:5591,5 in emacs + 2837482) [0x10fd87bea]
  42  maybe_garbage_collect + 38 (alloc.c:6107,5 in emacs + 2144006) [0x10fcde706]
  42  garbage_collect + 999 (alloc.c:6262,3 in emacs + 2145127) [0x10fcdeb67]
  42  gc_sweep + 39 (alloc.c:7430,3 in emacs + 2148215) [0x10fcdf777]
  42  sweep_vectors + 297 (alloc.c:3254,5 in emacs + 2172105) [0x10fce54c9]
  42  cleanup_vector + 523 (alloc.c:3179,5 in emacs + 2173979) [0x10fce5c1b]
  42  treesit_delete_parser + 25 (treesit.c:1182,3 in emacs + 3175289) [0x10fdda379]
  42  ts_tree_delete + 44 (libtree-sitter.0.0.dylib + 114692) [0x110942004]
  42  ts_subtree_release + 158 (libtree-sitter.0.0.dylib + 102601) [0x11093f0c9]
  42  xmalloc + 77 (alloc.c:760,3 in emacs + 2117229) [0x10fcd7e6d]
  42  malloc_probe + 93 (profiler.c:509,3 in emacs + 3146093) [0x10fdd316d]
  42  record_backtrace + 95 (profiler.c:169,19 in emacs + 3146207) [0x10fdd31df]
  42  hash_lookup + 90 (fns.c:4693,44 in emacs + 2505546) [0x10fd36b4a]
  42  ??? [0x7fa1909ed180]
  42  _sigtramp + 29 (libsystem_platform.dylib + 15389) [0x7ff81a671c1d]
  42  deliver_fatal_thread_signal + 26 (sysdep.c:1795,3 in emacs + 1650762) [0x10fc6604a]
  42  deliver_thread_signal + 137 (sysdep.c:1775,3 in emacs + 1662777) [0x10fc68f39]
  42  handle_fatal_signal + 24 (sysdep.c:1783,3 in emacs + 1662632) [0x10fc68ea8]
  42  terminate_due_to_signal + 192 (emacs.c:447,11 in emacs + 3863584) [0x10fe82420]
  42  shut_down_emacs + 489 (emacs.c:2991,3 in emacs + 1422313) [0x10fc2e3e9]
  42  Fdo_auto_save + 309 (fileio.c:6042,18 in emacs + 1894389) [0x10fca17f5]
  42  Fexpand_file_name + 110 (fileio.c:956,13 in emacs + 1841918) [0x10fc94afe]
  42  Ffind_file_name_handler + 331 (fileio.c:324,24 in emacs + 1830395) [0x10fc91dfb]
  42  fast_string_match + 55 (lisp.h:4768,10 in emacs + 1831287) [0x10fc92177]
  42  fast_string_match_internal + 94 (search.c:487,7 in emacs + 1988174) [0x10fcb864e]
  42  compile_pattern + 599 (search.c:235,4 in emacs + 1988967) [0x10fcb8967]
  42  compile_pattern_1 + 331 (search.c:121,18 in emacs + 2021755) [0x10fcc097b]
  42  rpl_re_compile_pattern + 73 (regex-emacs.c:5170,9 in emacs + 2062489) [0x10fcca899]
  42  regex_compile + 133 (regex-emacs.c:1768,25 in emacs + 2062693) [0x10fcca965]
  42  xmalloc + 77 (alloc.c:760,3 in emacs + 2117229) [0x10fcd7e6d]
  42  malloc_probe + 93 (profiler.c:509,3 in emacs + 3146093) [0x10fdd316d]
  42  record_backtrace + 95 (profiler.c:169,19 in emacs + 3146207) [0x10fdd31df]
  42  hash_lookup + 90 (fns.c:4693,44 in emacs + 2505546) [0x10fd36b4a]
  42  ASIZE + 45 (lisp.h:1768,3 in emacs + 2442877) [0x10fd2767d]
*37  hndl_alltraps + 95 (kernel + 694399) [0xffffff800038587f]
*22  user_trap + 1218 (kernel + 2542418) [0xffffff8000548b52]
*21  exception_triage_thread + 490 (kernel + 1119322) [0xffffff80003ed45a]
*15  exception_deliver + 2172 (kernel + 1117868) [0xffffff80003eceac]
*15  mach_exception_raise + 265 (kernel + 1631513) [0xffffff800046a519]
*5   kernel_mach_msg_rpc + 689 (kernel + 1139009) [0xffffff80003f2141]
*4   ipc_port_adjust_special_reply_port_locked + 1170 (kernel + 989010) [0xffffff80003cd752]
*2   ipc_port_send_turnstile_complete + 213 (kernel + 989509) [0xffffff80003cd945]
*2   mpsc_daemon_enqueue + 177 (kernel + 1240465) [0xffffff800040ad91]
*2   ??? (kernel + 1548050) [0xffffff8000455f12]