packetbeat/protos/memcache: don't panic when a transaction is empty #33853
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
efd6
added
bug
Packetbeat
backport-7.17
botelastic
bot
added
the
needs_team
When a *transaction is constructed from a UDP stream, but has no request and no response, onTransaction is handed a nil *transaction, resulting in a panic in Event when the *transaction.Notes field is accessed. The panic is not recovered by ParseUDP's recover because the panic happens in a separate goroutine. So be more careful with pointer dereferencing in this path and put a separate recover in the time.AfterFunc-called closure.
botelastic
bot
removed
the
needs_team
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
💚 Flaky test reportTests succeeded. 🤖 GitHub commentsExpand to view the GitHub comments
To re-run your PR in the CI, just comment with:
|
|
Pinging @elastic/security-external-integrations (Team:Security-External Integrations) |
|
@efd6 can you fix the error handling issues, otherwise LGTM. |
|
@ShourieG I'd rather not touch additional code here. |
ShourieG
approved these changes
Dec 5, 2022
mergify bot
pushed a commit
that referenced
this pull request
Dec 5, 2022
…33853) When a *transaction is constructed from a UDP stream, but has no request and no response, onTransaction is handed a nil *transaction, resulting in a panic in Event when the *transaction.Notes field is accessed. The panic is not recovered by ParseUDP's recover because the panic happens in a separate goroutine. So be more careful with pointer dereferencing in this path and put a separate recover in the time.AfterFunc-called closure. (cherry picked from commit 248c9b0)
mergify bot
pushed a commit
that referenced
this pull request
Dec 5, 2022
…33853) When a *transaction is constructed from a UDP stream, but has no request and no response, onTransaction is handed a nil *transaction, resulting in a panic in Event when the *transaction.Notes field is accessed. The panic is not recovered by ParseUDP's recover because the panic happens in a separate goroutine. So be more careful with pointer dereferencing in this path and put a separate recover in the time.AfterFunc-called closure. (cherry picked from commit 248c9b0)
efd6
added a commit
that referenced
this pull request
Dec 5, 2022
…33853) (#33936) When a *transaction is constructed from a UDP stream, but has no request and no response, onTransaction is handed a nil *transaction, resulting in a panic in Event when the *transaction.Notes field is accessed. The panic is not recovered by ParseUDP's recover because the panic happens in a separate goroutine. So be more careful with pointer dereferencing in this path and put a separate recover in the time.AfterFunc-called closure. (cherry picked from commit 248c9b0) Co-authored-by: Dan Kortschak <90160302+efd6@users.noreply.github.com>
efd6
added a commit
that referenced
this pull request
Dec 5, 2022
…33853) (#33935) When a *transaction is constructed from a UDP stream, but has no request and no response, onTransaction is handed a nil *transaction, resulting in a panic in Event when the *transaction.Notes field is accessed. The panic is not recovered by ParseUDP's recover because the panic happens in a separate goroutine. So be more careful with pointer dereferencing in this path and put a separate recover in the time.AfterFunc-called closure. (cherry picked from commit 248c9b0) Co-authored-by: Dan Kortschak <90160302+efd6@users.noreply.github.com>
chrisberkhout
pushed a commit
that referenced
this pull request
Jun 1, 2023
…33853) When a *transaction is constructed from a UDP stream, but has no request and no response, onTransaction is handed a nil *transaction, resulting in a panic in Event when the *transaction.Notes field is accessed. The panic is not recovered by ParseUDP's recover because the panic happens in a separate goroutine. So be more careful with pointer dereferencing in this path and put a separate recover in the time.AfterFunc-called closure.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
When a *transaction is constructed from a UDP stream, but has no request and no response, onTransaction is handed a nil *transaction, resulting in a panic in Event when the *transaction.Notes field is accessed. The panic is not recovered by ParseUDP's recover because the panic happens in a separate goroutine. So be more careful with pointer dereferencing in this path and put a separate recover in the time.AfterFunc-called closure.
Why is it important?
The panic causes loss of packetbeat service in some situations.
Checklist
CHANGELOG.next.asciidocorCHANGELOG-developer.next.asciidoc.Author's Checklist
How to test this PR locally
Related issues
Use cases
Screenshots
Logs