#90 segfault handling very large multivolume .7z file

closed-fixed
nobody
None
5
2009-06-07
2009-05-28
No

I compiled p7zip 4.65 on CentOS 5.3 (x86_64) and used the resulting 7zr executable to compress a ~100 GB tar file using the following:

cat verrucano-6verrucano-20090520.tar | ~/path/to/7zr a -bd -si -mx=9 -v100000000b verrucano-6verrucano-20090520.tar.7z

This resulted in 683 .tar.7z.??? files:

> [rwg@cabernet verrucano]$ ~/root/p7zip-4.65/bin/7zr l -slt verrucano-6verrucano-20090520.tar.7z.001
>
> 7-Zip (A) 4.65 Copyright (c) 1999-2009 Igor Pavlov 2009-02-03
> p7zip Version 4.65 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,2 CPUs)
>
> Listing archive: verrucano-6verrucano-20090520.tar.7z.001
>
> Method = LZMA
> Solid = -
> Blocks = 1
> Physical Size = 68215887947
> Headers Size = 101
> ----------
>
> Path = verrucano-6verrucano-20090520.tar
> Size = 106976194560
> Packed Size = 68215887846
> Modified = 2009-05-21 16:24:22
> Attributes = .....
> CRC = B8E9A914
> Encrypted = -
> Method = LZMA:26
> Block = 0

As a check, I used 7zr to extract the tar file from the .7z file, then compared the MD5 hash of the original tar file with the extracted tar file. The hashes matched. So far so good.

I then copied the .tar.7z.??? files to my Macintosh (PowerMac G5 running OS X 10.5.7) and verified the MD5 hashes of the original files matched the copies. I compiled p7zip 4.65 on the Mac and tried to extract the tar file -- 7zr (and 7z) segfaulted. They would also segfault if I tried to "l" (list) or "t" (test) the archive.

I recompiled p7zip with no optimizations (-O0) and debug information enabled (-g), obtained a core dump ("7z t xxx.tar.7z.001"), and ran it through gdb:

> (gdb) bt
> #0 0x00007f0c in CBaseRecordVector::Size (this=0x68) at MyVector.h:25
> #1 0x00030244 in COpenCallbackImp::FindName (this=0x0, name=@0x862638) at ../../UI/Common/ArchiveOpenCallback.cpp:64
> #2 0x000318c8 in CInFileStreamVol::~CInFileStreamVol (this=0x862200) at ../../UI/Common/ArchiveOpenCallback.cpp:77
> #3 0x00025d34 in CInFileStream::Release (this=0x862200) at FileStreams.h:48
> #4 0x000310fc in CMyComPtr<IInStream>::~CMyComPtr (this=0xbffee95c) at MyCom.h:25
> #5 0x00030460 in COpenCallbackImp::GetStream (this=0x103300, name=0x111750, inStream=0xbffeeadc) at ../../UI/Common/ArchiveOpenCallback.cpp:108
> #6 0x003c88f0 in NArchive::NSplit::CHandler::Open (this=0x102ad0, stream=0x802600, openArchiveCallback=0x103300) at ../../Archive/Split/SplitHandler.cpp:209
> #7 0x0003c520 in OpenArchive (codecs=0x100760, arcTypeIndex=23, inStream=0x802600, fileName=@0xbfffee5c, archiveResult=0xbffff1e0, formatIndex=@0xbffff008, defaultItemName=@0xbffff1e8, openArchiveCallback=0x103300) at ../../UI/Common/OpenArchive.cpp:280
> #8 0x0003c9f4 in OpenArchive (codecs=0x100760, arcTypeIndex=23, filePath=@0x100590, archiveResult=0xbffff1e0, formatIndex=@0xbffff008, defaultItemName=@0xbffff1e8, openArchiveCallback=0x103300) at ../../UI/Common/OpenArchive.cpp:319
> #9 0x0003cc34 in OpenArchive (codecs=0x100760, formatIndices=@0xbffff178, fileName=@0x100590, archive0=0xbffff1e0, archive1=0xbffff1e4, formatIndex0=@0xbffff008, formatIndex1=@0xbffff00c, defaultItemName0=@0xbffff1e8, defaultItemName1=@0xbffff1f4, openArchiveCallback=0x103300) at ../../UI/Common/OpenArchive.cpp:356
> #10 0x0003d5a4 in MyOpenArchive (codecs=0x100760, formatIndices=@0xbffff178, archiveName=@0x100590, archive0=0xbffff1e0, archive1=0xbffff1e4, defaultItemName0=@0xbffff1e8, defaultItemName1=@0xbffff1f4, volumePaths=@0xbffff208, volumesSize=@0xbffff220, openCallbackUI=0xbffff464) at ../../UI/Common/OpenArchive.cpp:471
> #11 0x0003d84c in MyOpenArchive (codecs=0x100760, formatIndices=@0xbffff178, archiveName=@0x100590, archiveLink=@0xbffff1e0, openCallbackUI=0xbffff464) at ../../UI/Common/OpenArchive.cpp:530
> #12 0x000352cc in DecompressArchives (codecs=0x100760, formatIndices=@0xbffff430, archivePaths=@0xbffff610, archivePathsFull=@0xbffff624, wildcardCensor=@0x10066c, optionsSpec=@0xbffff4f8, openCallback=0xbffff464, extractCallback=0x102c60, errorMessage=@0xbffff480, stat=@0xbffff4d0) at ../../UI/Common/Extract.cpp:162
> #13 0x0000a890 in Main2 (numArguments=3, arguments=0xbffff8a8) at ../../UI/Console/Main.cpp:454
> #14 0x0000f7a8 in main (numArguments=3, arguments=0xbffff8a8) at ../../UI/Console/MainAr.cpp:84

More relevant gdb info:

> (gdb) up
> #2 0x000318c8 in CInFileStreamVol::~CInFileStreamVol (this=0x862200) at ../../UI/Common/ArchiveOpenCallback.cpp:77
> 77 int index = OpenCallbackImp->FindName(Name);
> (gdb) whatis OpenCallbackImp
> type = COpenCallbackImp *
> (gdb) x OpenCallbackImp
> 0x0: 0x00000000

As a test, I compiled p7zip 4.65 on a Debian 5.0r1 (x86_64) machine and tried using 7z on the same .7z.tar.??? files -- it segfaults in the exact same way.

Discussion

  • my space

    my space - 2009-06-02

    I confirm the problem.

    The next version of p7zip will not crash but will not be able to handle these kind
    of multi-volume.

    p7zip (indeed 7-zip) needs to open all the files that are part of the archive.
    If the user does not have the right to open such many files then p7zip can't handle that error.

    try
    ulimit -a (line "open files")
    to know the user's rights.

     
  • Richard Godbee

    Richard Godbee - 2009-06-06

    I increased the limit on the number of open fds for my account (from 256 to 1024), and 7z/7zr no longer segfaults. I'm kicking myself for not thinking of this before filing this bug report!

    Thank you for your reply.

     
  • my space

    my space - 2009-06-07

    Since version 9.04, p7zip do not crash but is not able to handle these kind of multi-volume.

    p7zip (indeed 7-zip) needs to open all the files that are part of the archive.
    If the user does not have the right to open such many files then p7zip
    can't handle that error.

    try
    ulimit -a (line "open files")
    to know the user's rights.

     
  • my space

    my space - 2009-06-07
    • status: open --> closed-fixed
     

Log in to post a comment.