[Crash-utility] [PATCH] Fix junk values when run crash on a .gz file

[Dave Anderson]

----- Original Message -----
> 
> 
> If I look at my sample's gzip header, it looks like:
> 
> $ od -c vmlinux-2.6.36-0.16.rc3.git0.fc15.x86_64.gz | head
> 0000000 037 213  \b  \b   6 254 264   L  \0 003   v   m   l   i   n   u
> 0000020   x   -   2   .   6   .   3   6   -   0   .   1   6   .   r   c
> 0000040   3   .   g   i   t   0   .   f   c   1   5   .   x   8   6   _
> 0000060   6   4  \0 354 375  \v   | 024 325 375 300 177   O   n   $   @
> 0000100   p 303 325 250 250   A 202   b 305   J 274 264   D   @ 263 232
> 0000120 350 254 335   (   ^   P 274   U   , 202   V 333 376 254 356 002
> 0000140   Z 251   Y 227   ( 343 262 224 326   K 351 035   + 266 264 372
> 0000160 253   x  \a   T   H 270   d 301   k   D   E 224   V   n  \n 023
> 0000200 203 212 250 341   * 373 377   ~ 317 354   - 200 332 377 345   y
> 0000220 376 257 327 363   | 336   /   % 273   s   f 346 234 231   9   s
> $
> 
> where you can see the NULL-terminated filename string starting at
> byte offset 10.  What does yours look like?

I guess the name string can be stripped:

>From this google reference: http://www.dotnetperls.com/gzip-header

 Specification

 After researching this problem, I found the GZIP File Format Specification, 
 which outlines the contents of every valid GZIP file's headers. From the
 specification, each file begins with specific bytes.  

 Link

 Byte order specification

 +---+---+---+---+---+---+---+---+---+---+
 |ID1|ID2|CM |FLG|     MTIME     |XFL|OS | (more-->)
 +---+---+---+---+---+---+---+---+---+---+

 Text description of bits

 FLG (FLaGs)
 This flag byte is divided into individual bits as follows:
    bit 0   FTEXT
    bit 1   FHCRC
    bit 2   FEXTRA
    bit 3   FNAME
    bit 4   FCOMMENT
    bit 5   reserved
    bit 6   reserved
    bit 7   reserved

 The FLG byte above, the fourth byte, contains 8 bits that can be set to 1 or 0 
 depending on what optional header information is in the file header. If a bit is
 set to 1, you can find the data for that bit starting at the 11th bit in the GZIP file.

 Bit descriptions. The flag byte, shown above, contains the FNAME bit at the fourth
 position, bit 3. Therefore, if the FNAME bit is set to 1, we can remove filename data
 starting at bit 11 through null.

So I guess the proper thing to do would be to check for the FNAME bit 
in the FLG byte, and if it's not set, I guess we could either accept
the file without prejudice, or print a message indicating that the
name has been stripped and that -f should be used.

Dave