lldb-mi freezes on MacOS when breaking near uninitialised variables

Type: Debugger

Describe the bug

OS and Version: MacOS 11.2.3 (Big Sur)
VS Code Version: 1.5.4.3
C/C++ Extension Version: 1.2.2
I have recreated on both Intel and Apple Silicon (Rosetta) MacBook Pros.

During debugging, if stopping on (or stepping in to) a frame containing certain types of uninitialised variables, lldb-mi gets stuck at 100% cpu and starts to consume multiple GBs of memory.

I've encountered this a a few times in different code, I've condensed the latest example in to a tiny snippet (below), using a std::initialiser_list<int>.

I couldn't reproduce using the lldb command line. Xcode is fine too, but I notice it uses lldb-rpc-server to communicate with debugserver instead of lldb-mi.

I also tried using the CodeLLDB extension (https://marketplace.visualstudio.com/items?itemName=vadimcn.vscode-lldb) which doesn't suffer with the same problem (and doesn't use lldb-mi) - but interestingly, it does try to inspect the values of the initializer_list but times out after a short time.

If debugging is stopped while this is going on, the lldb-mi process continue to spin with high cpu usage in the background.

This may be related to the following:

The issue may not be directly related to cpptools (could be an lldb-mi bug?), but the extension suffers as a result - in that case, maybe there is something between the interaction with lldb-mi and cpptools that could avoid triggering the bug.

To Reproduce

(I've also prepared a tiny repo for easily reproducing the problem here: https://github.com/andrewfindon/lldbmi-freeze)

To trigger the problem, step in to the freeze_up() function in the example below. The lldb-mi process should spike in cpu/memory usage and vscode will appear to freeze waiting for local variables to resolve.

main.cpp

#include <initializer_list>

void freeze_up()
{
	auto bad_var = {1, 2, 3};		// A breakpoint here will trigger the issue.
}						// A breakpoint here is fine (bad_var is initialised).

int main() {
	freeze_up();
	
	return 0;
}

launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/freeze",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "lldb",
            "preLaunchTask": "clang++ build",

            "logging": {
                "engineLogging": true,
                "trace": true,
                "traceResponse": true
            }
        }
    ]
}

tasks.json

{
    "version": "2.0.0",
    "tasks": [
        {
            "type": "shell",
            "label": "clang++ build",
            "command": "/usr/bin/clang++",
            "args": [
                "main.cpp",
                "-arch",
                "x86_64",
                "-std=c++17",
                "-Wall",
                "-g",
                "-o",
                "freeze",
            ],
            "problemMatcher": [
                "$gcc"
            ],
            "group": "build",
        }
    ]
}

The tail of my engine logging output at the point where the debugger has frozen on a breakpoint, looks like:

--> E (stopped): {"type":"event","event":"stopped","body":{"reason":"step","threadId":1,"allThreadsStopped":true,"source":{"name":"main.cpp","path":"/Users/andrewfindon/Documents/lldbmi-crash/main.cpp","sources":[],"checksums":[]},"line":6,"column":1},"seq":641}
<--   C (threads-12): {"command":"threads","type":"request","seq":12}
--> R (threads-12): {"type":"response","request_seq":12,"success":true,"command":"threads","body":{"threads":[{"id":1,"name":"Thread #1"}]},"seq":644}
<--   C (stackTrace-13): {"command":"stackTrace","arguments":{"threadId":1,"startFrame":0,"levels":20},"type":"request","seq":13}
--> R (stackTrace-13): {"type":"response","request_seq":13,"success":true,"command":"stackTrace","body":{"stackFrames":[{"id":1000,"name":"freeze!freeze_up()","source":{"name":"main.cpp","path":"/Users/andrewfindon/Documents/lldbmi-crash/main.cpp","sources":[],"checksums":[]},"line":6,"column":1,"moduleId":1},{"id":1001,"name":"freeze!main","source":{"name":"main.cpp","path":"/Users/andrewfindon/Documents/lldbmi-crash/main.cpp","sources":[],"checksums":[]},"line":12,"column":1,"moduleId":1},{"id":1002,"name":"libdyld.dylib!start","line":0,"column":0,"moduleId":12},{"id":1003,"name":"libdyld.dylib!start","line":0,"column":0,"moduleId":12}],"totalFrames":4},"seq":647}
<--   C (scopes-14): {"command":"scopes","arguments":{"frameId":1000},"type":"request","seq":14}
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (33618) <-1018-stack-list-variables 0 --thread 1 --frame 0\n"},"seq":650}
1: (33618) <-1018-stack-list-variables 0 --thread 1 --frame 0
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (33631) ->1018^done,variables=[{name=\"bad_var\"}]\n"},"seq":652}
1: (33631) ->1018^done,variables=[{name="bad_var"}]
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (33631) ->(gdb)\n"},"seq":654}
1: (33631) ->(gdb)
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (33632) 1018: elapsed time 13\n"},"seq":656}
1: (33632) 1018: elapsed time 13
--> E (output): {"type":"event","event":"output","body":{"category":"console","output":"1: (33657) <-1019-var-create - - \"bad_var\" --thread 1 --frame 0\n"},"seq":658}
1: (33657) <-1019-var-create - - "bad_var" --thread 1 --frame 0

