You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Stefan Bodewig (JIRA)" <ji...@apache.org> on 2014/01/21 15:07:20 UTC

[jira] [Comment Edited] (COMPRESS-256) 7z: 16 MB dictionary is too big

    [ 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)