The file (the file is about 5M and cannot be attached directly, please see http://narod.ru/disk/4749634001/crash01022011.chm.html\) was extracted by 7z from a multivolume RAR archive, as a result a section of this file is corrupted.
When extracting the files from this CHM, when the extraction process reaches the corrupted (non-existant) files I experience random crashes in 7z with the following stack trace
NCompress::NLzx::Cx86ConvertOutStream::MakeTranslation () from
#1 0xf4889214 in NCompress::NLzx::Cx86ConvertOutStream::Flush () from
#2 0xf48896b9 in NCompress::NLzx::CDecoder::Flush () from /usr/lib/7z.so
#3 0xf488b530 in NCompress::NLzx::CDecoderFlusher::~CDecoderFlusher
() from /usr/lib/7z.so
#4 0xf488b3c9 in NCompress::NLzx::CDecoder::CodeReal () from
#5 0xf488b42f in NCompress::NLzx::CDecoder::Code () from /usr/lib/7z.so
#6 0xf48285b3 in NArchive::NChm::CHandler::Extract () from /usr/lib/7z.so
The Cx86ConvertOutStream object looks unitialized with random values instead of the member variables. valgrind also keeps complaining about the unitialized values in the object functions. Apparently the Init function wasn\'t called, while the default constructor doesn\'t initialize the values properly.
I\'d suggest to add a constructor to the Cx86ConvertOutStream class which would initialize the fields properly. But more likely the problem is the handling of the corrupted files by the LzxDecoder, which may call Flush on its m_x86ConvertOutStreamSpec object even if it was never used - in such case there would be no need to flush it.
I\'d like to emphasize that this isn\'t a problem of broken archive, this is an issue of the 7z stability and internal consistency.