Here's a trace of lldb-mi in Instruments - it's clear on the timeline when I stepped in to the freeze_up function:

Example debugging session:

lldb-mi seems to already have some issues being slow debugging as per #1899 (comment).

For Apple Silicon, it will be slow since both the Debug Adapter (MIEngine) and lldb-mi will both be running in emulation.

To fix the latter, it is dependent on #7035

Please note, this issue applies equally to Intel machines (I mention Apple Silicon only to be thorough).

Also, I have left It in this high cpu, high memory state for "some time" (multiple minutes) - it doesn't seem to recover (so less about it being slow, and more about it getting stuck).

cpptools no longer responds, except for cancelling debugging (but this leaves lldb-mi running in the background eating cpu and rapidly draining battery).

This ~6 line sample is enough to break the debugging experience entirely, but personally I've encountered these symptoms a couple of times in actual code, although then I think it was an uninitialised std::vector that was the trigger.

Anecdotally it seems like the debugger is reaching in to the uninitiated memory forever to resolve values for the local variables view.

+1 for this issue, macOS Catalina 10.15.7, Intel CPU.
However:

all variables in the function I'm trying to stop in seems to be initialized
when put breakpoint in called function, I'm able to navigate, and when returning to the original function see this:

at the moment of stop all of those variables are initialized
if it helps, I'm building with -fsanitize=address,undefined. Removing this doesn't change the behaviour.

Same problem here. Would like to know how to address it.

I have recompiled my lldb-mi with this patch:

