Hi,
by mistake we have created a recursive call with endless loop and in Debug this flow throws after few seconds SOE, but when running in Release, the recursive call loop never ends. I do not think that this is by design?
Repository:
https://github.com/ppekrol/ravendb/tree/RavenDB-13682-hang
Test: SlowTests.MailingList.Nberardi.Spatial_Search_Should_Integrate_Distance_As_A_Boost_Factor
Problematic code:
a) Test: https://github.com/ppekrol/ravendb/blob/RavenDB-13682-hang/test/SlowTests/MailingList/nberardi.cs#L53-L56
b) Endless recursive call: https://github.com/ppekrol/ravendb/blob/RavenDB-13682-hang/src/Raven.Client/Documents/Session/AbstractDocumentQuery.Spatial.cs#L119
Behavior:
a) Debug - 2 events in Event Log:
Faulting application name: dotnet.exe, version: 3.0.19.46305, time stamp: 0x5d7bb03a
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc00000fd
Fault offset: 0x00007ff975cd7b37
Faulting process id: 0x4f08
Faulting application start time: 0x01d5801a96c749d9
Faulting application path: C:\Program Files\dotnet\dotnet.exe
Faulting module path: unknown
Report Id: a889719a-f600-47e2-8b2c-e672209e8aae
Faulting package full name:
Faulting package-relative application ID:
Fault bucket 1888251967040835289, type 5
Event Name: CLR20r3
Response: Not available
Cab Id: 0
Problem signature:
P1: C:\Program Files\dotnet\dotnet.exe
P2: 3.0.19.46305
P3: 5d7bb03a
P4: Raven.Client
P5: 4.2.4.42
P6: e5db14ba
P7: 968
P8: 1
P9: System.StackOverflowException
P10:
Attached files:
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERBD3.tmp.mdmp
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER7924.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER7964.tmp.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER7962.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER79C1.tmp.txt
These files may be available here:
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_C__Program Files_209ac05da5c7fd849f852450409f7c9ca02224f7_58b55f8a_3959cacf-4593-4163-9568-1abdc1197665
Analysis symbol:
Rechecking for solution: 0
Report Id: a889719a-f600-47e2-8b2c-e672209e8aae
Report Status: 268435456
Hashed bucket: 2604fd66b8114d5fba346b28dde6ced9
Cab Guid: 0
b) Release (running this via VS2019 Test Runner) - test still runs after 10min
My environment:
a) Windows 10 x64 Pro
b) .NET Core 2.2.7
It's probably getting optimized into a tail call, which won't stack dive, by design. What is the concern?
A crashing app is cheaper to run on Azure than an app that spins. 馃ぃ
You can disable this optimization via COMPlus_TailCallLoopOpt=0 env. variable.
BTW feel free to vote for https://github.com/dotnet/coreclr/issues/20478
It's probably getting optimized into a tail call, which won't stack dive, by design. What is the concern?
The problem for us was that during CI (which runs in Release) for each PR we are running tests in parallel (8), so it was 'not easy' to pinpoint the cause. I would expect runtime to guard against human mistakes and 'inform' me (by throwing SOE). In general I think that runtime should just die, not spin endlessly.
In general I think that runtime should just die, not spin endlessly.
@ppekrol - This is known as the Halting Problem.
The computer/runtime doesn't actually know that the SOE is actually "wanted", per se - it's only throwing the error because of a limitation of physical reality - and it's possible to get SOEs through other, non-recursive, means (you young whippersnappers and your large stack space and heap allocated arrays).
Some compilers _do_ perform analysis that might spot this, especially such a trivial case (a Roslyn analyzer could spot this). But the general case is very difficult/impossible, especially in the face of multithreading/concurrency (where it's possible to have conditions checked be changed by some other thread).
I'm closing this one down then. Thanks for detailed explanation!
Most helpful comment
@ppekrol - This is known as the Halting Problem.
The computer/runtime doesn't actually know that the SOE is actually "wanted", per se - it's only throwing the error because of a limitation of physical reality - and it's possible to get SOEs through other, non-recursive, means (you young whippersnappers and your large stack space and heap allocated arrays).
Some compilers _do_ perform analysis that might spot this, especially such a trivial case (a Roslyn analyzer could spot this). But the general case is very difficult/impossible, especially in the face of multithreading/concurrency (where it's possible to have conditions checked be changed by some other thread).