Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid deadlocking on log scanning with lots of output on stderr #5738

Merged
merged 4 commits into from
May 7, 2024

Conversation

bk2204
Copy link
Member

@bk2204 bk2204 commented May 7, 2024

When we're running our log scanning code, we can end up with a deadlock if there is lots of output on standard error because we either don't read standard error at all or we only read it when we're done reading standard output. To fix this, let's add and use some functions that either discard standard error if we're not using it, as well as making sure we read standard error in a separate goroutine so the child process doesn't block.

Fixes #5720

bk2204 added 4 commits May 6, 2024 15:23
In some cases, we call `BufferedExec` and only want standard output;
that is, we ignore standard error.  In such a case, we can cause the
data to be buffered forever and we'll block if there's enough of it,
especially on Windows.

Let's add a `StdoutBufferedExec` that redirects standard error to
`/dev/null`, since that's effectively what we're doing already, except
that our new function will be more robust because it won't cause
indefinite blocking.
We already have some small wrappers for `BufferedExec`; let's add some
for `StdoutBufferedExec` which we'll use in a future commit.
These are functions for which we don't care about standard error and
which we don't want to block indefinitely.
When we process log output, we can sometimes get a large amount of
data on standard error, which is buffered.  If we wait until the end to
process it, then the child process can block because it's trying to
write to standard error but we're not reading from it, and in turn we
can block because we're waiting for more standard output.

The solution is simple: process standard error in another goroutine and
send the result over a channel to be read at the end.  This guarantees
that we'll always process the data as expected and prevent deadlock.
@bk2204 bk2204 marked this pull request as ready for review May 7, 2024 15:03
@bk2204 bk2204 requested a review from a team as a code owner May 7, 2024 15:03
@bk2204 bk2204 merged commit 41612f7 into git-lfs:main May 7, 2024
10 checks passed
@bk2204 bk2204 deleted the log-scanner-stderr branch May 7, 2024 17:49
Foxsenrubas

This comment was marked as spam.

jochenhz pushed a commit to Anchorpoint-Software/git-lfs that referenced this pull request May 17, 2024
Avoid deadlocking on log scanning with lots of output on stderr
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

gitscanner_log Freezes When 'git log' Outputs to STDERR
3 participants