diff --git a/src/MICmdCmdVar.cpp b/src/MICmdCmdVar.cpp
index 6712a48..e9ceab7 100644
--- a/src/MICmdCmdVar.cpp
+++ b/src/MICmdCmdVar.cpp
@@ -304,7 +304,8 @@ void CMICmdCmdVarCreate::CompleteSBValue(lldb::SBValue &vrwValue) {
   // And update its children
   lldb::SBType valueType = vrwValue.GetType();
   if (!valueType.IsPointerType() && !valueType.IsReferenceType()) {
-    const MIuint nChildren = vrwValue.GetNumChildren();
+    const auto temp = vrwValue.GetNumChildren();
+    const MIuint nChildren = temp > 64 ? 64 : temp;
     for (MIuint i = 0; i < nChildren; ++i) {
       lldb::SBValue member = vrwValue.GetChildAtIndex(i);
       if (member.IsValid())

Same problem here

andrewfindon

I just experienced this a few minutes ago. I am on MacOS Monterey, v12.3.1, Intel CPU.
I was able to hit breakpoints, but then realized my debugger controls (Continue, Step Over, Step In) were completely unresponsive. I was able to press stop to quit debugging as andrewfindon mentioned. But then my laptop tried to enter orbit... fans on full blast, CPU utilization pegged at 100%. Activity Monitor showed several instances (I guess because I had hit stop and rerun the debugger a few times) of lldb-mi using lots of memory and 100% CPU. Stopping them manually through Activity Monitor resolved the issue and the fan/utilization went back to normal levels.

A few quick Google searches led me here. I'm glad to see that it's an issue that's still getting attention.

This helped me to avoid the problem for now.
Looking forward for a permanent fix though.

Hey guys, do you have a solution for Linux users?
Cheers!

Hey, any news on this?

Hey, any news on this?

I do not think this is a VSCode issue. This is truly a problem with the lldb. See my patch above. lldb is out-of-bounds-ing on walking uninitialized variables with garbage values on things like internal counters and sizes. My quick yet brutal fix is to limit these things to 64.

Unfortunately, VSCode tries to render all local variables in the current scope. And when it reaches one of those not-yet-initialized vars, it behaves like that.

As a workaround, I installed CodeLLDB. It fixed the issue. Still, vscode's own debugger got lldb to use all the memory in my machine, which in turn made it unresponsive and I had to restart it.

Gavriloaie Eugen-Andrei (@shiretu)

I ran into this today. Since Gavriloaie Eugen-Andrei (@shiretu) says this is an lldb-mi issue, I guess the place to track it is here?

Gavriloaie Eugen-Andrei (@shiretu)

I have recompiled my lldb-mi with this patch:

diff --git a/src/MICmdCmdVar.cpp b/src/MICmdCmdVar.cpp
index 6712a48..e9ceab7 100644
--- a/src/MICmdCmdVar.cpp
+++ b/src/MICmdCmdVar.cpp
@@ -304,7 +304,8 @@ void CMICmdCmdVarCreate::CompleteSBValue(lldb::SBValue &vrwValue) {
   // And update its children
   lldb::SBType valueType = vrwValue.GetType();
   if (!valueType.IsPointerType() && !valueType.IsReferenceType()) {
-    const MIuint nChildren = vrwValue.GetNumChildren();
+    const auto temp = vrwValue.GetNumChildren();
+    const MIuint nChildren = temp > 64 ? 64 : temp;
     for (MIuint i = 0; i < nChildren; ++i) {
       lldb::SBValue member = vrwValue.GetChildAtIndex(i);
       if (member.IsValid())

Gavriloaie Eugen-Andrei (@shiretu) Would you consider improving it and then submit it to lldb-mi?

This is still happening with cpptools v1.18.5. I disabled the "Variables" view of the debugger so I can get some work done. Mouse hover on a variable still shows the variables when needed.

James Juett (@jamesjuett)

I actually had it freeze again after removing the file James Juett (@jamesjuett)

cd ~/.vscode/extensions/vadimcn.vscode-lldb-1.10.0/lldb/bin
rm debugserver

But hiding the variables section in the debug window does work (rerunning after hiding)

OS and Version: MacOS 14.5 (Sonoma)
VS Code Version: 1.91.1
C/C++ Extension Version: 1.21.2
Mac Air M2 chip

This issue still persists

This is an issue with synthetic child providers. For STL classes you often don't want to see the actual children of a std::list<T> or std::vector<T>, you want to see the children as an array. When we have uninitialized variables, the synthetic child provider has to be very careful to check for invalid values and not do too much work when calculating the number of children. So this can most likely be fixed by checking out the typename of the type that is causing this delay, and then finding out which synthetic child provider it is using and adding a fix to this formatter if upstream LLDB doesn't already have it fixed. To see which synthetic formatters are enabled, type this command at the prompt:

(lldb) type synthetic list

And then with the variable that causes the problem run:

(lldb) frame variable --raw <name>

The --raw option will disable the synthetic child plug-in. These synthetic plugins can either be natively compiled into lldb, or they can be python modules that add the support. If they are python then it is usually easy to fix right away. If the synthetic child provider is compiled into LLDB, then a new version of LLDB will need to be distributed. This formatter does seem to have issues. I just compiled your example and ran this in the command line:

Process 10801 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step in
    frame #0: 0x0000000100003f20 a.out`freeze_up() at main.cpp:5:17
   2   	
   3   	void freeze_up()
   4   	{
-> 5   		auto bad_var = {1, 2, 3};		// A breakpoint here will trigger the issue.
   6   	}						// A breakpoint here is fine (bad_var is initialised).
   7   	
   8   	int main() {
(lldb) fr var
(std::initializer_list<int>) bad_var = {
  [0] = 72715400
  [1] = 2
  [2] = 0
  [3] = 0
  [4] = 0
  [5] = 0
  [6] = 0
  [7] = 0
  [8] = 0
  [9] = 0
  [10] = 0
  [11] = 0
  [12] = 16
  [13] = 0
  [14] = 5
  [15] = 0
  [16] = 1876948112
  [17] = 1
  [18] = 49200
  [19] = 1
  [20] = 0
  [21] = 0
  [22] = 0
  [23] = 0
  [24] = 0
  [25] = 0
  [26] = 0
  [27] = 0
  [28] = 671744
  [29] = 1
  [30] = 16384
  [31] = 0
  [32] = 688128
  [33] = 1
  [34] = 327680
  [35] = 0
  [36] = 0
  [37] = 0
  [38] = 0
  [39] = 0
  [40] = 0
  [41] = 0
  [42] = 0
  [43] = 0
  [44] = 0
  [45] = 0
  [46] = 0
  [47] = 0
  [48] = 0
  [49] = 0
  [50] = 0
  [51] = 0
  [52] = 0
  [53] = 0
  [54] = 0
  [55] = 0
  [56] = 0
  [57] = 0
  [58] = 0
  [59] = 0
  [60] = 0
  [61] = 0
  [62] = 0
  [63] = 0
  [64] = 0
  [65] = 0
  [66] = 0
  [67] = 0
  [68] = 0
  [69] = 0
  [70] = 0
  [71] = 0
  [72] = 0
  [73] = 0
  [74] = 0
  [75] = 0
  [76] = 0
  [77] = 0
  [78] = 0
  [79] = 0
  [80] = 0
  [81] = 0
  [82] = 0
  [83] = 0
  [84] = 0
  [85] = 0
  [86] = 0
  [87] = 0
  [88] = 1876948240
  [89] = 1
  [90] = -1753497600
  [91] = 1
  [92] = 393232384
  [93] = 0
  [94] = -1754251264
  [95] = 1
  [96] = 49152
  [97] = 1
  [98] = 1876948664
  [99] = 1
  [100] = 0
  [101] = 0
  [102] = 0
  [103] = 1325694976
  [104] = 0
  [105] = 0
  [106] = 0
  [107] = 1
  [108] = 1
  [109] = 0
  [110] = 1876949096
  [111] = 1
  [112] = 0
  [113] = 0
  [114] = 1876949117
  [115] = 1
  [116] = 1876949151
  [117] = 1
  [118] = 1876949171
  [119] = 1
  [120] = 1876949186
  [121] = 1
  [122] = 1876949217
  [123] = 1
  [124] = 1876949231
  [125] = 1
  [126] = 1876949250
  [127] = 1
  [128] = 1876949272
  [129] = 1
  [130] = 1876949286
  [131] = 1
  [132] = 1876949303
  [133] = 1
  [134] = 1876949360
  [135] = 1
  [136] = 1876949392
  [137] = 1
  [138] = 1876949432
  [139] = 1
  [140] = 1876949451
  [141] = 1
  [142] = 1876949468
  [143] = 1
  [144] = 1876949480
  [145] = 1
  [146] = 1876949491
  [147] = 1
  [148] = 1876949525
  [149] = 1
  [150] = 1876949553
  [151] = 1
  [152] = 1876950259
  [153] = 1
  [154] = 1876950270
  [155] = 1
  [156] = 1876950278
  [157] = 1
  [158] = 1876950286
  [159] = 1
  [160] = 1876950323
  [161] = 1
  [162] = 1876950358
  [163] = 1
  [164] = 1876950379
  [165] = 1
  [166] = 1876950432
  [167] = 1
  [168] = 1876950462
  [169] = 1
  [170] = 1876950489
  [171] = 1
  [172] = 1876950555
  [173] = 1
  [174] = 1876950580
  [175] = 1
  [176] = 0
  [177] = 0
  [178] = 1876949056
  [179] = 1
  [180] = 1876950624
  [181] = 1
  [182] = 1876950640
  [183] = 1
  [184] = 1876950671
  [185] = 1
  [186] = 1876950724
  [187] = 1
  [188] = 1876950753
  [189] = 1
  [190] = 1876950807
  [191] = 1
  [192] = 1876950846
  [193] = 1
  [194] = 1876950887
  [195] = 1
  [196] = 1876950946
  [197] = 1
  [198] = 1876951007
  [199] = 1
  [200] = 1876951021
  [201] = 1
  [202] = 0
  [203] = 0
  [204] = 1667594341
  [205] = 1650553973
  [206] = 1885300076
  [207] = 1030255713
  [208] = 1886221359
  [209] = 1768843567
  [210] = 1768697204
  [211] = 1630499955
  [212] = 1953853230
  [213] = 0
  [214] = 1886221359
  [215] = 1768843567
  [216] = 1768697204
  [217] = 1630499955
  [218] = 1953853230
  [219] = 1297041408
  [220] = 1163018821
  [221] = 1163026263
  [222] = 1230196560
  [223] = 1498566484
  [224] = 1886334781
  [225] = 1869098868
  [226] = 1919051117
  [227] = 1409316709
  [228] = 1028477509
  [229] = 1919251576
  [230] = 892480877
  [231] = 1819239222
  [232] = 1392538223
  [233] = 1280066888
  [234] = 1768042301
  [235] = 1937387374
  [236] = 1398407272
  [237] = 1429159240
  [238] = 1936876915
  [239] = 1818453807
  [240] = 1869904225
  [241] = 1865297774
  [242] = 2037198184
  [243] = 1752398381
  [244] = 1129338880
  [245] = 1095517791
  [246] = 809325383
  [247] = 1476407416
  [248] = 1398752080
  [249] = 1230393925
  [250] = 1314866499
  [251] = 1027951937
  [252] = 1029636144
  [253] = 1920169263
  [254] = 1668246575
  [255] = 1647275105
  ...
}
*** Some of the displayed variables have more members than the debugger will show by default. To show all of them, you can either use the --show-all-children option to frame variable or raise the limit by changing the target.max-children-count setting.

As you can see we stopped asking for children when we reached the target.max-children-count setting. The MI plug-in will want to do the same thing. We can see the raw variable values here:

(lldb) frame variable --show-types --raw
(std::initializer_list<int>) bad_var = {
  (const int *) __begin_ = 0x000000016fdff510
  (size_t) __size_ = 4299233552
}

So we think there are 4299233552 children to show. This value is way to easy to mess up because there isn't much we can do to know when the values are bad. We can check that __begin_ is aligned on a int boundary, but in this case, it works.

In this case the provider is built in:

(lldb) type synthetic info bad_var
synthetic applied to (std::initializer_list<int>) bad_var is:  libc++ std::initializer_list synthetic children

So the question is: is the MI plug-in asking and producing that many children for this variable and that is what is taking the time and blowing up memory? If so, it should stop creating children for a variable when it hits the target.max-children-count lldb setting value.

lldb-mi has attempted to fix this problem in lldb-tools/lldb-mi#115, but it seems that cpptools is not using the latest version of lldb-mi.

Shaoce SUN (@sunshaoce)

Thanks for the info Shaoce SUN (@sunshaoce) . I was able to work around the issue by building lldb-mi from scratch (from commit a6c8c66), and replacing the executable inside ~/.vscode/extensions/ms-vscode.cpptools-1.21.6-darwin-arm64/debugAdapters/lldb-mi/bin/lldb-mi

Obviously any update to the extension would cause the file to be overwritten. Not sure how to update it inside the cpptools extension directly. This whole "downloading" section seems outdated https://github.com/microsoft/vscode-cpptools/blob/main/CONTRIBUTING.md#about-the-code -- there is no packageManager.ts

OS and Version: MacOS 14.6.1 (Sonoma)
VS Code Version: 1.93.1
C/C++ Extension Version: 1.21.6
LLDB Version: lldb-1600.0.36.3
Apple M2 Max Chip

Similar issue, but for me the debugger crashes

ERROR: LLDB exited unexpectedly with exit code 139 (0x8B). Debugging will now abort.

Tried building lldb-mi with the instructions from lldb-tools/lldb-mi#100 using the commit a6c8c66, which made no difference. Also tried the fix from the lldb-tools/lldb-mi#118 for lldb-mi, also no difference.

The workaround of hiding the Variables view from #7240 (comment) works.

Downgrading Xcode to 15.4 (and thus to lldb-1500.0.404.7) also returns the issue to the current state (which for me was still working in most cases).

But hiding the variables section in the debug window does work

Thank you for this tip. Is a great workaround.

Yes I faced the exact same issues with my Mac M2 Sequoia 15.5, but with one more problem. The temperature spiked from low to very high really quickly. I have used VSCode for so much time before and nothing like this ever happened. Only when I tried to do debugging, this happened; and this happened always when I tried to do debugging.

Here's another really small reproducer with a breakpoint on the first line of the main function.

#include <vector>

int main(int argc, const char* argv[]) {
    std::vector<char> data;
    return 0;
}

Right now on an M1 Pro macbook with clang/lldb from the latest Xcode the default build / debug action in vscode on this incredibly simple test case (after also modifying tasks.json to add -lstdc++ to avoid linker errors) causes the spinner on loading the locals list. On stopping debugging it leaves the lldb-mi process around, consuming 100% of a CPU core and gobbling memory at a rate of around 1GB every 10 seconds. The first time it happened I needed to hard reset my laptop as I hadn't noticed that runaway process before the system became unresponsive. This feels like a pretty serious issue that I'd argue makes C++ debugging in vscode on vanilla Mac configurations actively harmful.

To summarise what I've learnt of the background, it seems there are two possible ways that vscode can communicate with LLDB - lldb-mi, and lldb-dap.

lldb-mi implements a subset of the GCC-defined Machine Interface but adapts it to the LLDB public API.
lldb-mi was contributed to LLVM but is no longer actively maintained and has been split off to a separate repo.
lldb-dap is actively supported upstream but seems like there are still some reasons vscode-cpptools has not made the switch yet.

LLVM themselves do publish a lldb-dap extension for vscode which does not suffer from this issue, so installing that from the marketplace is a simple workaround.

The issue with the version of lldb-mi shipped with this extension is that it recurses into children when evaluating variables. lldb implements synthetic children for things like std::vector and if the memory is corrupt or uninitialised that can lead to an incredibly large number of children (the lldb-dap debugger doesn't do the recursion and reports the size of the vector as 5166693 before stepping over the initialization line where it is initialized to 0).

Even though it's not very actively maintained, the lldb-mi repo does appear to have a fix for this:
lldb-tools/lldb-mi@2340ff2

It looks like the binary shipped with vscode is built from the scripts in the Build/lldb-mi folder which reference a specific older lldb-mi commit from before the fix listed above.

So therefore if there are valid reasons for not switching to lldb-dab just yet, then at least updating lldb-mi (or just applying a patch based on the commit above) should resolve this issue and the many others referencing debugging hangs on lldb/Mac.

I tried just updating the reference above in a fork but it looks like that workflow doesn't run on GitHub but rather on some separate azure infrastructure? Would it be possible for someone on the vscode team just to try bumping that to a newer commit for testing?

Navigation Menu

Repository navigation

lldb-mi freezes on MacOS when breaking near uninitialised variables #7240

6 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

lldb-mi freezes on MacOS when breaking near uninitialised variables #7240

Description

Activity

WardenGnaw commented on Mar 29, 2021

andrewfindon commented on Mar 29, 2021

ni4 commented on Jun 19, 2021

Wdong04 commented on Aug 30, 2021

shiretu commented on Dec 20, 2021

Ayasra commented on Mar 19, 2022

PenceGL commented on Apr 7, 2022

AgraVator commented on Apr 24, 2022

lp35 commented on Aug 10, 2022

vlebourl commented on Sep 13, 2022

shiretu commented on Oct 5, 2022

jpcofr commented on Mar 12, 2023

garfieldnate commented on Aug 25, 2023

6 remaining items

sunshaoce commented on Nov 29, 2023

robUx4 commented on Feb 17, 2024

wbf22 commented on May 16, 2024

ddavlet commented on Jul 23, 2024

clayborg commented on Aug 6, 2024

clayborg commented on Aug 6, 2024

clayborg commented on Aug 6, 2024

sunshaoce commented on Aug 7, 2024

KevinEady commented on Aug 17, 2024

jjaine commented on Oct 9, 2024

icppWorld commented on Jan 22, 2025

Ritil-Ranjan commented on Jul 8, 2025

tangobravo commented on Oct 13, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions