Dart analysis server at 100% cpu indefinitely when opening the Dart SDK repo (or flutter engine, which includes a nested copy)

[gaaclarke]

Description

The dart analysis server just sits at 100% when editing the flutter engine repo.

To Reproduce

1. Check out the flutter engine repo
2. Open it in VSCode with the dart plugin installed
3. Notice that dart process that is running the analysis server sits at around 100% and never stops.

Expected behavior

I would expect the process to reach some stasis of VSCode is not being interacted with.

Screenshots

Maybe it's related that there is a huge number of issues that are reported that I never mind:

Logs

openfiles.txt

sample.txt

Details

• Operating System and version: macOS 14.4.1
• VS Code version: 1.89.0
• Dart extension version: v3.89.20240509 (pre-release)
• Dart/Flutter SDK version: engine 0e23e60093d162e19108fcf28233f918fdafc136
• Target device (if the issue relates to Flutter debugging):

(spawned from #5084)

[gaaclarke]

This PR to the analysis options seems to resolve this issue: flutter/engine#52699

We were just overloading it and getting it into a bad state. It's probably still worth fixing, but it's not an issue for me anymore.

[DanTup]

@gaaclarke do you know if there are extra steps beyond cloning the repo required to trigger this? I wasn't able to reproduce (even with gclient sync). I wonder if there are other steps you may have performed during setting up your environment for the engine.

(eg., if you clone a new copy of the repo, can you trigger it on that?)

[gaaclarke]

No, it can't be a new clone, you have to checkout before: flutter/engine@233a57b

here is my workspace, but i don't see anything that may be off. Maybe the fact that I'm using a workspace is enough to mess it up?

$ cat engine.code-workspace 
{
	"folders": [
		{
			"path": "src/flutter"
		},
		{
			"path": "src/third_party/vulkan-deps/vulkan-headers"
		},
		{
			"path": "src/flutter/lib/ui"
		}
	],
	"settings": {
		"files.associations": {
			"optional": "cpp",
			"__bit_reference": "cpp",
			"__bits": "cpp",
			"__config": "cpp",
			"__debug": "cpp",
			"__errc": "cpp",
			"__hash_table": "cpp",
			"__locale": "cpp",
			"__mutex_base": "cpp",
			"__node_handle": "cpp",
			"__nullptr": "cpp",
			"__split_buffer": "cpp",
			"__string": "cpp",
			"__threading_support": "cpp",
			"__tree": "cpp",
			"__tuple": "cpp",
			"any": "cpp",
			"array": "cpp",
			"atomic": "cpp",
			"bitset": "cpp",
			"cctype": "cpp",
			"chrono": "cpp",
			"cinttypes": "cpp",
			"clocale": "cpp",
			"cmath": "cpp",
			"codecvt": "cpp",
			"compare": "cpp",
			"complex": "cpp",
			"concepts": "cpp",
			"condition_variable": "cpp",
			"csignal": "cpp",
			"cstdarg": "cpp",
			"cstddef": "cpp",
			"cstdint": "cpp",
			"cstdio": "cpp",
			"cstdlib": "cpp",
			"cstring": "cpp",
			"ctime": "cpp",
			"cwchar": "cpp",
			"cwctype": "cpp",
			"deque": "cpp",
			"exception": "cpp",
			"forward_list": "cpp",
			"fstream": "cpp",
			"future": "cpp",
			"initializer_list": "cpp",
			"iomanip": "cpp",
			"ios": "cpp",
			"iosfwd": "cpp",
			"iostream": "cpp",
			"istream": "cpp",
			"limits": "cpp",
			"list": "cpp",
			"locale": "cpp",
			"map": "cpp",
			"memory": "cpp",
			"mutex": "cpp",
			"new": "cpp",
			"numeric": "cpp",
			"ostream": "cpp",
			"queue": "cpp",
			"random": "cpp",
			"ratio": "cpp",
			"regex": "cpp",
			"set": "cpp",
			"span": "cpp",
			"sstream": "cpp",
			"stack": "cpp",
			"stdexcept": "cpp",
			"streambuf": "cpp",
			"string": "cpp",
			"string_view": "cpp",
			"strstream": "cpp",
			"system_error": "cpp",
			"tuple": "cpp",
			"type_traits": "cpp",
			"typeinfo": "cpp",
			"unordered_map": "cpp",
			"unordered_set": "cpp",
			"valarray": "cpp",
			"variant": "cpp",
			"vector": "cpp",
			"algorithm": "cpp",
			"filesystem": "cpp",
			"memory_resource": "cpp",
			"bit": "cpp",
			"charconv": "cpp",
			"format": "cpp",
			"functional": "cpp",
			"iterator": "cpp",
			"utility": "cpp",
			"__assert": "cpp",
			"*.inc": "cpp",
			"__verbose_abort": "cpp",
			"*.def": "cpp",
			"*.hpp11": "cpp",
			"__functional_base": "cpp",
			"shared_mutex": "cpp",
			"coroutine": "cpp",
			"hash_map": "cpp",
			"hash_set": "cpp",
			"thread": "cpp",
			"propagate_const": "cpp",
			"*.gen": "cpp",
			"simd": "cpp"
		},
		"C_Cpp.default.includePath": [
			"${default}",
			"/Users/aaclarke/dev/engine/src/",
			"/Users/aaclarke/dev/engine/src/flutter",
			"/Users/aaclarke/dev/engine/src/third_party/vulkan-deps/vulkan-headers/src/include/"
		],
		"dotnet.defaultSolution": "disable"
	}
}

[DanTup]

I think I may have reproduced this using your workspace. It doesn't seem "stuck" because it's still sending analysis diagnostics (it's generating a lot of diagnostics because there is a copy of the SDK in there that doesn't seem to resolve any packages) but it's been going at least 10 minutes.

I wonder if it's because you have the same folders included multiple times:

{
	"path": "src/flutter"
},
{
	"path": "src/flutter/lib/ui" // this is included by the one above
}

I'll do some more digging, thanks!

[DanTup]

btw, in your workspace above you have:

"path": "src/third_party/vulkan-deps/vulkan-headers"

But I don't have a vulkan-deps at that location (even after gclient sync), it's only at src/flutter/third_party, so this folder shows as "missing". Did I set something up differently to you?

[DanTup]

Seems that this is caused by the Dart SDK in src/third_party/dart. If I open only that folder, I still see the same behaviour. And, if I just open a clone of the Dart SDK directly (not part of engine), I see the same too.

It is known that there are issues trying to analyze the whole SDK repo (it's full of test projects and things), but I'm surprised that it seems to be analyze forever (or at least, it's so slow it doesn't complete in any reasonable amount of time).

An extra weird thing - this repros on Windows (server is stuck forever analyzing), yet it uses almost no CPU to do so (I presume something else is a bottleneck, but nothing else like disk seem saturated oddly).

I'm gonna leave it running in the background and while I for lunch on the chance it does complete, but otherwise I'll do some more debugging to see what's going on.

[DanTup]

I tracked this down to an infinite loop in the linter when there are cycling redirecting constructors. The Dart SDK includes a test file that has that (but I guess never triggers the linter over it in tests).

I've opened dart-lang/linter#4970 with the details and will close this one. Thanks!

[gaaclarke]

Thanks Danny! Yea we've recently moved the vulkan headers but I haven't had the need to update my workspace. I don't even know why I'd have "src/flutter" and "src/flutter/lib/ui" separately. Thanks for figuring it out.