Off-by-one error in buffer handling during P/Invoke

[bart-vmware]

Description

A bug in Microsoft.Diagnostics.Tracing.TraceEvent was recently fixed; see microsoft/perfview#2226 for details.

Please update the various global tools (particularly dotnet-stack, dotnet-dump and dotnet-gcdump) to the latest version of this library, so we can benefit from the fix.

Note that the fix in Microsoft.Diagnostics.Tracing.TraceEvent hasn't been released yet. However, I thought it best to log this now, as it may take some effort to update to the latest released version. That work can already be done to reduce the effort required to update to the next release.

[bart-vmware]

The fix was released in https://github.com/microsoft/perfview/releases/tag/v3.1.23.

Please don't treat this issue as an extreme corner case that happens only once per decade. We have an integration test in our CI environment that fails once or twice a week due to this.

Tagging @cshung and @brianrob for possibly related work in #3255.

[hoyosjs]

Sound like we should at least try to update TraceEvent to 3.1.23.

That being said @bart-vmware, the stack you see is coming from a call to TraceEventStackSource.GetSourceLine which report doesn't use. I also don't see calls to LookupSymbols that'd end up there.

[bart-vmware]

Thanks. The tools themselves probably don't require this, but our code does.

Unfortunately, we won't be able to benefit from this once merged. Our project references both gcdump and Microsoft.Diagnostics.Tracing.TraceEvent. Since they both ship with a private copy of Microsoft.Diagnostics.FastSerialization.dll, they must be binary compatible. Otherwise, a TypeLoadException occurs at runtime.

Due to this, we are forced to reference version 3.1.16 of Microsoft.Diagnostics.Tracing.TraceEvent (an outdated version). The latest version ships with Microsoft.Diagnostics.FastSerialization.dll v3.1.23, which is incompatible with the latest version of gcdump, which ships with a private copy of Microsoft.Diagnostics.FastSerialization.dll v3.1.16.

Sorry for not explaining this more clearly until now. Would you like me to open a separate issue to update to the latest version of Microsoft.Diagnostics.FastSerialization.dll?

[hoyosjs]

This should be enough - the traceevent package is what brings the fast serialization library for us. That being said, our gcdump package is a tool package - it's not meant to be referenced as a build dep, so I'm not sure how it's handling unification on your side but that would explain it. I just checked and the nightly package contains the 3.1.23 version of the dll.