New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[runincontext] Test failed: tracing_eventpipe._buffersize_buffersize_buffersize_._buffersize_buffersize_buffersize_cmd #13120
Comments
Could be related to: dotnet/coreclr#25786? cc @jorive |
cc @jorive since he was investigating it this morning - Please let me know if you need any help with the investigation :) |
This failure is for a |
Same test Message :
Stack Trace :
|
@janvorli do you have any intuition on what might be going on here? My hunch is that something in the EventPipe client library is failing to unload due to the native components involved in the IPC communication, but I haven't looked at a repro yet. |
I'm not seeing any indication that the test was running using the runincontext tool. Seeing |
@janvorli This is the log:
|
Ah, I've looked only at the most recent log here. |
@janvorli We followed your suggestions and ran the commands you specified. First, !dumpheap -type LoaderAllocator
Then, !gcroot -all 000001b19108b878
The
!DumpObj /d 000001b1910a92f0
At this point, I do not know where to go (how did this object get there?). Could you please give us some guidance or take a look? |
This is a static variable containing instance of the TraceProvider (the 1020 elements array is array of statics). The TraceProvider instance is created from an assembly loaded into the unloadable context, but stored in a static variable outside of that context. That prevents unloading. I am not sure how that ends up happening. It would be interesting to see the stack trace at which the instance of the TraceProvider is created. That should give us a clue whether it is a problem due to the way the test is run in the unloadable context (=> the test is not compatible with the way we run it and so we should disable it for the runincontext testing) or whether there is some problem with the tracing and unloadability that needs to be fixed. |
More information: This is the callstack when
|
I understand the issue now. The Debug.SetProvider is in System.Private.CoreLib that is loaded into the default context. But the Microsoft.Diagnostics.TraceSource.dll was loaded into the testing unloadable context. So we've created an instance of the TraceProvider type from that assembly living in the unloadable context and stored it into a static variable in the default context. We should mark the test as incompatible with the runincontext testing. In real world scenarios, the System.Diagnostics.TraceSource.dll which is a part of the runtime would not be loaded into the unloadable context. |
Job:
https://mc.dot.net/#/user/coreclr-runincontext/ci~2Fdotnet~2Fcoreclr~2Frefs~2Fheads~2Fmaster/test~2Ffunctional~2Fcli~2F/20190721.1/workItem/PayloadGroup0/analysis/xunit/tracing_eventpipe._buffersize_buffersize_buffersize_~2F_buffersize_buffersize_buffersize_cmd
Failed tests:
tracing_eventpipe.buffersize_buffersize_buffersize._buffersize_buffersize_buffersize_cmd
Log:
The text was updated successfully, but these errors were encountered: