Dotnet build hangs at CoreCompile when specific NuGet package referenced #112502
Comments
|
I'm not 100% sure what's going on here, as I don't understand how adding a PackageReference could possibly make something hang, but I don't see how it's connected to the SDK, so since it's hanging in the CoreCompile stage, I'm tentatively moving it to roslyn for a first look. |
|
Presumably an SG is running and has an infinite loop or something (or just takes a really really long time). Best is to open this in a profiler or debugger and see what stacks it is in when it appears to not be making progress. |
|
That's very likely an issue on https://github.com/reactiveui/ReactiveUI.SourceGenerators @fabianoliver I can't repro by simply adding the package reference to a blank console app. |
|
@Youssef1313 Thanks for having a look. Strange, I've run this on a simple blank console app as well with the csproj file above. I've tried on 2 independent systems and ran into that issue on both of them. I'm running on win10 (though I first ran into this issue via CI build on an unix image) & have attached dotnet --info for reference. I'm trying the build via simple cmd-line execution of "dotnet build". For reference, I've attached a debugger while it appears to be stuck on CoreCompile - as per @CyrusNajmabadi 's suggestion, stack traces of all threads attached as well, in case that helps (though not sure if there's any child processes spawned that might have more relevant traces to look at?). Unfortunately, I agree it feels very much like a potential bug of the library, so the end result might be rather "boring" here; just thought I'd flag this out of caution as personally, I could think of many ways to make source generators hang, but a lot less ways to make them hang just with specific NET SDK versions |
|
Thank you. I'm able to reproduce. I can see one of the threads appear to be stuck here. I can't see any reason this can happen or be specific to SDK version. |
|
I tried to do a bit of investigation here. I created a response file from binlog of the stuck build, and ran that with a locally built compiler for easier debugging. However, what I noticed is analyzer crash that makes sense.
The analyzer is incorrectly authors and uses The mystery here:
@jaredpar @CyrusNajmabadi Does that make any sense to you? |
Did you build the compiler in Debug?
Can't really think of a way it could. Do you have a compiler log I could look at? |
Yup. Is it expected to have this kind of behavior difference between Debug and Release builds of the compiler?
No, I can get one though. |
The underlying error is a
Yes it's pretty easy to repro with 9.0.101. When I look at this under the debugger though it seems that it's the runtime that has locked up here. All the threads which are creating @agocke, @davidwrighton any changes to type loading that could explain this behavior in the .NET 9 timeframe? |
|
@mangod9 It looks like this has a reliable repro that can produce a dump, and is a regression from 9.0 preview. Could someone take a look? |
|
@steveisok This should be looked at by someone on your team. |
|
It looks like the hang is because while trying to acquire the cctor lock for |
|
Before the deadlock, an exception is thrown on the main thread: With the following stack: So my working theory is that this is leaving a lock held which causes us to deadlock later on. |
|
The initial assembly load failure exception appears to happen during JIT compilation for the cctor. For some reason it seems like when we unwind this exception we're skipping straight over the rest of the logic for running the cctor without releasing the lock it's holding (?) which doesn't seem like it should be possible. When I "step out" in windbg it leaps really far up the stack, and the same is true if I try to step through exception handling in Visual Studio as well. There are multiple exception handlers on the stack that intentionally suppress exceptions, which might be part of the problem? But it still doesn't make sense to me that we'd fail to release a lock we're holding inside the runtime. The use of an exception filter in the 2nd one caught my attention.
|
|
Thanks @davidwrighton for helping me determine that setting EDIT: Here's a repro folder |
|
Well at least I think I understand what changed to explain why this is showing up in 9.0.100 but not before. Consider this change where I added the exception filter to this code path. That would've likely appeared first in 9.0.100. Note: will use this situation as another plea to please provide AssemblyLoadContext.TryLoadFromAssemblyName. Having guaranteed exceptions on compiler startup is an endless source of problems for the team. Any debugging of the compiler starts with a series of F5 to skip past the guaranteed exceptions on startup. The more analyzers, the more exceptions. In this case the API would have saved us from this bug 😄 |
|
Let me take a look |
|
I have found the culprit and have a fix. I will send out a PR after creating a simpler regression test for the issue. |
|
It turns out Linux has the same problem. Also, I've found that the fix I have has a problem w.r.t. the inner exception (FileNotFoundException) having an empty stack trace. I need to figure out a good way to fix that too. |
|
@jaredpar The linked runtime PR is merged. I think this can be closed |
|
The fix was reverted in #112466 |
|
The fixed fix was merged in #112666 |
Issue moved from dotnet/sdk#45036
From @fabianoliver on Friday, November 22, 2024 10:10:28 AM
Describe the bug
When using SDK 9.0.100, building any project that references "ReactiveUI.SourceGenerations" version 1.1.31 hangs forever at the "CoreCompile" stage. Building the same project using SDK 8.0.100 works well.
Please feel free to close this issue if you reckon the package itself is at fault of course. I'm raising this here though as I would think that building this with a different SDK version "should" not be able to break the referenced package / source generator in any way?
To Reproduce
Build an empty project with the following csproj
The text was updated successfully, but these errors were encountered: