--- Begin Message ---
|
Subject: |
maint: fix s390 buffer flushes |
|
Date: |
Mon, 2 Dec 2024 10:35:55 +0100 |
Problem reported by Nick Rosbrook in:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2083700
align the behavior of dfltcc_inflate to do the same as gzip_inflate
when it hits a premature EOF
---
Notes:
Hi, the ubuntu folks found a problem with gzip on the ibm s390x
architecture.
( https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2083700 )
The dfltcc_inflate function will not flush the outbuffer in case it
encounters a premature EOF.
I changed the code to break and flush the buffers just like the regular
implementation does.
I also had to change the `hufts` test. For this special test-data the
dfltcc decompression routine request more data instead of reporting a
data--format error.
dfltcc.c | 2 +-
tests/hufts | 6 ++++--
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/dfltcc.c b/dfltcc.c
index 811c1f8..2a5b350 100644
--- a/dfltcc.c
+++ b/dfltcc.c
@@ -434,7 +434,7 @@ dfltcc_inflate ()
flush_outbuf ();
if (inptr == insize)
{
- if (fill_inbuf (1) == EOF)
+ if (fill_inbuf (0) == EOF)
{
/* Premature EOF. */
return 2;
diff --git a/tests/hufts b/tests/hufts
index c464ef6..6dbb8ac 100755
--- a/tests/hufts
+++ b/tests/hufts
@@ -40,10 +40,12 @@ compare exp err || fail=1
printf '\037\213\010\000\060\060\060\060\060\060\144\000\000\000' > bug33501 \
|| framework_failure_
-printf '\ngzip: stdin: invalid compressed data--format violated\n' >exp33501 \
+printf '\ngzip: stdin: invalid compressed data--format violated\n' >
exp33501.1 \
+ || framework_failure_
+printf '\ngzip: stdin: unexpected end of file\n' > exp33501.2 \
|| framework_failure_
returns_ 1 gzip -d <bug33501 >out33501 2> err33501-raw || fail=1
sed "$clean_stderr" err33501-raw > err33501 || framework_failure_
-compare exp33501 err33501 || fail=1
+compare exp33501.1 err33501 || compare exp33501.2 err33501 || fail=1
Exit $fail
--
2.47.1
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#75924: maint: fix s390 buffer flushes |
|
Date: |
Tue, 8 Apr 2025 10:55:29 -0700 |
|
User-agent: |
Mozilla Thunderbird |
On 2025-02-20 03:33, Eduard Stefes wrote:
I think we are at a solid state here, as both implementations run with
the same test suit.
Investing more time to get a 100% error message overlap looks like a
bigger effort. We know that the hardware state machine does not simply
map the software, so I fear that it will result in very very cumbersome
error handling code.
OK, thanks for the analysis. Closing the bug report.
--- End Message ---