You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
tracing/eventpipe/eventsvalidation tests failing with AF: codeLength > 0 #69375
Based on the investigation below, this assert is just one of the possible failure modes of this test due this bug. Any crash or AF with ETW::MethodLog::SendEventsForJitMethods on stack is potentially caused by this bug.
The rundown is trying to access GCInfo of a dynamic method. The dynamic method that it is trying to access appears to be destroyed already and its memory was overwritten that leads to the assert.
The finalizer thread is actively running and destroying other dynamic methods.
Has there only been one instance of this failing? If this is indeed a race condition in the tracing code, I would have assumed we would have seen this issue for a long time. Rundown logic hasn't changed significantly in a long time. I would assert that something else changed around the tracing code. I'll take a look at the PR Tom mentioned and see if I spot anything.
If this is indeed a race condition in the tracing code,
Yes, it is.
The heap enumeration and code memory allocation are all protected by m_CodeHeapCritSec. The problem that this lock does not protect the initialization of this memory. Here is the sequence of events that leads to this assert:
EEJitManager::allocGCInfo allocates a piece of memory for GCInfo and sets up codeheader to point to this memory (under m_CodeHeapCritSec lock)
The tracing code kicks in and starts enumerating the codeheap. It will see a codeheader that points to GCInfo block that was not initialized yet. It is what triggers the assert above.
The JIT initializes GCInfo. It is too late. The tracing code crashed on the uninitialized GCInfo already.
Thanks for the clarification! Presumably this race has been around for a long time then. We'll take a look at adjusting the tracing code to handle this case.
coreclr Linux arm Checked no_tiered_compilation @ (Ubuntu.1804.Arm32.Open)Ubuntu.1804.Armarch.Open@mcr.microsoft.com/dotnet-buildtools/prereqs:ubuntu-18.04-helix-arm32v7-bfcd90a-20200121150440
- tracing/eventpipe/eventsvalidation/ExceptionThrown_V1/ExceptionThrown_V1.sh
Error message:
Assert failure(PID 377 [0x00000179], Thread: 379 [0x017b]): codeLength > 0
File: /__w/1/s/src/coreclr/vm/eetwain.cpp Line: 5880
Image: /root/helix/work/correlation/corerun
/root/helix/work/workitem/e/tracing/eventpipe/eventsvalidation/ExceptionThrown_V1/ExceptionThrown_V1.sh: line 408: 377 Aborted (core dumped) $LAUNCHER $ExePath "${CLRTestExecutionArguments[@]}"
Return code: 1
Raw output file: /root/helix/work/workitem/uploads/Reports/tracing.eventpipe/eventsvalidation/ExceptionThrown_V1/ExceptionThrown_V1.output.txt
Raw output:
BEGIN EXECUTION
/root/helix/work/correlation/corerun -p System.Reflection.Metadata.MetadataUpdater.IsSupported=false ExceptionThrown_V1.dll ''
0.0s: ==TEST STARTING==
3.3s: Attempting to delete the zombied pipe: /tmp/dotnet-diagnostic-310-7465873-socket
3.3s: Deleted
3.4s: Started sending sentinel events...
3.5s: Connecting to EventPipe...
5.5s: Creating EventPipeEventSource...
5.6s: EventPipeEventSource created
5.7s: Dynamic.All callback registered
5.7s: Starting stream processing...
6.5s: Saw new provider 'Microsoft-DotNETCore-SampleProfiler'
6.6s: Saw sentinel event
6.6s: Stopped sending sentinel events
6.7s: Starting event generating action...
6.7s: Thrown an excpetion 0 times...
6.7s: Thrown an excpetion 100 times...
6.8s: Thrown an excpetion 200 times...
6.8s: Saw new provider 'Microsoft-Windows-DotNETRuntime'
6.8s: Thrown an excpetion 300 times...
6.9s: Thrown an excpetion 400 times...
6.9s: Thrown an excpetion 500 times...
7.0s: Thrown an excpetion 600 times...
7.0s: Thrown an excpetion 700 times...
7.1s: Thrown an excpetion 800 times...
7.1s: Thrown an excpetion 900 times...
7.1s: Stopping event generating action
7.2s: Sending StopTracing command...
[createdump] Gathering state for process 377 corerun
[createdump] Crashing thread 0000017b signal 00000006
[createdump] Writing minidump with heap to file /home/helixbot/dotnetbuild/dumps/coredump.377.dmp
[createdump] Written 146321408 bytes (35723 pages) to core file
[createdump] Dump successfully written
Expected: 100
Actual: 134
END EXECUTION - FAILED
Test Harness Exitcode is : 1
To run the test:
set CORE_ROOT=/root/helix/work/correlation
/root/helix/work/workitem/e/tracing/eventpipe/eventsvalidation/ExceptionThrown_V1/ExceptionThrown_V1.sh
Expected: True
Actual: False
Stack trace
at tracing_eventpipe._eventsvalidation_ExceptionThrown_V1_ExceptionThrown_V1_._eventsvalidation_ExceptionThrown_V1_ExceptionThrown_V1_sh()
Activity
jkotas commentedon May 15, 2022
More info from the dump.
jkotas commentedon May 15, 2022
The rundown is trying to access GCInfo of a dynamic method. The dynamic method that it is trying to access appears to be destroyed already and its memory was overwritten that leads to the assert.
The finalizer thread is actively running and destroying other dynamic methods.
jkotas commentedon May 15, 2022
This appears to be a race condition in the rundown code.
jkotas commentedon May 15, 2022
You should be able to hit this crash more reliably by handcrafting a test that creates and destroys a lot of dynamic methods.
tommcdon commentedon May 16, 2022
@josalem
tommcdon commentedon May 16, 2022
Related to 6f563b3?
josalem commentedon May 19, 2022
Has there only been one instance of this failing? If this is indeed a race condition in the tracing code, I would have assumed we would have seen this issue for a long time. Rundown logic hasn't changed significantly in a long time. I would assert that something else changed around the tracing code. I'll take a look at the PR Tom mentioned and see if I spot anything.
jkotas commentedon May 19, 2022
Yes, it is.
The heap enumeration and code memory allocation are all protected by
m_CodeHeapCritSec. The problem that this lock does not protect the initialization of this memory. Here is the sequence of events that leads to this assert:EEJitManager::allocGCInfoallocates a piece of memory for GCInfo and sets up codeheader to point to this memory (underm_CodeHeapCritSeclock)josalem commentedon May 19, 2022
Thanks for the clarification! Presumably this race has been around for a long time then. We'll take a look at adjusting the tracing code to handle this case.
VincentBu commentedon May 24, 2022
Failed again in: runtime-coreclr outerloop 20220523.2
Failed test:
Error message:
tommcdon commentedon Jun 7, 2022
@davmason ptal
tommcdon commentedon Jun 10, 2022
This test has 1 failure in the last 2 weeks, removing the blocking-ci tag