-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
v1.9.1 causes panic in writer #1383
Comments
Luap99
added a commit
to Luap99/logrus
that referenced
this issue
May 17, 2023
Commit 766cfec introduced this bug by defining an incorrect split function. First it breaks the old behavior because it never splits at newlines now. Second, it causes a panic because it never tells te scanner to stop. See the bufio.ScanLines function, something like: ``` if atEOF && len(data) == 0 { return 0, nil, nil } ``` is need to do that. This commit fixes it by restoring the old behavior and calling bufio.ScanLines but also keep the 64KB check in place to avoid buffering for to long. Two tests are added to ensure it is working as expected. Fixes sirupsen#1383 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Luap99
added a commit
to Luap99/logrus
that referenced
this issue
May 17, 2023
Commit 766cfec introduced this bug by defining an incorrect split function. First it breaks the old behavior because it never splits at newlines now. Second, it causes a panic because it never tells the scanner to stop. See the bufio.ScanLines function, something like: ``` if atEOF && len(data) == 0 { return 0, nil, nil } ``` is needed to do that. This commit fixes it by restoring the old behavior and calling bufio.ScanLines but also keep the 64KB check in place to avoid buffering for to long. Two tests are added to ensure it is working as expected. Fixes sirupsen#1383 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Closed
This was referenced May 17, 2023
1 task
1 task
ashmckenzie
pushed a commit
to ashmckenzie/logrus-Luap99-fork
that referenced
this issue
Jun 2, 2023
Commit 766cfec introduced this bug by defining an incorrect split function. First it breaks the old behavior because it never splits at newlines now. Second, it causes a panic because it never tells the scanner to stop. See the bufio.ScanLines function, something like: ``` if atEOF && len(data) == 0 { return 0, nil, nil } ``` is needed to do that. This commit fixes it by restoring the old behavior and calling bufio.ScanLines but also keep the 64KB check in place to avoid buffering for to long. Two tests are added to ensure it is working as expected. Fixes sirupsen#1383 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Found while updating to the lasted version:
This seems to be caused by #1376 which does not look correct. the split function never tells the scanner to stop. Second it even changes the behaviour because it now no longer splits at newlines.
It easy to reproduce, just apply this test to the repo here:
The text was updated successfully, but these errors were encountered: