FastSerialization throws generic Exception on error

[sywhang]

When an EventPipeEventSource is created with a stream, sometimes FastSerialization can run into error when the target process stops sending data and EventPipeEventSource tries to read off the stream and fails.

This then throws a plain Exception instance, which is rather unfortunate because it makes it hard on the consumer side to catch just this kind of exception and force a catch-all clause.

[brianrob]

@sywhang can you share a call stack for this please?

[sywhang]

This isn't exactly the same example (this one is from creating an EventPipeEventSource from a truncated nettrace file) but it shares a similar call stack:

Error: Exception EventPipe conversion: System.Exception: Read past end of stream.
   at FastSerialization.IOStreamStreamReader.Fill(Int32 minimum)
   at FastSerialization.MemoryStreamReader.ReadByte()
   at FastSerialization.Deserializer.ReadObject()
   at Microsoft.Diagnostics.Tracing.EventPipeEventSource.Process()
   at Microsoft.Diagnostics.Tracing.Etlx.TraceLog.CopyRawEvents(TraceEventDispatcher rawEvents, IStreamWriter writer)
   at Microsoft.Diagnostics.Tracing.Etlx.TraceLog.<>c__DisplayClass118_0.<FastSerialization.IFastSerializable.ToStream>b__0()
   at FastSerialization.DeferedRegion.Write(Serializer serializer, Action toStream)
   at Microsoft.Diagnostics.Tracing.Etlx.TraceLog.FastSerialization.IFastSerializable.ToStream(Serializer serializer)
   at FastSerialization.Serializer.WriteObjectData(IFastSerializable obj, Tags beginTag)
   at FastSerialization.Serializer.WriteObjectRef(IFastSerializable obj, Boolean defered)
   at FastSerialization.Serializer..ctor(IStreamWriter writer, IFastSerializable entryObject)
   at Microsoft.Diagnostics.Tracing.Etlx.TraceLog.CreateFromEventPipeEventSources(TraceEventDispatcher source, String etlxFilePath, TraceLogOptions options)
   at Microsoft.Diagnostics.Tracing.Etlx.TraceLog.CreateFromEventPipeDataFile(String filePath, String etlxFilePath, TraceLogOptions options)

[brianrob]

This comes from

perfview/src/FastSerialization/StreamReaderWriter.cs

Line 817 in 9a743d9

throw new Exception("Read past end of stream.");

.

We certainly have the ability to change this if we want to, and I don't think we have a big compat burden here. That said, the streaming case is interesting, because I would expect that until the connection is terminated, that attempting to read a byte off of the stream could fail in the normal course of business if a byte hasn't been sent. I'm wondering if in the stream case, we need to either block and try again, or return some sort of response that tells the client to try again.

What do you think?

[sywhang]

I'm wondering if in the stream case, we need to either block and try again, or return some sort of response that tells the client to try again.

I think we could just throw an exception and the client can decide whether it wants to retry on such error.

On a side note, do we have a timeout for the read when we're in the streaming case?