[test][Eventpipe] Disable eventsourceerror on OSX #105278
Conversation
dotnet-issue-labeler
bot
added
the
needs-area-label
|
Should we rather disable this test completely like it was before? Given that we have seen this test fail on both osx-x64 and linux-arn, the test is very likely going to be flaky on all OSes. |
|
From the linux-arm failure, we couldn't extract anything useful from the dump generated by createdump, and we chalked it up to not being able to generate arm32 dumps very well. The other dump grabbed from the system was partial and insufficient to discovering the problematic code. So our plan was to see if it failed on an OS that we can grab a better dump from (non arm32), but unfortunately, OSX generates a dump that is too large to upload so I was hoping to just get one failure that uploads two useful dumps before disabling it completely. |
I have looked at linux-arm dump earlier. I was able to extract the unmanaged part of the stacktrace of crash: #80666 (comment) . I know that it is a challenge to find a working dump debugger for non-x64 Linux. I often end up using both lldb and gdb together since each of those debuggers have different bugs and limitations. (You can see in #80666 (comment) that I got the stacktrace from gdb.) I did not spent time on extracting the full managed stack trace from the linux-arm dump. It can be done, but it is a labor-intensive process. The problem is that this is a crash inside an FCall, the managed stackwalker does not have a good context to start walking with. The osx-arm64 crash is the same crash in MarshalNative::GCHandleInternalGet according to .crashreport.json. I have submitted #105372 that should allow us to see the full managed stacktrace in .crashreport.json |
After reenabling on non-arm32 linux platforms, #80666 is hitting frequently for osx-x64 running on osx-arm64. Unfortunately, one of the dumps generated is too large for uploading, so disabling on OSX to see if we can get this test to crash on another platform where we can grab useful dumps.