Skip to content

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
@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