压缩7z时算法选Fast lzma2, level选5时, 在压缩过程中出现c0000005崩溃

[yyjdelete]

测试版本: NanaZip 3.0 Preview 0 (3.0.756.0) x64

好像随便找个3个G的东西压, 就会在进度条大概在2G左右的时候崩溃 更新: 好像挑文件, 我找了几个iso镜像试了下都不会重现, 我看能不能找到一个方便公开上传的文件找了个样本上传了

nanozip选其他算法和级别时貌似没有出现相同现象 但测试使用相同算法和参数的7z-std 22.01也不会崩

测试样本: 百度网盘(解压外层7z后, 直接压缩那个tar文件就可以了, 不需要二次解压tar) 链接：https://pan.baidu.com/s/1sEvqJpYFa_611NCWyMfsaQ?pwd=jdvd 提取码：jdvd

或者直接clone这个版本库, 然后压缩目录

git clone https://github.com/ridon/ridon-kernel-cross82_3821
NanaZipC a test.7z ridon-kernel-cross82_3821  -t7z -m0=FLZMA2 -mx5  -mmt=8

完整参数参考(测试机是4核超线程的CPU, 并行度8, 其他的都是lv5的默认参数没动):

问题签名:
P1: 40174MouriNaruto.NanaZipPreview_3.0.756.0_x64__gnj4mf6z9tkrc
P2: praid:NanaZip
P3: 3.0.756.0
P4: 6512d77d
P5: NanaZip.Core.dll
P6: 3.0.756.0
P7: 6512d76f
P8: c0000005
P9: 00000000000203dd
P10: 

问题签名:
P1: 40174MouriNaruto.NanaZipPreview_3.0.756.0_x64__gnj4mf6z9tkrc
P2: praid:NanaZipC
P3: 3.0.756.0
P4: 6512d7c3
P5: NanaZip.Core.dll
P6: 3.0.756.0
P7: 6512d76f
P8: c0000005
P9: 00000000000203dd
P10: 

[dinhngtu]

I managed to reproduce. Seems to be this bug:

https://github.com/conor42/fast-lzma2/issues/9

[MouriNaruto]

I will try to fix it manually due to fast-lzma2 not being updated since 4 years ago.

Kenji Mouri

[peashooter2]

NanaZip直接破坏了7-Zip的对于不存在文件的处理逻辑，导致了INVALID_POINTER_READ异常

[dinhngtu]

~~I tried to reproduce this recently but couldn't do it any more with the github repo you linked. Do you have a single-file reproducer, @yyjdelete?~~ nvm, compressing the whole repo as tar helped.

Reproducer (extract before use). Crash will happen within the first 32MB:

xxab.zip