commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Bodewig (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (COMPRESS-256) 7z: 16 MB dictionary is too big
Date Tue, 21 Jan 2014 14:07:20 GMT

    [ https://issues.apache.org/jira/browse/COMPRESS-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13877483#comment-13877483
] 

Stefan Bodewig edited comment on COMPRESS-256 at 1/21/14 2:06 PM:
------------------------------------------------------------------

note this is while reading the header rather than the content of the entry.  The content may
use LZMA2 but the header seems to use LZMA.

XZ for Java says:

{quote}
     * LZMA allows dictionaries up to one byte less than 4 GiB. This
     * implementation supports only 16 bytes less than 2 GiB. This
     * limitation is due to Java using signed 32-bit integers for array
     * indexing. The limitation shouldn't matter much in practice since so
     * huge dictionaries are not normally used.
{quote}

uhm, apparently they are used.  But then again I'm surprised 7z would use a dictionary larger
than 2GiB for headers.  This makes me believe there is some bug in our parsing code for compressed
headers.  Again, any chance you could provide an example archive?


was (Author: bodewig):
note this is while reading the header rather than the content of the entry.  The content may
use LZMA2 but the header seems to use LZMA.

XZ for Java says:

{cite}
     * LZMA allows dictionaries up to one byte less than 4 GiB. This
     * implementation supports only 16 bytes less than 2 GiB. This
     * limitation is due to Java using signed 32-bit integers for array
     * indexing. The limitation shouldn't matter much in practice since so
     * huge dictionaries are not normally used.
{cite}

uhm, apparently they are used.  But then again I'm surprised 7z would use a dictionary larger
than 2GiB for headers.  This makes me believe there is some bug in our parsing code for compressed
headers.  Again, any chance you could provide an example archive?

> 7z: 16 MB dictionary is too big
> -------------------------------
>
>                 Key: COMPRESS-256
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-256
>             Project: Commons Compress
>          Issue Type: Bug
>          Components: Archivers
>    Affects Versions: 1.6, 1.7
>            Reporter: Stefan Mueller
>            Priority: Minor
>              Labels: 7zip
>
> I created an archiv with 7zip 9.20 containing the compress-1.7-src directory. Also tried
it with 1.6 version and directory. I 
> downloaded the zip file and reziped it as 7z. The standard setting where used:
> Compression level: normal
> Compression method: lzma2
> Dictionary size: 16 MB
> Word size: 32
> Solid Block size: 2 GB
> I get an exception if I try to open the file with the simple line of code:
> SevenZFile input = new SevenZFile(new File(arcName));
> Maybe it is a bug in the tukaani library, but I do not know how to report it to them.
> The exception thrown:
> org.tukaani.xz.UnsupportedOptionsException: LZMA dictionary is too big for this implementation
> 	at org.tukaani.xz.LZMAInputStream.initialize(Unknown Source)
> 	at org.tukaani.xz.LZMAInputStream.<init>(Unknown Source)
> 	at org.apache.commons.compress.archivers.sevenz.Coders$LZMADecoder.decode(Coders.java:117)
> 	at org.apache.commons.compress.archivers.sevenz.Coders.addDecoder(Coders.java:48)
> 	at org.apache.commons.compress.archivers.sevenz.SevenZFile.readEncodedHeader(SevenZFile.java:278)
> 	at org.apache.commons.compress.archivers.sevenz.SevenZFile.readHeaders(SevenZFile.java:190)
> 	at org.apache.commons.compress.archivers.sevenz.SevenZFile.<init>(SevenZFile.java:94)
> 	at org.apache.commons.compress.archivers.sevenz.SevenZFile.<init>(SevenZFile.java:116)
> 	at compress.SevenZipError.main(SevenZipError.java:28)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message