bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code

bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code

[mail]

[-- Attachment #1: Type: text/plain, Size: 854 bytes --]

Code in attached file cause Emacs to hang and memory leak infinitely
while editing. Try to open this code in elixir-ts-mode and move cursor
on line 6 (between <:loading>  </:loading>) and type char by char:

<.some_component a={

(for some reason it does not happen with electric-pair-mode when {}
inserted automatically).

I am able to reproduce this with -Q on few different machines (Linux and
MacOS) and Emacs 29, 30.0.5 and current HEAD.

C-g does nothing (including with debug-on-quit and sending SIGUSR2)

At the same time I can't reproduce this in other tree-sitter based editors.

I got this sample code sample from elixir-ts-mode repo but now it's moved
to the Emacs core so seems to be out of scope of Github repo issues.

Attaching samle code and LLDB backtrace. 
Also attaching report from built-in MacOS crash reporting tool just in case.


[-- Attachment #2: code.ex --]
[-- Type: application/octet-stream, Size: 1340 bytes --]

defmodule CoreWeb.Components.Feedback.Create.Stepper do
  def conditional_stepper_item(assigns) do
    ~H"""
    <.async_result :let={value} assign={@result}>
      <:loading>

      </:loading>
    </.async_result>
    """
  end

  def selected_stepper_item(assigns) do
    ~H"""
    <li>
      <span>
        <Icons.from_name name={@icon} solid class="w-3.5 h-3.5 text-gray-500 dark:text-gray-400" />
      </span>
      <h3 class="font-medium leading-tight"><%= @title %></h3>
      <p class="text-sm truncate"><%= @description %></p>
    </li>
    """
  end

  attr :title, :string, required: true
  attr :description, :string, required: true

  attr :icon, :atom, required: true

  attr :event, :string, default: nil

  attr :target, CID, required: true

  def stepper_item(assigns) do
    ~H"""
    <li class="mb-10 ps-6 pr-2 hover:bg-gray-200 rounded-lg cursor-pointer" phx-click={@event} phx-target={@target}>
      <span class="absolute flex items-center justify-center w-8 h-8 bg-gray-100 rounded-full -start-4 ring-4 ring-white dark:ring-gray-900 dark:bg-gray-700">
        <Icons.from_name name={@icon} solid class="w-3.5 h-3.5 text-gray-500 dark:text-gray-400" />
      </span>
      <h3 class="font-medium leading-tight"><%= @title %></h3>
      <p class="text-sm truncate"><%= @description %></p>
    </li>
    """
  end
end

[-- Attachment #3: backtrace --]
[-- Type: application/octet-stream, Size: 5779 bytes --]

* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00000001870df6d8 libsystem_malloc.dylib`nanov2_find_block_and_allocate + 392
    frame #1: 0x00000001870fd210 libsystem_malloc.dylib`nanov2_allocate_outlined + 252
    frame #2: 0x00000001022434d4 Emacs`xmalloc + 20
    frame #3: 0x0000000103175cec libtree-sitter.0.dylib`stack__iter + 116
    frame #4: 0x000000010317c928 libtree-sitter.0.dylib`ts_parser__reduce + 92
    frame #5: 0x000000010316d73c libtree-sitter.0.dylib`ts_parser_parse + 5204
    frame #6: 0x00000001022e07e4 Emacs`Ftreesit_parser_root_node + 176
    frame #7: 0x000000010226612c Emacs`Ffuncall + 316
    frame #8: 0x000000010227543c Emacs`mapcar1 + 352
    frame #9: 0x0000000102275684 Emacs`Fmapcar + 232
    frame #10: 0x0000000129ec02c4 treesit-37439c61-f92dd089.eln`F747265657369742d666f6e742d6c6f636b2d666f6e746966792d726567696f6e_treesit_font_lock_fontify_region_0 + 248
    frame #11: 0x000000010226612c Emacs`Ffuncall + 316
    frame #12: 0x00000001092c5258 font-lock-895216f6-19836891.eln`F666f6e742d6c6f636b2d666f6e746966792d73796e746163746963616c6c792d726567696f6e_font_lock_fontify_syntactically_region_0 + 88
    frame #13: 0x000000010226612c Emacs`Ffuncall + 316
    frame #14: 0x00000001092c3258 font-lock-895216f6-19836891.eln`F666f6e742d6c6f636b2d64656661756c742d666f6e746966792d726567696f6e_font_lock_default_fontify_region_0 + 972
    frame #15: 0x000000010226612c Emacs`Ffuncall + 316
    frame #16: 0x00000001092c20ac font-lock-895216f6-19836891.eln`F666f6e742d6c6f636b2d666f6e746966792d726567696f6e_font_lock_fontify_region_0 + 140
    frame #17: 0x00000001022a83b4 Emacs`exec_byte_code + 2528
    frame #18: 0x000000010226612c Emacs`Ffuncall + 316
    frame #19: 0x0000000102269fa0 Emacs`run_hook_wrapped_funcall + 28
    frame #20: 0x0000000102269e08 Emacs`run_hook_with_args + 288
    frame #21: 0x0000000109304ce4 jit-lock-8a988e43-faf4eb64.eln`F6a69742d6c6f636b2d2d72756e2d66756e6374696f6e73_jit_lock__run_functions_0 + 196
    frame #22: 0x000000010226612c Emacs`Ffuncall + 316
    frame #23: 0x0000000109305068 jit-lock-8a988e43-faf4eb64.eln`F6a69742d6c6f636b2d666f6e746966792d6e6f77_jit_lock_fontify_now_0 + 640
    frame #24: 0x000000010226612c Emacs`Ffuncall + 316
    frame #25: 0x0000000109304a20 jit-lock-8a988e43-faf4eb64.eln`F6a69742d6c6f636b2d66756e6374696f6e_jit_lock_function_0 + 576
    frame #26: 0x000000010226612c Emacs`Ffuncall + 316
    frame #27: 0x0000000102268450 Emacs`internal_condition_case_n + 120
    frame #28: 0x000000010215d984 Emacs`dsafe__call + 156
    frame #29: 0x0000000102178d9c Emacs`handle_fontified_prop + 852
    frame #30: 0x0000000102177f70 Emacs`handle_stop + 116
    frame #31: 0x000000010217ad40 Emacs`next_element_from_buffer + 232
    frame #32: 0x000000010214eb4c Emacs`get_next_display_element + 72
    frame #33: 0x000000010216207c Emacs`display_line + 912
    frame #34: 0x0000000102187b24 Emacs`redisplay_window + 21184
    frame #35: 0x0000000102181d18 Emacs`redisplay_window_1 + 44
    frame #36: 0x0000000102268314 Emacs`internal_condition_case_1 + 100
    frame #37: 0x000000010215bbdc Emacs`redisplay_internal + 2496
    frame #38: 0x00000001021f23fc Emacs`read_char + 2892
    frame #39: 0x00000001021efd18 Emacs`read_key_sequence + 1100
    frame #40: 0x00000001021ee564 Emacs`command_loop_1 + 708
    frame #41: 0x0000000102268288 Emacs`internal_condition_case + 96
    frame #42: 0x00000001021ee28c Emacs`command_loop_2 + 52
    frame #43: 0x0000000102267af4 Emacs`internal_catch + 88
    frame #44: 0x000000010233077c Emacs`command_loop.cold.1 + 88
    frame #45: 0x00000001021edb94 Emacs`command_loop + 156
    frame #46: 0x00000001021eda44 Emacs`recursive_edit_1 + 168
    frame #47: 0x00000001021edd2c Emacs`Frecursive_edit + 264
    frame #48: 0x00000001021ecd20 Emacs`main + 7052
    frame #49: 0x0000000186f490e0 dyld`start + 2360
  thread #2, name = 'gmain'
    frame #0: 0x00000001872949d4 libsystem_kernel.dylib`__select + 8
    frame #1: 0x00000001035c833c libglib-2.0.0.dylib`g_poll + 424
    frame #2: 0x00000001035b9468 libglib-2.0.0.dylib`g_main_context_iterate_unlocked + 296
    frame #3: 0x00000001035b9530 libglib-2.0.0.dylib`g_main_context_iteration + 60
    frame #4: 0x00000001035ba764 libglib-2.0.0.dylib`glib_worker_main + 48
    frame #5: 0x00000001035dfb68 libglib-2.0.0.dylib`g_thread_proxy + 68
    frame #6: 0x00000001872ca034 libsystem_pthread.dylib`_pthread_start + 136
  thread #3
    frame #0: 0x000000018728fb4c libsystem_kernel.dylib`__pselect + 8
    frame #1: 0x000000018728fa24 libsystem_kernel.dylib`pselect$DARWIN_EXTSN + 64
    frame #2: 0x00000001023000bc Emacs`-[EmacsApp fd_handler:] + 184
    frame #3: 0x00000001884a8fb4 Foundation`__NSThread__start__ + 716
    frame #4: 0x00000001872ca034 libsystem_pthread.dylib`_pthread_start + 136
  thread #4, name = 'com.apple.NSEventThread'
    frame #0: 0x0000000187289874 libsystem_kernel.dylib`mach_msg2_trap + 8
    frame #1: 0x000000018729bcf0 libsystem_kernel.dylib`mach_msg2_internal + 80
    frame #2: 0x00000001872924b0 libsystem_kernel.dylib`mach_msg_overwrite + 476
    frame #3: 0x0000000187289bf8 libsystem_kernel.dylib`mach_msg + 24
    frame #4: 0x00000001873a7bf4 CoreFoundation`__CFRunLoopServiceMachPort + 160
    frame #5: 0x00000001873a64bc CoreFoundation`__CFRunLoopRun + 1208
    frame #6: 0x00000001873a59ac CoreFoundation`CFRunLoopRunSpecific + 608
    frame #7: 0x000000018acac510 AppKit`_NSEventThread + 144
    frame #8: 0x00000001872ca034 libsystem_pthread.dylib`_pthread_start + 136
  thread #5
    frame #0: 0x000000018728b524 libsystem_kernel.dylib`__workq_kernreturn + 8
  thread #6
    frame #0: 0x000000018728b524 libsystem_kernel.dylib`__workq_kernreturn + 8
  thread #7
    frame #0: 0x0000000000000000

[-- Attachment #4: report --]
[-- Type: application/octet-stream, Size: 18231 bytes --]

Date/Time: 2024-08-29 06:49:50.086 +0400
End time: 2024-08-29 06:50:17.600 +0400
OS Version: macOS 14.2.1 (Build 23C71)
Architecture: arm64e
Report Version: 44
Incident Identifier: 550F07B4-4CFD-4E27-84F8-1D66070D7537

Data Source: Stackshots
Shared Cache: F9DDD844-7F3F-34BD-BE29-F0C72D5E5449 slid base address 0x186e8c000, slide 0x6e8c000 (System Primary)
Shared Cache: 2BF5B417-CD87-34D6-A876-2BBD0F25330F slid base address 0x1e416c000, slide 0x6416c000 (DriverKit)
Shared Cache: AA32606F-3F8A-36DC-89AB-9C1BD7BF3104 slid base address 0x7ff80d72c000, slide 0xd72c000 (Rosetta)

Command: Emacs
Path: /opt/homebrew/\*/Emacs.app/Contents/MacOS/Emacs
Identifier: org.gnu.Emacs
Version: Version 30.0.50 (9.0)
Codesigning ID: temacs-555549440d1331b714183a9c960c6f20fd7b8ce2
Is First Party: No
Architecture: arm64
Parent: zsh [37889] [unique pid 3906475]
Responsible: Terminal [29051] [unique pid 1417380]
PID: 42099
Time Since Fork: 51s

Event: hang
Duration: 27.51s
Duration Sampled: 1.60s (process was unresponsive for 26 seconds before sampling)
Steps: 16 (100ms sampling interval)

Hardware model: MacBookPro18,3
Active cpus: 10
HW page size: 16384
VM page size: 16384

Time Since Boot: 1995070s
Time Awake Since Boot: 1875793s
Time Since Wake: 1414762s

Fan speed: 2307 rpm
Total CPU Time: 7.770s (21.0G cycles, 62.0G instructions, 0.34c/i)
Advisory levels: Battery -> 3, User -> 2, ThermalPressure -> 0, Combined -> 2
Free disk space: 354.26 MB/460.43 GB, low space threshold 3072 MB
Vnodes Available: 83.16% (218860/263168)

Preferred User Language: en-US, ru-US
Country Code: US
Keyboards: ABC, Russian - Phonetic
OS Cryptex File Extents: 6653

---

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:
16 start + 2360 (dyld + 24800) [0x186f490e0]
16 main + 7052 (Emacs + 806176) [0x100b20d20]
16 Frecursive_edit + 264 (Emacs + 810284) [0x100b21d2c]
16 recursive_edit_1 + 168 (Emacs + 809540) [0x100b21a44]
16 command_loop + 156 (Emacs + 809876) [0x100b21b94]
16 command_loop.cold.1 + 88 (Emacs + 2131836) [0x100c6477c]
16 internal_catch + 88 (Emacs + 1309428) [0x100b9baf4]
16 command_loop_2 + 52 (Emacs + 811660) [0x100b2228c]
16 internal_condition_case + 96 (Emacs + 1311368) [0x100b9c288]
16 command_loop_1 + 708 (Emacs + 812388) [0x100b22564]
16 read_key_sequence + 1100 (Emacs + 818456) [0x100b23d18]
16 read_char + 2892 (Emacs + 828412) [0x100b263fc]
16 redisplay_internal + 2496 (Emacs + 211932) [0x100a8fbdc]
16 internal_condition_case_1 + 100 (Emacs + 1311508) [0x100b9c314]
16 redisplay_window_1 + 44 (Emacs + 367896) [0x100ab5d18]
16 redisplay_window + 21184 (Emacs + 391972) [0x100abbb24]
16 display_line + 912 (Emacs + 237692) [0x100a9607c]
16 get_next_display_element + 72 (Emacs + 158540) [0x100a82b4c]
16 next_element_from_buffer + 232 (Emacs + 339264) [0x100aaed40]
16 handle_stop + 116 (Emacs + 327536) [0x100aabf70]
16 handle_fontified_prop + 852 (Emacs + 331164) [0x100aacd9c]
16 dsafe**call + 156 (Emacs + 219524) [0x100a91984]
16 internal_condition_case_n + 120 (Emacs + 1311824) [0x100b9c450]
16 Ffuncall + 316 (Emacs + 1302828) [0x100b9a12c]
16 F6a69742d6c6f636b2d66756e6374696f6e_jit_lock_function_0 + 576 (jit-lock-8a988e43-faf4eb64.eln + 18976) [0x107c38a20]
16 Ffuncall + 316 (Emacs + 1302828) [0x100b9a12c]
16 F6a69742d6c6f636b2d666f6e746966792d6e6f77_jit_lock_fontify_now_0 + 640 (jit-lock-8a988e43-faf4eb64.eln + 20584) [0x107c39068]
16 Ffuncall + 316 (Emacs + 1302828) [0x100b9a12c]
16 F6a69742d6c6f636b2d2d72756e2d66756e6374696f6e73_jit_lock**run_functions_0 + 196 (jit-lock-8a988e43-faf4eb64.eln + 19684) [0x107c38ce4]
16 run_hook_with_args + 288 (Emacs + 1318408) [0x100b9de08]
16 run_hook_wrapped_funcall + 28 (Emacs + 1318816) [0x100b9dfa0]
16 Ffuncall + 316 (Emacs + 1302828) [0x100b9a12c]
16 exec_byte_code + 2528 (Emacs + 1573812) [0x100bdc3b4]
16 F666f6e742d6c6f636b2d666f6e746966792d726567696f6e_font_lock_fontify_region_0 + 140 (font-lock-895216f6-19836891.eln + 8364) [0x107bf60ac]
16 Ffuncall + 316 (Emacs + 1302828) [0x100b9a12c]
16 F666f6e742d6c6f636b2d64656661756c742d666f6e746966792d726567696f6e_font_lock_default_fontify_region_0 + 972 (font-lock-895216f6-19836891.eln + 12888) [0x107bf7258]
16 Ffuncall + 316 (Emacs + 1302828) [0x100b9a12c]
16 F666f6e742d6c6f636b2d666f6e746966792d73796e746163746963616c6c792d726567696f6e_font_lock_fontify_syntactically_region_0 + 88 (font-lock-895216f6-19836891.eln + 21080) [0x107bf9258]
16 Ffuncall + 316 (Emacs + 1302828) [0x100b9a12c]
16 F747265657369742d666f6e742d6c6f636b2d666f6e746966792d726567696f6e_treesit_font_lock_fontify_region_0 + 248 (treesit-37439c61-f92dd089.eln + 33476) [0x1150742c4]
16 Fmapcar + 232 (Emacs + 1365636) [0x100ba9684]
16 mapcar1 + 352 (Emacs + 1365052) [0x100ba943c]
16 Ffuncall + 316 (Emacs + 1302828) [0x100b9a12c]
16 Ftreesit_parser_root_node + 176 (Emacs + 1804260) [0x100c147e4]
14 ts_parser_parse + 5204 (libtree-sitter.0.dylib + 38716) [0x101aa173c]
12 ts_parser**reduce + 92 (libtree-sitter.0.dylib + 100648) [0x101ab0928]
11 stack**iter + 116 (libtree-sitter.0.dylib + 72940) [0x101aa9cec]
8 xmalloc + 20 (Emacs + 1160404) [0x100b774d4]
7 nanov2_allocate_outlined + 252 (libsystem_malloc.dylib + 127504) [0x1870fd210]
4 nanov2_find_block_and_allocate + 392 (libsystem_malloc.dylib + 5848) [0x1870df6d8]

Process: Emacs [42099] [unique pid 3910678]
UUID: 0D1331B7-1418-3A9C-960C-6F20FD7B8CE2
Path: /opt/homebrew/\*/Emacs.app/Contents/MacOS/Emacs
Identifier: org.gnu.Emacs
Version: Version 30.0.50 (9.0)
Codesigning ID: temacs-555549440d1331b714183a9c960c6f20fd7b8ce2
Is First Party: No
Shared Cache: F9DDD844-7F3F-34BD-BE29-F0C72D5E5449 slid base address 0x186e8c000, slide 0x6e8c000 (System Primary)
Architecture: arm64
Parent: zsh [37889] [unique pid 3906475]
Responsible: Terminal [29051] [unique pid 1417380]
UID: 501
Footprint: 12.71 GB
Time Since Fork: 51s
Num samples: 16 (1-16)
CPU Time: 1.444s (4.4G cycles, 14.3G instructions, 0.31c/i)
Note: Unresponsive for 26 seconds before sampling
Note: 1 idle work queue thread omitted

Thread 0x1b9f250 DispatchQueue "com.apple.main-thread"(1) 16 samples (1-16) priority 46 (base 46) cpu time 1.444s (4.4G cycles, 14.3G instructions, 0.31c/i)
<thread QoS user interactive (requested user interactive), process unclamped, process received importance donation from WindowServer [374], IO tier 0>
16 start + 2360 (dyld + 24800) [0x186f490e0] 1-16
16 main + 7052 (Emacs + 806176) [0x100b20d20] 1-16
16 Frecursive_edit + 264 (Emacs + 810284) [0x100b21d2c] 1-16
16 recursive_edit_1 + 168 (Emacs + 809540) [0x100b21a44] 1-16
16 command_loop + 156 (Emacs + 809876) [0x100b21b94] 1-16
16 command_loop.cold.1 + 88 (Emacs + 2131836) [0x100c6477c] 1-16
16 internal_catch + 88 (Emacs + 1309428) [0x100b9baf4] 1-16
16 command_loop_2 + 52 (Emacs + 811660) [0x100b2228c] 1-16
16 internal_condition_case + 96 (Emacs + 1311368) [0x100b9c288] 1-16
16 command_loop_1 + 708 (Emacs + 812388) [0x100b22564] 1-16
16 read_key_sequence + 1100 (Emacs + 818456) [0x100b23d18] 1-16
16 read_char + 2892 (Emacs + 828412) [0x100b263fc] 1-16
16 redisplay_internal + 2496 (Emacs + 211932) [0x100a8fbdc] 1-16
16 internal_condition_case_1 + 100 (Emacs + 1311508) [0x100b9c314] 1-16
16 redisplay_window_1 + 44 (Emacs + 367896) [0x100ab5d18] 1-16
16 redisplay_window + 21184 (Emacs + 391972) [0x100abbb24] 1-16
16 display_line + 912 (Emacs + 237692) [0x100a9607c] 1-16
16 get_next_display_element + 72 (Emacs + 158540) [0x100a82b4c] 1-16
16 next_element_from_buffer + 232 (Emacs + 339264) [0x100aaed40] 1-16
16 handle_stop + 116 (Emacs + 327536) [0x100aabf70] 1-16
16 handle_fontified_prop + 852 (Emacs + 331164) [0x100aacd9c] 1-16
16 dsafe**call + 156 (Emacs + 219524) [0x100a91984] 1-16
16 internal_condition_case_n + 120 (Emacs + 1311824) [0x100b9c450] 1-16
16 Ffuncall + 316 (Emacs + 1302828) [0x100b9a12c] 1-16
16 F6a69742d6c6f636b2d66756e6374696f6e_jit_lock_function_0 + 576 (jit-lock-8a988e43-faf4eb64.eln + 18976) [0x107c38a20] 1-16
16 Ffuncall + 316 (Emacs + 1302828) [0x100b9a12c] 1-16
16 F6a69742d6c6f636b2d666f6e746966792d6e6f77_jit_lock_fontify_now_0 + 640 (jit-lock-8a988e43-faf4eb64.eln + 20584) [0x107c39068] 1-16
16 Ffuncall + 316 (Emacs + 1302828) [0x100b9a12c] 1-16
16 F6a69742d6c6f636b2d2d72756e2d66756e6374696f6e73_jit_lock**run_functions_0 + 196 (jit-lock-8a988e43-faf4eb64.eln + 19684) [0x107c38ce4] 1-16
16 run_hook_with_args + 288 (Emacs + 1318408) [0x100b9de08] 1-16
16 run_hook_wrapped_funcall + 28 (Emacs + 1318816) [0x100b9dfa0] 1-16
16 Ffuncall + 316 (Emacs + 1302828) [0x100b9a12c] 1-16
16 exec_byte_code + 2528 (Emacs + 1573812) [0x100bdc3b4] 1-16
16 F666f6e742d6c6f636b2d666f6e746966792d726567696f6e_font_lock_fontify_region_0 + 140 (font-lock-895216f6-19836891.eln + 8364) [0x107bf60ac] 1-16
16 Ffuncall + 316 (Emacs + 1302828) [0x100b9a12c] 1-16
16 F666f6e742d6c6f636b2d64656661756c742d666f6e746966792d726567696f6e_font_lock_default_fontify_region_0 + 972 (font-lock-895216f6-19836891.eln + 12888) [0x107bf7258] 1-16
16 Ffuncall + 316 (Emacs + 1302828) [0x100b9a12c] 1-16
16 F666f6e742d6c6f636b2d666f6e746966792d73796e746163746963616c6c792d726567696f6e_font_lock_fontify_syntactically_region_0 + 88 (font-lock-895216f6-19836891.eln + 21080) [0x107bf9258] 1-16
16 Ffuncall + 316 (Emacs + 1302828) [0x100b9a12c] 1-16
16 F747265657369742d666f6e742d6c6f636b2d666f6e746966792d726567696f6e_treesit_font_lock_fontify_region_0 + 248 (treesit-37439c61-f92dd089.eln + 33476) [0x1150742c4] 1-16
16 Fmapcar + 232 (Emacs + 1365636) [0x100ba9684] 1-16
16 mapcar1 + 352 (Emacs + 1365052) [0x100ba943c] 1-16
16 Ffuncall + 316 (Emacs + 1302828) [0x100b9a12c] 1-16
16 Ftreesit_parser_root_node + 176 (Emacs + 1804260) [0x100c147e4] 1-16
1 ts_parser_parse + 5788 (libtree-sitter.0.dylib + 39300) [0x101aa1984] 1
1 ts_language_table_entry + 216 (libtree-sitter.0.dylib + 18916) [0x101a9c9e4] (running) 1
6 ts_parser_parse + 5204 (libtree-sitter.0.dylib + 38716) [0x101aa173c] 2-7
3 ts_parser**reduce + 92 (libtree-sitter.0.dylib + 100648) [0x101ab0928] 2-4
3 stack**iter + 116 (libtree-sitter.0.dylib + 72940) [0x101aa9cec] 2-4
1 nanov2_malloc + 404 (libsystem_malloc.dylib + 5348) [0x1870df4e4] (running) 2
1 \_malloc_zone_malloc + 84 (libsystem_malloc.dylib + 157824) [0x187104880] (running) 3
1 xmalloc + 20 (Emacs + 1160404) [0x100b774d4] 4
1 nanov2_allocate_outlined + 252 (libsystem_malloc.dylib + 127504) [0x1870fd210] 4
1 nanov2_find_block_and_allocate + 392 (libsystem_malloc.dylib + 5848) [0x1870df6d8] (running) 4
1 ts_parser**reduce + 300 (libtree-sitter.0.dylib + 100856) [0x101ab09f8] 5
1 ts_subtree_new_node + 388 (libtree-sitter.0.dylib + 82556) [0x101aac27c] 5
1 ts_subtree_summarize_children + 1072 (libtree-sitter.0.dylib + 81800) [0x101aabf88] (running) 5
2 ts_parser**reduce + 92 (libtree-sitter.0.dylib + 100648) [0x101ab0928] 6-7
2 stack**iter + 116 (libtree-sitter.0.dylib + 72940) [0x101aa9cec] 6-7
2 xmalloc + 20 (Emacs + 1160404) [0x100b774d4] 6-7
2 nanov2_allocate_outlined + 252 (libsystem_malloc.dylib + 127504) [0x1870fd210] 6-7
1 nanov2_find_block_and_allocate + 392 (libsystem_malloc.dylib + 5848) [0x1870df6d8] (running) 6
1 nanov2_find_block_and_allocate + 596 (libsystem_malloc.dylib + 6052) [0x1870df7a4] (running) 7
1 ts_parser_parse + 5640 (libtree-sitter.0.dylib + 39152) [0x101aa18f0] 8
1 ts_stack_renumber_version + 128 (libtree-sitter.0.dylib + 74828) [0x101aaa44c] 8
1 stack_node_release + 152 (libtree-sitter.0.dylib + 71952) [0x101aa9910] (running) 8
8 ts_parser_parse + 5204 (libtree-sitter.0.dylib + 38716) [0x101aa173c] 9-16
1 ts_parser**reduce + 92 (libtree-sitter.0.dylib + 100648) [0x101ab0928] 9
1 stack**iter + 116 (libtree-sitter.0.dylib + 72940) [0x101aa9cec] 9
1 xmalloc + 20 (Emacs + 1160404) [0x100b774d4] 9
1 nanov2_allocate_outlined + 252 (libsystem_malloc.dylib + 127504) [0x1870fd210] 9
1 nanov2_find_block_and_allocate + 656 (libsystem_malloc.dylib + 6112) [0x1870df7e0] (running) 9
1 ts_parser**reduce + 280 (libtree-sitter.0.dylib + 100836) [0x101ab09e4] 10
1 ts_subtree_array_remove_trailing_extras + 64 (libtree-sitter.0.dylib + 79104) [0x101aab500] (running) 10
6 ts_parser**reduce + 92 (libtree-sitter.0.dylib + 100648) [0x101ab0928] 11-16
5 stack**iter + 116 (libtree-sitter.0.dylib + 72940) [0x101aa9cec] 11-15
1 xmalloc + 20 (Emacs + 1160404) [0x100b774d4] 11
1 nanov2_allocate_outlined + 252 (libsystem_malloc.dylib + 127504) [0x1870fd210] 11
1 nanov2_find_block_and_allocate + 392 (libsystem_malloc.dylib + 5848) [0x1870df6d8] (running) 11
1 \_malloc_zone_malloc + 52 (libsystem_malloc.dylib + 157792) [0x187104860] (running) 12
3 xmalloc + 20 (Emacs + 1160404) [0x100b774d4] 13-15
1 nanov2_allocate_outlined + 252 (libsystem_malloc.dylib + 127504) [0x1870fd210] 13
1 nanov2_find_block_and_allocate + 356 (libsystem_malloc.dylib + 5812) [0x1870df6b4] (running) 13
1 nanov2_allocate_outlined + 316 (libsystem_malloc.dylib + 127568) [0x1870fd250] 14
*1 ??? (kernel.release.t6000 + 31592) [0xfffffe000853fb68] 14
*1 ??? (kernel.release.t6000 + 1714172) [0xfffffe00086da7fc] 14
*1 ??? (kernel.release.t6000 + 1716824) [0xfffffe00086db258] 14
*1 ??? (kernel.release.t6000 + 1072768) [0xfffffe000863de80] 14
*1 ??? (kernel.release.t6000 + 1086348) [0xfffffe000864138c] 14
*1 ??? (kernel.release.t6000 + 1652636) [0xfffffe00086cb79c] 14
\*1 ??? (kernel.release.t6000 + 1652636) [0xfffffe00086cb79c] (running) 14
1 nanov2_allocate_outlined + 252 (libsystem_malloc.dylib + 127504) [0x1870fd210] 15
1 nanov2_find_block_and_allocate + 392 (libsystem_malloc.dylib + 5848) [0x1870df6d8] (running) 15
1 stack\_\_iter + 1064 (libtree-sitter.0.dylib + 73888) [0x101aaa0a0] (running) 16

Thread 0x1b9f254 Thread name "gmain" 16 samples (1-16) priority 31 (base 31)
<thread QoS default (requested default), process unclamped, process received importance donation from WindowServer [374], IO tier 0>
16 thread_start + 8 (libsystem_pthread.dylib + 7740) [0x1872c4e3c] 1-16
16 \_pthread_start + 136 (libsystem_pthread.dylib + 28724) [0x1872ca034] 1-16
16 g_thread_proxy + 68 (libglib-2.0.0.dylib + 392040) [0x101f13b68] 1-16
16 glib_worker_main + 48 (libglib-2.0.0.dylib + 239460) [0x101eee764] 1-16
16 g_main_context_iteration + 60 (libglib-2.0.0.dylib + 234800) [0x101eed530] 1-16
16 g_main_context_iterate_unlocked + 296 (libglib-2.0.0.dylib + 234600) [0x101eed468] 1-16
16 \_\_select + 8 (libsystem_kernel.dylib + 51668) [0x1872949d4] 1-16
\*16 ??? (kernel.release.t6000 + 5651088) [0xfffffe0008a9ba90] 1-16

Thread 0x1b9f25d 16 samples (1-16) priority 31 (base 31)
<thread QoS default (requested default), process unclamped, process received importance donation from WindowServer [374], IO tier 0>
16 thread_start + 8 (libsystem_pthread.dylib + 7740) [0x1872c4e3c] 1-16
16 \_pthread_start + 136 (libsystem_pthread.dylib + 28724) [0x1872ca034] 1-16
16 **NSThread**start** + 716 (Foundation + 343988) [0x1884a8fb4] 1-16
16 -[EmacsApp fd_handler:] + 184 (Emacs + 1933500) [0x100c340bc] 1-16
16 <patched truncated backtrace> 1-16
16 **pselect + 8 (libsystem_kernel.dylib + 31564) [0x18728fb4c] 1-16
\*16 ??? (kernel.release.t6000 + 5651088) [0xfffffe0008a9ba90] 1-16

Thread 0x1b9f261 Thread name "com.apple.NSEventThread" 16 samples (1-16) priority 46 (base 46)
<thread QoS user interactive (requested user interactive), process unclamped, process received importance donation from WindowServer [374], IO tier 0>
16 thread_start + 8 (libsystem_pthread.dylib + 7740) [0x1872c4e3c] 1-16
16 \_pthread_start + 136 (libsystem_pthread.dylib + 28724) [0x1872ca034] 1-16
16 \_NSEventThread + 144 (AppKit + 1455376) [0x18acac510] 1-16
16 CFRunLoopRunSpecific + 608 (CoreFoundation + 506284) [0x1873a59ac] 1-16
16 **CFRunLoopRun + 1208 (CoreFoundation + 509116) [0x1873a64bc] 1-16
16 **CFRunLoopServiceMachPort + 160 (CoreFoundation + 515060) [0x1873a7bf4] 1-16
16 mach_msg + 24 (libsystem_kernel.dylib + 7160) [0x187289bf8] 1-16
16 mach_msg_overwrite + 476 (libsystem_kernel.dylib + 42160) [0x1872924b0] 1-16
16 mach_msg2_trap + 8 (libsystem_kernel.dylib + 6260) [0x187289874] 1-16
\*16 ??? (kernel.release.t6000 + 231904) [0xfffffe00085709e0] 1-16

Binary Images:
0x100a5c000 - 0x101373fff org.gnu.Emacs Version 30.0.50 (9.0) <0D1331B7-1418-3A9C-960C-6F20FD7B8CE2> /opt/homebrew/_/Emacs.app/Contents/MacOS/Emacs
0x101a98000 - 0x101abffff libtree-sitter.0.dylib (0) <9053818C-25CC-3F55-8A69-1C25670CDDC0> /opt/homebrew/_/libtree-sitter.0.dylib
0x101eb4000 - 0x101fabfff libglib-2.0.0.dylib (0) <C29E7DDA-6715-306D-AFD3-F81CCAB7D8B5> /opt/homebrew/_/libglib-2.0.0.dylib
0x107bf4000 - 0x107c13fff font-lock-895216f6-19836891.eln (0) <BACF6FB6-37ED-3682-8058-F5E096C0E9FA> /opt/homebrew/_/Emacs.app/Contents/native-lisp/30.0.50-fce17090/preloaded/font-lock-895216f6-19836891.eln
0x107c34000 - 0x107c47fff jit-lock-8a988e43-faf4eb64.eln (0) <8981D7A0-4A30-3839-B81A-B040875777EE> /opt/homebrew/_/Emacs.app/Contents/native-lisp/30.0.50-fce17090/preloaded/jit-lock-8a988e43-faf4eb64.eln
0x11506c000 - 0x1150abfff treesit-37439c61-f92dd089.eln (0) <CBBA7F4A-5446-3A60-A991-CD21093D00F0> /Users/USER/_/treesit-37439c61-f92dd089.eln
0x186f43000 - 0x186fd7347 dyld (1125.5) <324E4AD9-E01F-3183-B09F-3E20B326643A> /usr/lib/dyld
0x1870de000 - 0x187114fff libsystem_malloc.dylib (474.0.13) <690A8B04-8E64-3332-B5A5-56A3D5C1C43F> /usr/lib/system/libsystem_malloc.dylib
0x187288000 - 0x1872c2fff libsystem_kernel.dylib (10002.61.3) <CA94FC21-BC40-3B43-B65D-B87ECE9E1D48> /usr/lib/system/libsystem_kernel.dylib
0x1872c3000 - 0x1872cfff3 libsystem_pthread.dylib (519) <A7D94C96-7B1F-3229-9BEA-048D037C3292> /usr/lib/system/libsystem_pthread.dylib
0x18732a000 - 0x187801fff com.apple.CoreFoundation 6.9 (2202) <47E4EC09-8F6E-30A8-99D0-34024D4F8122> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x188455000 - 0x18909cfff com.apple.Foundation 6.9 (2202) <9558B1EB-DDA3-3FDA-88A5-E785ECDFCD30> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x18ab49000 - 0x18be63fff com.apple.AppKit 6.9 (2487.30.108) <F3527312-E426-3F7C-B77B-2BF49D1B7C04> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
\*0xfffffe0008538000 - 0xfffffe0008db3fff kernel.release.t6000 (10002.61.3) <3DE22D7D-A5F5-3B17-84BD-A58164C8B09B>\_\_TEXT_EXEC /System/Library/Kernels/kernel.release.t6000

[-- Attachment #5: Type: text/plain, Size: 1667 bytes --]



In GNU Emacs 30.0.50 (build 1, aarch64-apple-darwin23.2.0, NS
 appkit-2487.30 Version 14.2.1 (Build 23C71)) of 2024-06-23 built on
 Sviatoslavs-MacBook-Pro.local
Windowing system distributor 'Apple', version 10.3.2487
System Description:  macOS 14.2.1

Configured using:
 'configure --disable-dependency-tracking --disable-silent-rules
 --enable-locallisppath=/opt/homebrew/share/emacs/site-lisp
 --infodir=/opt/homebrew/Cellar/emacs-plus@30/30.0.50/share/info/emacs
 --prefix=/opt/homebrew/Cellar/emacs-plus@30/30.0.50 --with-xml2
 --with-gnutls --with-native-compilation --without-compress-install
 --without-dbus --without-imagemagick --with-modules --with-rsvg
 --with-webp --with-ns --disable-ns-self-contained 'CFLAGS=-Os -w -pipe
 -mmacosx-version-min=14
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk
 -DFD_SETSIZE=10000 -DDARWIN_UNLIMITED_SELECT
 -I/opt/homebrew/opt/gcc/include -I/opt/homebrew/opt/libgccjit/include'
 'CPPFLAGS=-I/opt/homebrew/opt/zlib/include
 -I/opt/homebrew/opt/jpeg/include -I/opt/homebrew/opt/icu4c/include
 -I/opt/homebrew/opt/sqlite/include -I/opt/homebrew/opt/readline/include
 -isystem/opt/homebrew/include -F/opt/homebrew/Frameworks
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk'
 'LDFLAGS=-L/opt/homebrew/opt/zlib/lib -L/opt/homebrew/opt/jpeg/lib
 -L/opt/homebrew/opt/icu4c/lib -L/opt/homebrew/opt/sqlite/lib
 -L/opt/homebrew/opt/readline/lib -L/opt/homebrew/lib
 -F/opt/homebrew/Frameworks -Wl,-headerpad_max_install_names
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk
 -L/opt/homebrew/lib/gcc/14 -I/opt/homebrew/opt/gcc/include
 -I/opt/homebrew/opt/libgccjit/include''

bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code

[Eli Zaretskii]

> From: mail@ssbb.me
> Date: Thu, 29 Aug 2024 06:57:38 +0400
> 
> Code in attached file cause Emacs to hang and memory leak infinitely
> while editing. Try to open this code in elixir-ts-mode and move cursor
> on line 6 (between <:loading>  </:loading>) and type char by char:
> 
> <.some_component a={
> 
> (for some reason it does not happen with electric-pair-mode when {}
> inserted automatically).
> 
> I am able to reproduce this with -Q on few different machines (Linux and
> MacOS) and Emacs 29, 30.0.5 and current HEAD.
> 
> C-g does nothing (including with debug-on-quit and sending SIGUSR2)
> 
> At the same time I can't reproduce this in other tree-sitter based editors.
> 
> I got this sample code sample from elixir-ts-mode repo but now it's moved
> to the Emacs core so seems to be out of scope of Github repo issues.
> 
> Attaching samle code and LLDB backtrace. 
> Also attaching report from built-in MacOS crash reporting tool just in case.

Thanks.

Wilhelm and Yuan, could you please look into this soon?

bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code

[Wilhelm Kirschbaum]

[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]

>
>  > From: mail@ssbb.me
> > Date: Thu, 29 Aug 2024 06:57:38 +0400
> >
> > Code in attached file cause Emacs to hang and memory leak infinitely
> > while editing. Try to open this code in elixir-ts-mode and move cursor
> > on line 6 (between <:loading>  </:loading>) and type char by char:
> >
> > <.some_component a={
> >
> > (for some reason it does not happen with electric-pair-mode when {}
> > inserted automatically).
> >
> > I am able to reproduce this with -Q on few different machines (Linux and
> > MacOS) and Emacs 29, 30.0.5 and current HEAD.
> >
> > C-g does nothing (including with debug-on-quit and sending SIGUSR2)
> >
> > At the same time I can't reproduce this in other tree-sitter based
> editors.
> >
> > I got this sample code sample from elixir-ts-mode repo but now it's moved
> > to the Emacs core so seems to be out of scope of Github repo issues.
> >
> > Attaching samle code and LLDB backtrace.
> > Also attaching report from built-in MacOS crash reporting tool just in
> case.
>
> Thanks.
>
> Wilhelm and Yuan, could you please look into this soon?
>

Thanks, I will have a look later today.

Wilhelm

[-- Attachment #2: Type: text/html, Size: 1604 bytes --]

bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code

[Yuan Fu]

> On Aug 28, 2024, at 10:09 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: mail@ssbb.me
>> Date: Thu, 29 Aug 2024 06:57:38 +0400
>> 
>> Code in attached file cause Emacs to hang and memory leak infinitely
>> while editing. Try to open this code in elixir-ts-mode and move cursor
>> on line 6 (between <:loading>  </:loading>) and type char by char:
>> 
>> <.some_component a={
>> 
>> (for some reason it does not happen with electric-pair-mode when {}
>> inserted automatically).
>> 
>> I am able to reproduce this with -Q on few different machines (Linux and
>> MacOS) and Emacs 29, 30.0.5 and current HEAD.
>> 
>> C-g does nothing (including with debug-on-quit and sending SIGUSR2)
>> 
>> At the same time I can't reproduce this in other tree-sitter based editors.
>> 
>> I got this sample code sample from elixir-ts-mode repo but now it's moved
>> to the Emacs core so seems to be out of scope of Github repo issues.
>> 
>> Attaching samle code and LLDB backtrace. 
>> Also attaching report from built-in MacOS crash reporting tool just in case.
> 
> Thanks.
> 
> Wilhelm and Yuan, could you please look into this soon?

That’s bizarre, might have some bug around ranges. I’m looking into this. Hopefully I can figure it out in a few days :-(

Yuan

bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code

[Wilhelm Kirschbaum]

[-- Attachment #1: Type: text/plain, Size: 1636 bytes --]

On Thu, Aug 29, 2024 at 8:14 AM Yuan Fu <casouri@gmail.com> wrote:

>
>
> > On Aug 28, 2024, at 10:09 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> >> From: mail@ssbb.me
> >> Date: Thu, 29 Aug 2024 06:57:38 +0400
> >>
> >> Code in attached file cause Emacs to hang and memory leak infinitely
> >> while editing. Try to open this code in elixir-ts-mode and move cursor
> >> on line 6 (between <:loading>  </:loading>) and type char by char:
> >>
> >> <.some_component a={
> >>
> >> (for some reason it does not happen with electric-pair-mode when {}
> >> inserted automatically).
> >>
> >> I am able to reproduce this with -Q on few different machines (Linux and
> >> MacOS) and Emacs 29, 30.0.5 and current HEAD.
> >>
> >> C-g does nothing (including with debug-on-quit and sending SIGUSR2)
> >>
> >> At the same time I can't reproduce this in other tree-sitter based
> editors.
> >>
> >> I got this sample code sample from elixir-ts-mode repo but now it's
> moved
> >> to the Emacs core so seems to be out of scope of Github repo issues.
> >>
> >> Attaching samle code and LLDB backtrace.
> >> Also attaching report from built-in MacOS crash reporting tool just in
> case.
> >
> > Thanks.
> >
> > Wilhelm and Yuan, could you please look into this soon?
>
> That’s bizarre, might have some bug around ranges. I’m looking into this.
> Hopefully I can figure it out in a few days :-(
>
> Yuan


I can reproduce the issue by following the above instructions, but need to
do some digging. It only seems to be the case with embedded heex and not
with heex-ts-mode by itself.

WIlhelm

[-- Attachment #2: Type: text/html, Size: 2394 bytes --]

bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code

[mail]

[-- Attachment #1: Type: text/plain, Size: 1970 bytes --]

I can confirm that I never had such problems in heex-ts-mode but only with inline heex in elixir-ts-mode.

> On Sep 4, 2024, at 10:39 AM, Wilhelm Kirschbaum <wkirschbaum@gmail.com> wrote:
> 
> 
> 
> On Thu, Aug 29, 2024 at 8:14 AM Yuan Fu <casouri@gmail.com <mailto:casouri@gmail.com>> wrote:
>> 
>> 
>> > On Aug 28, 2024, at 10:09 PM, Eli Zaretskii <eliz@gnu.org <mailto:eliz@gnu.org>> wrote:
>> > 
>> >> From: mail@ssbb.me <mailto:mail@ssbb.me>
>> >> Date: Thu, 29 Aug 2024 06:57:38 +0400
>> >> 
>> >> Code in attached file cause Emacs to hang and memory leak infinitely
>> >> while editing. Try to open this code in elixir-ts-mode and move cursor
>> >> on line 6 (between <:loading>  </:loading>) and type char by char:
>> >> 
>> >> <.some_component a={
>> >> 
>> >> (for some reason it does not happen with electric-pair-mode when {}
>> >> inserted automatically).
>> >> 
>> >> I am able to reproduce this with -Q on few different machines (Linux and
>> >> MacOS) and Emacs 29, 30.0.5 and current HEAD.
>> >> 
>> >> C-g does nothing (including with debug-on-quit and sending SIGUSR2)
>> >> 
>> >> At the same time I can't reproduce this in other tree-sitter based editors.
>> >> 
>> >> I got this sample code sample from elixir-ts-mode repo but now it's moved
>> >> to the Emacs core so seems to be out of scope of Github repo issues.
>> >> 
>> >> Attaching samle code and LLDB backtrace. 
>> >> Also attaching report from built-in MacOS crash reporting tool just in case.
>> > 
>> > Thanks.
>> > 
>> > Wilhelm and Yuan, could you please look into this soon?
>> 
>> That’s bizarre, might have some bug around ranges. I’m looking into this. Hopefully I can figure it out in a few days :-(
>> 
>> Yuan
> 
> I can reproduce the issue by following the above instructions, but need to do some digging. It only seems to be the case with embedded heex and not with heex-ts-mode by itself.
> 
> WIlhelm
> 
> 
> 


[-- Attachment #2: Type: text/html, Size: 2934 bytes --]

bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code

[Yuan Fu]

> On Sep 4, 2024, at 12:42 AM, mail@ssbb.me wrote:
> 
> I can confirm that I never had such problems in heex-ts-mode but only with inline heex in elixir-ts-mode.
> 
>> On Sep 4, 2024, at 10:39 AM, Wilhelm Kirschbaum <wkirschbaum@gmail.com> wrote:
>> 
>> 
>> 
>> On Thu, Aug 29, 2024 at 8:14 AM Yuan Fu <casouri@gmail.com> wrote:
>> 
>> 
>> > On Aug 28, 2024, at 10:09 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> > 
>> >> From: mail@ssbb.me
>> >> Date: Thu, 29 Aug 2024 06:57:38 +0400
>> >> 
>> >> Code in attached file cause Emacs to hang and memory leak infinitely
>> >> while editing. Try to open this code in elixir-ts-mode and move cursor
>> >> on line 6 (between <:loading>  </:loading>) and type char by char:
>> >> 
>> >> <.some_component a={
>> >> 
>> >> (for some reason it does not happen with electric-pair-mode when {}
>> >> inserted automatically).
>> >> 
>> >> I am able to reproduce this with -Q on few different machines (Linux and
>> >> MacOS) and Emacs 29, 30.0.5 and current HEAD.
>> >> 
>> >> C-g does nothing (including with debug-on-quit and sending SIGUSR2)
>> >> 
>> >> At the same time I can't reproduce this in other tree-sitter based editors.
>> >> 
>> >> I got this sample code sample from elixir-ts-mode repo but now it's moved
>> >> to the Emacs core so seems to be out of scope of Github repo issues.
>> >> 
>> >> Attaching samle code and LLDB backtrace. 
>> >> Also attaching report from built-in MacOS crash reporting tool just in case.
>> > 
>> > Thanks.
>> > 
>> > Wilhelm and Yuan, could you please look into this soon?
>> 
>> That’s bizarre, might have some bug around ranges. I’m looking into this. Hopefully I can figure it out in a few days :-(
>> 
>> Yuan
>> 
>> I can reproduce the issue by following the above instructions, but need to do some digging. It only seems to be the case with embedded heex and not with heex-ts-mode by itself. 
>> 
>> WIlhelm
>> 

At the moment I’m still not able to pinpoint the culprit, but here’s what I found: I can reproduce the issue by simply creating a heex parser, set the ranges to [108,240], [300,572], [820,1346] (these are byte position, aka one less than character position), then make it parse the buffer (with the "<.some_component a={" part already typed in. I instrumented the buffer reader and the program hangs after reading the character at byte position 908 (end of "phx-click={“). Also the hang appears in ts_parser_parse.

I wrote a C program that does exactly that, but the program runs fine without hanging. I haven’t found what Emacs does differently that causes the hang to happen.

Also I found some other range bug, but fixing those didn’t help this issue.

Yuan

bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code

[Yuan Fu]

> On Sep 4, 2024, at 9:32 PM, Yuan Fu <casouri@gmail.com> wrote:
> 
> 
> 
>> On Sep 4, 2024, at 12:42 AM, mail@ssbb.me wrote:
>> 
>> I can confirm that I never had such problems in heex-ts-mode but only with inline heex in elixir-ts-mode.
>> 
>>> On Sep 4, 2024, at 10:39 AM, Wilhelm Kirschbaum <wkirschbaum@gmail.com> wrote:
>>> 
>>> 
>>> 
>>> On Thu, Aug 29, 2024 at 8:14 AM Yuan Fu <casouri@gmail.com> wrote:
>>> 
>>> 
>>>> On Aug 28, 2024, at 10:09 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>>> 
>>>>> From: mail@ssbb.me
>>>>> Date: Thu, 29 Aug 2024 06:57:38 +0400
>>>>> 
>>>>> Code in attached file cause Emacs to hang and memory leak infinitely
>>>>> while editing. Try to open this code in elixir-ts-mode and move cursor
>>>>> on line 6 (between <:loading>  </:loading>) and type char by char:
>>>>> 
>>>>> <.some_component a={
>>>>> 
>>>>> (for some reason it does not happen with electric-pair-mode when {}
>>>>> inserted automatically).
>>>>> 
>>>>> I am able to reproduce this with -Q on few different machines (Linux and
>>>>> MacOS) and Emacs 29, 30.0.5 and current HEAD.
>>>>> 
>>>>> C-g does nothing (including with debug-on-quit and sending SIGUSR2)
>>>>> 
>>>>> At the same time I can't reproduce this in other tree-sitter based editors.
>>>>> 
>>>>> I got this sample code sample from elixir-ts-mode repo but now it's moved
>>>>> to the Emacs core so seems to be out of scope of Github repo issues.
>>>>> 
>>>>> Attaching samle code and LLDB backtrace. 
>>>>> Also attaching report from built-in MacOS crash reporting tool just in case.
>>>> 
>>>> Thanks.
>>>> 
>>>> Wilhelm and Yuan, could you please look into this soon?
>>> 
>>> That’s bizarre, might have some bug around ranges. I’m looking into this. Hopefully I can figure it out in a few days :-(
>>> 
>>> Yuan
>>> 
>>> I can reproduce the issue by following the above instructions, but need to do some digging. It only seems to be the case with embedded heex and not with heex-ts-mode by itself. 
>>> 
>>> WIlhelm
>>> 
> 
> At the moment I’m still not able to pinpoint the culprit, but here’s what I found: I can reproduce the issue by simply creating a heex parser, set the ranges to [108,240], [300,572], [820,1346] (these are byte position, aka one less than character position), then make it parse the buffer (with the "<.some_component a={" part already typed in. I instrumented the buffer reader and the program hangs after reading the character at byte position 908 (end of "phx-click={“). Also the hang appears in ts_parser_parse.
> 
> I wrote a C program that does exactly that, but the program runs fine without hanging. I haven’t found what Emacs does differently that causes the hang to happen.
> 
> Also I found some other range bug, but fixing those didn’t help this issue.

Still don’t have much progress. The buffer’s gap is at the beginning, and there’s no narrowing, which means the parser is really just reading a continues chunk of memory, there’s no reason why it should behave differently. At this point I might have to read tree-sitter’s source :-(

Meanwhile, I want to push the fix for the other bug I discovered to emacs-30. Eli, I wrote a debugging function that prints parser states, naturally this function isn’t called anywhere so there’ll be a compiler warning, what should I do in this case?

Yuan

bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Sat, 7 Sep 2024 22:44:53 -0700
> Cc: Wilhelm Kirschbaum <wkirschbaum@gmail.com>,
>  Eli Zaretskii <eliz@gnu.org>,
>  72863@debbugs.gnu.org
> 
> Meanwhile, I want to push the fix for the other bug I discovered to emacs-30. Eli, I wrote a debugging function that prints parser states, naturally this function isn’t called anywhere so there’ll be a compiler warning, what should I do in this case?

Why would there be a compiler warning?  What kind of warning?

bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code

[Yuan Fu]

> On Sep 7, 2024, at 10:54 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Sat, 7 Sep 2024 22:44:53 -0700
>> Cc: Wilhelm Kirschbaum <wkirschbaum@gmail.com>,
>> Eli Zaretskii <eliz@gnu.org>,
>> 72863@debbugs.gnu.org
>> 
>> Meanwhile, I want to push the fix for the other bug I discovered to emacs-30. Eli, I wrote a debugging function that prints parser states, naturally this function isn’t called anywhere so there’ll be a compiler warning, what should I do in this case?
> 
> Why would there be a compiler warning?  What kind of warning?

A function-not-used warning. Maybe it’s an lldb thing?

Yuan

bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Sat, 7 Sep 2024 22:57:29 -0700
> Cc: mail@ssbb.me,
>  wkirschbaum@gmail.com,
>  72863@debbugs.gnu.org
> 
> 
> 
> > On Sep 7, 2024, at 10:54 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> >> From: Yuan Fu <casouri@gmail.com>
> >> Date: Sat, 7 Sep 2024 22:44:53 -0700
> >> Cc: Wilhelm Kirschbaum <wkirschbaum@gmail.com>,
> >> Eli Zaretskii <eliz@gnu.org>,
> >> 72863@debbugs.gnu.org
> >> 
> >> Meanwhile, I want to push the fix for the other bug I discovered to emacs-30. Eli, I wrote a debugging function that prints parser states, naturally this function isn’t called anywhere so there’ll be a compiler warning, what should I do in this case?
> > 
> > Why would there be a compiler warning?  What kind of warning?
> 
> A function-not-used warning. Maybe it’s an lldb thing?

If the function is not static, there should be no such warning.

bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code

[Yuan Fu]

> On Sep 8, 2024, at 12:02 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Sat, 7 Sep 2024 22:57:29 -0700
>> Cc: mail@ssbb.me,
>> wkirschbaum@gmail.com,
>> 72863@debbugs.gnu.org
>> 
>> 
>> 
>>> On Sep 7, 2024, at 10:54 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> 
>>>> From: Yuan Fu <casouri@gmail.com>
>>>> Date: Sat, 7 Sep 2024 22:44:53 -0700
>>>> Cc: Wilhelm Kirschbaum <wkirschbaum@gmail.com>,
>>>> Eli Zaretskii <eliz@gnu.org>,
>>>> 72863@debbugs.gnu.org
>>>> 
>>>> Meanwhile, I want to push the fix for the other bug I discovered to emacs-30. Eli, I wrote a debugging function that prints parser states, naturally this function isn’t called anywhere so there’ll be a compiler warning, what should I do in this case?
>>> 
>>> Why would there be a compiler warning?  What kind of warning?
>> 
>> A function-not-used warning. Maybe it’s an lldb thing?
> 
> If the function is not static, there should be no such warning.

Ah, you’re right, I marked it static. Thanks!

Yuan

bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code

[Yuan Fu]

> On Sep 8, 2024, at 12:48 AM, Yuan Fu <casouri@gmail.com> wrote:
> 
> 
> 
>> On Sep 8, 2024, at 12:02 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>>> From: Yuan Fu <casouri@gmail.com>
>>> Date: Sat, 7 Sep 2024 22:57:29 -0700
>>> Cc: mail@ssbb.me,
>>> wkirschbaum@gmail.com,
>>> 72863@debbugs.gnu.org
>>> 
>>> 
>>> 
>>>> On Sep 7, 2024, at 10:54 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>>> 
>>>>> From: Yuan Fu <casouri@gmail.com>
>>>>> Date: Sat, 7 Sep 2024 22:44:53 -0700
>>>>> Cc: Wilhelm Kirschbaum <wkirschbaum@gmail.com>,
>>>>> Eli Zaretskii <eliz@gnu.org>,
>>>>> 72863@debbugs.gnu.org
>>>>> 
>>>>> Meanwhile, I want to push the fix for the other bug I discovered to emacs-30. Eli, I wrote a debugging function that prints parser states, naturally this function isn’t called anywhere so there’ll be a compiler warning, what should I do in this case?
>>>> 
>>>> Why would there be a compiler warning?  What kind of warning?
>>> 
>>> A function-not-used warning. Maybe it’s an lldb thing?
>> 
>> If the function is not static, there should be no such warning.
> 
> Ah, you’re right, I marked it static. Thanks!
> 
> Yuan

Good news: not an Emacs bug. Bad news: a tree-sitter bug. Turns out I made an error in my test program, which is the reason why Emacs hangs but the test program doesn’t. Once I fixed the error, the test program hangs too. I submitted a bug report to tree-sitter: https://github.com/tree-sitter/tree-sitter/issues/3620

I can finally sleep soundly at night now; and I guess tree-sitter dev will start having sleepless nights :-)

Yuan

bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code

[mail]

[-- Attachment #1: Type: text/plain, Size: 2154 bytes --]

Wow, thank you so much for diving into this issue! I'll keep track of it in tree-sitter repo from now on.

It seems like other integrations somehow manage to avoid hanging or crashing the main process, so it doesn't affect them?

I just checked in the Zed editor again to confirm. When I type a={, it fails to highlight the rest of the embedded HEEX (but only within the current function) though.


> On Sep 11, 2024, at 7:45 AM, Yuan Fu <casouri@gmail.com> wrote:
> 
> 
> 
>> On Sep 8, 2024, at 12:48 AM, Yuan Fu <casouri@gmail.com> wrote:
>> 
>> 
>> 
>>> On Sep 8, 2024, at 12:02 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> 
>>>> From: Yuan Fu <casouri@gmail.com>
>>>> Date: Sat, 7 Sep 2024 22:57:29 -0700
>>>> Cc: mail@ssbb.me,
>>>> wkirschbaum@gmail.com,
>>>> 72863@debbugs.gnu.org
>>>> 
>>>> 
>>>> 
>>>>> On Sep 7, 2024, at 10:54 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>>>> 
>>>>>> From: Yuan Fu <casouri@gmail.com>
>>>>>> Date: Sat, 7 Sep 2024 22:44:53 -0700
>>>>>> Cc: Wilhelm Kirschbaum <wkirschbaum@gmail.com>,
>>>>>> Eli Zaretskii <eliz@gnu.org>,
>>>>>> 72863@debbugs.gnu.org
>>>>>> 
>>>>>> Meanwhile, I want to push the fix for the other bug I discovered to emacs-30. Eli, I wrote a debugging function that prints parser states, naturally this function isn’t called anywhere so there’ll be a compiler warning, what should I do in this case?
>>>>> 
>>>>> Why would there be a compiler warning?  What kind of warning?
>>>> 
>>>> A function-not-used warning. Maybe it’s an lldb thing?
>>> 
>>> If the function is not static, there should be no such warning.
>> 
>> Ah, you’re right, I marked it static. Thanks!
>> 
>> Yuan
> 
> Good news: not an Emacs bug. Bad news: a tree-sitter bug. Turns out I made an error in my test program, which is the reason why Emacs hangs but the test program doesn’t. Once I fixed the error, the test program hangs too. I submitted a bug report to tree-sitter: https://github.com/tree-sitter/tree-sitter/issues/3620
> 
> I can finally sleep soundly at night now; and I guess tree-sitter dev will start having sleepless nights :-)
> 
> Yuan
> 


[-- Attachment #2: Type: text/html, Size: 2657 bytes --]

bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code

[Yuan Fu]

> On Sep 11, 2024, at 12:22 PM, mail@ssbb.me wrote:
> 
> Wow, thank you so much for diving into this issue! I'll keep track of it in tree-sitter repo from now on.

My pleasure ;-)

> It seems like other integrations somehow manage to avoid hanging or crashing the main process, so it doesn't affect them?
> I just checked in the Zed editor again to confirm. When I type a={, it fails to highlight the rest of the embedded HEEX (but only within the current function) though.

I know a couple editors uses async parsing, Zed probably also uses async parsing.

Yuan


>> On Sep 11, 2024, at 7:45 AM, Yuan Fu <casouri@gmail.com> wrote:
>> 
>> 
>> 
>>> On Sep 8, 2024, at 12:48 AM, Yuan Fu <casouri@gmail.com> wrote:
>>> 
>>> 
>>> 
>>>> On Sep 8, 2024, at 12:02 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>>>> 
>>>>> From: Yuan Fu <casouri@gmail.com>
>>>>> Date: Sat, 7 Sep 2024 22:57:29 -0700
>>>>> Cc: mail@ssbb.me,
>>>>> wkirschbaum@gmail.com,
>>>>> 72863@debbugs.gnu.org
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Sep 7, 2024, at 10:54 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>>>>> 
>>>>>>> From: Yuan Fu <casouri@gmail.com>
>>>>>>> Date: Sat, 7 Sep 2024 22:44:53 -0700
>>>>>>> Cc: Wilhelm Kirschbaum <wkirschbaum@gmail.com>,
>>>>>>> Eli Zaretskii <eliz@gnu.org>,
>>>>>>> 72863@debbugs.gnu.org
>>>>>>> 
>>>>>>> Meanwhile, I want to push the fix for the other bug I discovered to emacs-30. Eli, I wrote a debugging function that prints parser states, naturally this function isn’t called anywhere so there’ll be a compiler warning, what should I do in this case?
>>>>>> 
>>>>>> Why would there be a compiler warning?  What kind of warning?
>>>>> 
>>>>> A function-not-used warning. Maybe it’s an lldb thing?
>>>> 
>>>> If the function is not static, there should be no such warning.
>>> 
>>> Ah, you’re right, I marked it static. Thanks!
>>> 
>>> Yuan
>> 
>> Good news: not an Emacs bug. Bad news: a tree-sitter bug. Turns out I made an error in my test program, which is the reason why Emacs hangs but the test program doesn’t. Once I fixed the error, the test program hangs too. I submitted a bug report to tree-sitter: https://github.com/tree-sitter/tree-sitter/issues/3620
>> 
>> I can finally sleep soundly at night now; and I guess tree-sitter dev will start having sleepless nights :-)
>> 
>> Yuan
>> 
> 

bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code

[Wilhelm Kirschbaum]

[-- Attachment #1: Type: text/plain, Size: 2680 bytes --]

Thanks Yuan, and thanks for the improvements on elixir-ts-mode.

Kind regards,
Wilhelm

On Thu, Sep 12, 2024 at 9:47 AM Yuan Fu <casouri@gmail.com> wrote:

>
>
> > On Sep 11, 2024, at 12:22 PM, mail@ssbb.me wrote:
> >
> > Wow, thank you so much for diving into this issue! I'll keep track of it
> in tree-sitter repo from now on.
>
> My pleasure ;-)
>
> > It seems like other integrations somehow manage to avoid hanging or
> crashing the main process, so it doesn't affect them?
> > I just checked in the Zed editor again to confirm. When I type a={, it
> fails to highlight the rest of the embedded HEEX (but only within the
> current function) though.
>
> I know a couple editors uses async parsing, Zed probably also uses async
> parsing.
>
> Yuan
>
>
> >> On Sep 11, 2024, at 7:45 AM, Yuan Fu <casouri@gmail.com> wrote:
> >>
> >>
> >>
> >>> On Sep 8, 2024, at 12:48 AM, Yuan Fu <casouri@gmail.com> wrote:
> >>>
> >>>
> >>>
> >>>> On Sep 8, 2024, at 12:02 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >>>>
> >>>>> From: Yuan Fu <casouri@gmail.com>
> >>>>> Date: Sat, 7 Sep 2024 22:57:29 -0700
> >>>>> Cc: mail@ssbb.me,
> >>>>> wkirschbaum@gmail.com,
> >>>>> 72863@debbugs.gnu.org
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On Sep 7, 2024, at 10:54 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >>>>>>
> >>>>>>> From: Yuan Fu <casouri@gmail.com>
> >>>>>>> Date: Sat, 7 Sep 2024 22:44:53 -0700
> >>>>>>> Cc: Wilhelm Kirschbaum <wkirschbaum@gmail.com>,
> >>>>>>> Eli Zaretskii <eliz@gnu.org>,
> >>>>>>> 72863@debbugs.gnu.org
> >>>>>>>
> >>>>>>> Meanwhile, I want to push the fix for the other bug I discovered
> to emacs-30. Eli, I wrote a debugging function that prints parser states,
> naturally this function isn’t called anywhere so there’ll be a compiler
> warning, what should I do in this case?
> >>>>>>
> >>>>>> Why would there be a compiler warning?  What kind of warning?
> >>>>>
> >>>>> A function-not-used warning. Maybe it’s an lldb thing?
> >>>>
> >>>> If the function is not static, there should be no such warning.
> >>>
> >>> Ah, you’re right, I marked it static. Thanks!
> >>>
> >>> Yuan
> >>
> >> Good news: not an Emacs bug. Bad news: a tree-sitter bug. Turns out I
> made an error in my test program, which is the reason why Emacs hangs but
> the test program doesn’t. Once I fixed the error, the test program hangs
> too. I submitted a bug report to tree-sitter:
> https://github.com/tree-sitter/tree-sitter/issues/3620
> >>
> >> I can finally sleep soundly at night now; and I guess tree-sitter dev
> will start having sleepless nights :-)
> >>
> >> Yuan
> >>
> >
>
>

[-- Attachment #2: Type: text/html, Size: 4556 bytes --]