[EventPipe] Null passed as an event argument causes crash

[jiangzeng01]

Test:
coreclr\tests\src\tracing\eventsource\eventsourcetrace\EventSourceTrace.cs
Line 23:
this.WriteEvent(1, x, y, z, null);

F:\TempRepo\coreclr>bin\tests\Windows_NT.x64.Debug\tracing\eventsource\eventsourcetrace\eventsourcetrace\eventsourcetrace.cmd
BEGIN EXECUTION
 "F:\TempRepo\coreclr\bin\tests\Windows_NT.x64.Debug\Tests\Core_Root\corerun.exe" eventsourcetrace.exe
        Start: Enable tracing.
        End: Enable tracing.

        Start: Messaging.

Unhandled Exception: System.Diagnostics.Tracing.EventSourceException: Null passed as a event argument.
   at System.Diagnostics.Tracing.EventSource.ThrowEventSourceException(String eventName, Exception innerEx)
   at System.Diagnostics.Tracing.EventSource.WriteEventVarargs(Int32 eventId, Guid* childActivityID, Object[] args)
   at System.Diagnostics.Tracing.EventSource.WriteEvent(Int32 eventId, Object[] args)
   at Tracing.Tests.SimpleEventSource.MathResult(Int32 x, Int32 y, Int32 z, String formula) in F:\TempRepo\coreclr\tests\src\tracing\eventsource\eventsourcetrace\EventSourceTrace.cs:line 23
   at Tracing.Tests.EventSourceTrace.Main(String[] args) in F:\TempRepo\coreclr\tests\src\tracing\eventsource\eventsourcetrace\EventSourceTrace.cs:line 75
Expected: 100
Actual: 255
END EXECUTION - FAILED
FAILED

[sywhang]

@brianrob Is this an expected behavior that's working as design? I tried something similar on Framework and it doesn't seem to be throwing there. Just wanted to know what the correct behavior should be here before I put out a "fix" :-)

[brianrob]

@sywhang, I would expect a null argument passed for formula in Tracing.Tests.SimpleEventSource.MathResult(Int32 x, Int32 y, Int32 z, String formula) should result in that null being written into the trace file. Said another way, null is a legal value for reference types.

[jorive]

I think the function being called here is WriteEvent(Int32, param object[])

[brianrob]

Right - every manifest based event is implemented as something that looks like this:

[Event(1)]
public void MathResult(Int32 x, Int32 y, Int32 z, String formula)
{
    WriteEvent(1, x, y, z, formula);
}

There are various overloads of WriteEvent to avoid the array allocation and subsequent boxing associated with param object[], but if there isn't a specialized overload for the set of arguments to the event then the compiler will bind to WriteEvent(Int32, param object[]).

So even though you see the exception inside fo WriteEvent, the work being done is on-behalf-of the event method.

[daviburg]

I got tripped by that today. I have tracing in place and sometimes one of the write event parameters (type string) is null, most of the time it's not. So first it look all hunky dory then I get this back from customer traces:

EventSourceException while processing event "**redacted**": Null passed as a event argument.

[JJamesWWang]

@davmason @noahfalk Is this issue still actionable? I noticed the original file with the failing test no longer exists.

[noahfalk]

I'm guessing the underlying issue may still actionable even if the test is gone or moved. Given that the bug is 3 years old there was probably some churn in the tests since then. The only way to know for sure would be to recreate a new test case that hits the issue. From the description it appears you would need to create an EventSource that takes a reference type argument such as a string and then pass null to it. Hope that helps!

[AaronRobinsonMSFT]

@JJamesWWang The introduction for EventSource is at https://learn.microsoft.com/dotnet/core/diagnostics/eventsource-getting-started. You could also try searching in git and check the history to recover the old test source that existed in 2019.