Bug 78413

Summary: (alpha) deflate.c mis-compiled with -O2
Product: [Retired] Red Hat Raw Hide Reporter: Jeff Johnson <jbj>
Component: gcc3Assignee: Richard Henderson <rth>
Status: CLOSED NOTABUG QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.0   
Target Milestone: ---   
Target Release: ---   
Hardware: alpha   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-01-31 05:21:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
file to reproduce problem none

Description Jeff Johnson 2002-11-22 16:13:33 UTC 
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 16:15:17 UTC 
Created attachment 86066 [details]
file to reproduce problem
Comment 2 Jeff Johnson 2002-11-22 16:16:45 UTC 
Workaround (compile deflate.c with -O0) in gzip-1.3.3-7
Comment 3 Jeff Johnson 2002-12-02 15:01:06 UTC 
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 05:21:40 UTC 
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.