Bus error when parsing EventPipeProviderConfiguration

[swift-kim]

Target platform: Tizen armel (32bit ARM processes on 64bit HW)

SIGBUS is raised at the following line if bufferCursor points to an unaligned address.

runtime/src/coreclr/src/vm/eventpipeprotocolhelper.cpp

Lines 159 to 161 in 03f8ed5

	uint64_t keywords = 0;
	if (!TryParse(bufferCursor, bufferLen, keywords))
	return false;

Thread 7 "dotnet-launcher" received signal SIGBUS, Bus error.
(gdb) bt
#0  EventPipeProtocolHelper::TryParseProviderConfiguration (bufferCursor=@0xf0843aa0: 0xf360bb05 "\377\377\377\377", bufferLen=@0xf0843a9c: 102, result=...)
    at /usr/src/debug/coreclr-3.0.0/src/vm/eventpipeprotocolhelper.cpp:160
#1  0xf5412174 in EventPipeCollectTracing2CommandPayload::TryParse (lpBuffer=0xf360baf8 "", BufferSize=@0xf0843ad2: 115) at /usr/src/debug/coreclr-3.0.0/src/vm/eventpipeprotocolhelper.cpp:70
#2  0xf54127ca in DiagnosticsIpc::IpcMessage::TryParsePayloadImpl<EventPipeCollectTracing2CommandPayload, 0> (this=0xf0843b30) at /usr/src/debug/coreclr-3.0.0/src/vm/diagnosticsprotocol.h:519
#3  DiagnosticsIpc::IpcMessage::TryParsePayload<EventPipeCollectTracing2CommandPayload> (this=0xf0843b30) at /usr/src/debug/coreclr-3.0.0/src/vm/diagnosticsprotocol.h:293
#4  EventPipeProtocolHelper::CollectTracing2 (message=..., pStream=0xf3608bf0) at /usr/src/debug/coreclr-3.0.0/src/vm/eventpipeprotocolhelper.cpp:265
#5  0xf5406bf8 in DiagnosticsServerThread (lpThreadParameter=0xf7a3aa18) at /usr/src/debug/coreclr-3.0.0/src/vm/diagnosticserver.cpp:76
#6  0xf565c726 in CorUnix::CPalThread::ThreadEntry (pvParam=0xf7a3f248) at /usr/src/debug/coreclr-3.0.0/src/pal/src/thread/thread.cpp:1807
#7  0xf7315f04 in start_thread (arg=0xf0844180) at pthread_create.c:335
#8  0xf708c7d8 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:86 from /lib/libc.so.6

• It tries to parse 8 bytes (uint64_t) from 0xf360bb05 (unaligned) but it seems it's not allowed for this platform.
• Reading a 4-byte (uint32_t) value is completely okay.
• The cursor points at an odd number address because TryParseRundownRequested() increases it by a boolean size.
• To reproduce the error, just run dotnet-counters monitor with default providers. However I couldn't reproduce on non-Tizen armel machine.

/cc @jkotas @alpencolt

[jkotas]

The TryParse method is using non-portable reinterpret_cast that will break when the C/C++ compiler chooses to emit instructions that require strict alignment.

@swift-kim Are you interested in submitting a PR with a fix?

One way to fix the alignment problem is to use memcpy that will tells the C/C++ compiler that the memory might not be aligned. memcpy is intrinsic on any recent C/C++ compiler, so there should be not performance penalty for using it.

cc @dotnet/dotnet-diag @lateralusX

[swift-kim]

Sure. I'll test the memcpy solution when back from holiday.

[swift-kim]

FYI, with @josalem's patch and some changes in the TraceEvent library (which has a similar alignment issue in managed code), dotnet-counters now works on this platform.

Press p to pause, r to resume, q to quit.
    Status: Paused

[System.Runtime]
    # of Assemblies Loaded                            52
    % Time in GC (since last GC)                       0
    Allocation Rate (Bytes / sec)                 40,900
    CPU Usage (%)                                      1
    Exceptions / sec                                   0
    GC Heap Size (MB)                                  0
    Gen 0 GC / sec                                     0
    Gen 0 Size (B)                                 5,920
    Gen 1 GC / sec                                     0
    Gen 1 Size (B)                                29,880
    Gen 2 GC / sec                                     0
    Gen 2 Size (B)                               608,364
    LOH Size (B)                                  40,592
    Monitor Lock Contention Count / sec                0
    Number of Active Timers                            0
    ThreadPool Completed Work Items / sec              0
    ThreadPool Queue Length                            0
    ThreadPool Threads Count                           2
    Working Set (MB)                                  53