From: Yuan Fu <casouri@gmail.com>
To: Mickey Petersen <mickey@masteringemacs.org>
Cc: eliz@gnu.org, 60237@debbugs.gnu.org
Subject: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node
Date: Fri, 24 Feb 2023 15:29:15 -0800 [thread overview]
Message-ID: <9310F6C6-8B17-41D5-BF5D-E116910D646E@gmail.com> (raw)
In-Reply-To: <87o7rx7xml.fsf@masteringemacs.org>
Yuan Fu <casouri@gmail.com> writes:
> Mickey Petersen <mickey@masteringemacs.org> writes:
>
>> Yuan Fu <casouri@gmail.com> writes:
>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>>>> From: Mickey Petersen <mickey@masteringemacs.org>
>>>>> 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]
next prev parent reply other threads:[~2023-02-24 23:29 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-21 12:24 bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node Mickey Petersen
2022-12-24 7:23 ` Eli Zaretskii
2022-12-24 9:20 ` Yuan Fu
2022-12-29 14:21 ` Mickey Petersen
2023-02-24 23:22 ` Yuan Fu
2023-02-25 7:13 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-25 7:51 ` Eli Zaretskii
2023-02-26 2:01 ` Yuan Fu
2023-02-26 2:37 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-26 6:18 ` Eli Zaretskii
2023-02-26 6:14 ` Eli Zaretskii
2023-02-26 15:16 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-28 14:00 ` Eli Zaretskii
2023-03-01 4:07 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-01 13:27 ` Eli Zaretskii
2023-03-01 14:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-01 15:51 ` Eli Zaretskii
2023-03-01 17:39 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-04 12:21 ` Eli Zaretskii
2023-03-08 16:34 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-10 18:28 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-10 20:56 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-11 6:45 ` Eli Zaretskii
2023-03-11 17:45 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-10 23:52 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-11 2:41 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-11 3:29 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-11 3:38 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-02 5:53 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-02 20:24 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-26 9:41 ` Mickey Petersen
2023-02-27 0:34 ` Yuan Fu
2023-02-27 8:22 ` Mickey Petersen
2023-02-27 9:05 ` Yuan Fu
2023-02-27 14:29 ` Mickey Petersen
2023-02-27 22:37 ` Yuan Fu
2023-02-27 22:45 ` Dmitry Gutov
2023-02-24 23:29 ` Yuan Fu [this message]
2023-02-25 7:55 ` Eli Zaretskii
2023-02-26 2:02 ` Yuan Fu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9310F6C6-8B17-41D5-BF5D-E116910D646E@gmail.com \
--to=casouri@gmail.com \
--cc=60237@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=mickey@masteringemacs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this 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).