Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 78413 - (alpha) deflate.c mis-compiled with -O2
(alpha) deflate.c mis-compiled with -O2
Product: Red Hat Raw Hide
Classification: Retired
Component: gcc3 (Show other bugs)
alpha Linux
medium Severity medium
: ---
: ---
Assigned To: Richard Henderson
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2002-11-22 11:13 EST by Jeff Johnson
Modified: 2007-04-18 12:48 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-01-31 00:21:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
file to reproduce problem (63.95 KB, text/plain)
2002-11-22 11:15 EST, Jeff Johnson
no flags Details

  None (edit)
Description Jeff Johnson 2002-11-22 11:13:33 EST
Description of Problem:

Version-Release number of selected component (if applicable):

How Reproducible:

Steps to Reproduce:
1. gzip lutBS08.pcf segfaults
2. compile deflate.c with -O0 rather than -O2
3. gzip lutBS08.pcf compresses

Actual Results:

Expected Results:

Additional Information:
Comment 1 Jeff Johnson 2002-11-22 11:15:17 EST
Created attachment 86066 [details]
file to reproduce problem
Comment 2 Jeff Johnson 2002-11-22 11:16:45 EST
Workaround (compile deflate.c with -O0) in gzip-1.3.3-7
Comment 3 Jeff Johnson 2002-12-02 10:01:06 EST
This smells like a compiler bug, since -O0 is a fix.

Bounce back to gzip so I can get the workaround removed, please.
Comment 4 Richard Henderson 2003-01-31 00:21:40 EST
Using no optimization does *not* fix the problem for me.
I see the same crash with all files compiled -O0.  Sticking
the debugger on this shows that the program is walking off
the end of the data segment.

I rebuilt gzip with gcc 2.96, which does not exhibit the
crash and debugged things there, trying to see what happens
differently.  Turns out: nothing at all.  The code really 
does walk off the end of the "window" array.

With the 2.96 compiler, the data segment is aligned differently,
and the end of the last page ends 0x1990 bytes past the end of
the window array.  With the 3.2 compiler, the last page ends 
0xd0 bytes past the end of the array.

Note You need to log in before you can comment on or make changes to this bug.