You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An index out of bounds panic can occasionally occur in the windowseventlog receiver here at buffer.FirstByte().
We believe this happens in due to the bufferUsed being passed in as a pointer to be used as an unsafe pointer inside the Windows system call in evtFormatMessage. In some cases the unsafe pointer likely loses it's reference in the stack frame shift out of the function and this sets bufferUsed to it's zero value. When this error case is triggered and bufferUsed has a value of 0 it resizes the buffer to 0 then the function makes a recursive call to itself. On the next call to buffer.FirstByte() a panic occurs due to indexing into a 0 sized buffer.
When developing this receiver my team hit a similar issue with unsafe pointers in evtRender and changed bufferUsed to be a return value rather than being passed in.
We didn't apply the same logic to evtFormatMessage at the time because it never hit an issue. I propose we copy the same strategy as evtRender with how we use the bufferUsed value.
It's also probably worth doing a safety check on bufferUsed in the case it returns a ErrorInsufficientBuffer and return an error if bufferUsed is 0.
Steps to Reproduce
We were not able to reliably reproduce this it just occasionally would occur if we left it running for several days.
Collector version
v0.66.0
Environment information
Environment
OS: Windows Sever 2022
OpenTelemetry Collector configuration
No response
Log output
No response
Additional context
We have tested the proposed fix and left it run in the same environment for two weeks that was seeing the issue and have not seen any panics.
The text was updated successfully, but these errors were encountered:
Component(s)
Windows Event Log Receiver
What happened?
Description
An index out of bounds panic can occasionally occur in the
windowseventlog
receiver here atbuffer.FirstByte()
.We believe this happens in due to the
bufferUsed
being passed in as a pointer to be used as an unsafe pointer inside the Windows system call in evtFormatMessage. In some cases the unsafe pointer likely loses it's reference in the stack frame shift out of the function and this setsbufferUsed
to it's zero value. When this error case is triggered andbufferUsed
has a value of 0 it resizes the buffer to 0 then the function makes a recursive call to itself. On the next call tobuffer.FirstByte()
a panic occurs due to indexing into a 0 sized buffer.When developing this receiver my team hit a similar issue with unsafe pointers in evtRender and changed
bufferUsed
to be a return value rather than being passed in.We didn't apply the same logic to
evtFormatMessage
at the time because it never hit an issue. I propose we copy the same strategy asevtRender
with how we use thebufferUsed
value.It's also probably worth doing a safety check on
bufferUsed
in the case it returns aErrorInsufficientBuffer
and return an error ifbufferUsed
is 0.Steps to Reproduce
We were not able to reliably reproduce this it just occasionally would occur if we left it running for several days.
Collector version
v0.66.0
Environment information
Environment
OS: Windows Sever 2022
OpenTelemetry Collector configuration
No response
Log output
No response
Additional context
We have tested the proposed fix and left it run in the same environment for two weeks that was seeing the issue and have not seen any panics.
The text was updated successfully, but these errors were encountered: