0.83: Error detecting split 7z files, and potential crash

[JMM72]

Hello. Using: XnViewMP Version 0.83 x64 (Oct 3 2016) Libformat version 6.92

Although this looks as one bug, it's actually two, the crash shouldn't happen but an error should be shown, besides the bad detection.

It took me a bit to get why and how XMP kept crashing in a certain folder, it all started when I opened a file and suddenly the Windows alert of 'XnViewMP stopped working' popped out. After much testing and misunderstanding, I finally found the culprit. XMP detects wrongly the first file of a split 7z compressed file (.7z.001, .7z.002, .7z.003, etc.) and tries to load it as an image. This only happens with the first file, the one with 001 extension, and detects it as 'Hayes JTFax', always as black & white, compression CCITT Group 3 and width 2544 pixels; the height depends on the size of the actual file. The crash happens if the file is too large. The one causing my crashes was 2 GiB large, so I guess something went wrong when trying to get the memory or calculate the height, shouldn't have crashed but launched an error.

I'm using 7Zip 15.12 64bit (http://www.7-zip.org/) for making the files, although the specific structure of the 7z files hasn't changed in many versions. Normal, non-split 7z files work ok, only split 7z files give the problem, and only the first file. What I found curious is that if you create a split file and the size of splitting is larger than the actual size of the file, the only file created is also wrongly detected as Hayes JTFax. There's a simple explanation for this, but it's part of 7Zip's technical approach of making split files, and is of no use for the current bug report.

So, to reproduce the format detection bug, create a split 7z file using any split size, and open the folder. You'll see the first file treated as an image.

And to reproduce the crash bug, make a large split 7z file using a large split size, mine was 2 GiB but much smaller files also make XMP crash, such as 37M.

[xnview]

is it possible to have the .001 file?

[JMM72]

As I said, any first volume of a split 7z file will trigger this bug, but here you go.
For some reason I can't add the file to this post, download from: http://www.eligeotravez.net/x.7z.001


You can download 7Zip and create a larger split 7z file to trigger the crash.

[xnview]

As I said, any first volume of a split 7z file will trigger this bug, but here you go.
For some reason I can't add the file to this post, download from: http://www.eligeotravez.net/x.7z.001
You can download 7Zip and create a larger split 7z file to trigger the crash.

I can't reproduce the crash, do you have sent a crash log with the crash box?

[Themis]

I packed the XnViewMP folder without compression and with splitting to 32M.
https://yadi.sk/d/vMZB9yCH36iyQU
Stack:
ntdll.dll!0000000077a2f262
ntdll.dll!0000000077a2f846
ntdll.dll!0000000077a30412
ntdll.dll!0000000077a32084
ntdll.dll!00000000779ca180
kernel32.dll!0000000077871a0a
msvcr120.dll!000007fef44e69d8
xnviewmp.exe!000000013ffbd73e
xnviewmp.exe!000000013ffbd8c3
xnviewmp.exe!000000013ff81bf8
xnviewmp.exe!000000013ff81a5b
xnviewmp.exe!000000013ff864ca
xnviewmp.exe!000000013ff86421
xnviewmp.exe!000000013fdcde3b
xnviewmp.exe!000000013feb3dc6
xnviewmp.exe!000000013feb5c95
xnviewmp.exe!000000013feb724f
Qt5CoreXn.dll!00000000668df11a

xnviewmp.exe 000000013FB00000-00000001405A6000 FileSize : 10884680 bytes

[xnview]

Stack:
ntdll.dll!0000000077a2f262

Is it possible to send the mini dump file by the crash dialog uploader?

[Themis]

I have only Windows's dialog.
I dont want to send any dump.

[helmut]

Thank you, JMM72 and Themis for your help in finding out about the problem. I've tried to reproduce your problem but XnView MP didn't crash for me (Windows 32bit, 3.25 GB RAM).

As a summary from the above posts:

• The problematic files are huge .001 files which XnView considers to be images in Hayes JTFax format with CCITT Group 3 compression. I assume that copying and renaming any huge file to .001 can be used for trying to reproduce the problem.
• In Tools > Setting > General the setting "Show all graphic formats" must be activated

What I tried:

• I've downloaded your sample .001 files -> No crash, thumbnails are displayed and files can be opened as images. (Sure enough only nonsense is displayed).
• I've copied and renamed 10 VMWare files with file sizes ranging from 100MiB to 4.3GiB to .001
  --> XnView didn't crash but there were some anomalies:
  - Some few .001 files have no thumbnails
  - Some .001 files have thumbnails but their format and size isn't displayed when setting "View as" in XnView browser to "Thumbnail + Detail". When double-clicking on those files, nothing happens. When using "Open" on those files they do open.

[JMM72]

I assume that copying and renaming any huge file to .001 can be used for trying to reproduce the problem.

No, any file with .001 extension is detected as Hayes JTFax format with CCITT Group 3 compression, but only 7zip files cause the crashes here (64 bit XMP). The file must have .001 extension, that's why I detected the crash with the first volume of zplit 7z files. E.g., I rename a 2.3mb PNG with extension .001 and XMP doesn't crash. I compress that file with 7z, rename with extension .001 and it crashes.

I am guessing that JTFax files don't have any header for detection, thus detection only relies on extension. However something inside a 7zip file causes the JTFax decoder to crash, and I see it's something to do with size because small 7z files don't crash.

The files don't need to be huge. Doing some compressions and tests, a file as low as 1679kb causes the crash here. The largest I've tried which doesn't cause the crash is 1482kb. Thus the size which causes the crash is higher than 1482kb but lower than 1679kb. The 1482kb file is detected as an image of 2544 width and 4170 height.

I'm not sure if it's really worth to continue pursuing this bug since it happens under such specific conditions, however one never knows how far a small bug can affect other code. If you are sure the bug is contained within the JTFax decoder and don't want to waste more time, maybe it's better to leave it alone.

[helmut]

I've just tried on Windows 10 with XnView 0.84 beta 3 64bit and could easily reproduce the crash. Whenever browsing the folder with the .001 files XnView crashes immediately.

Attached please find a manually edited ".001" file [~770KiB] that crashes XnView (the .001 file is packed in a ZIP archive because forum doesn't allow upload of .001 files).

xnv-crash-sample.zip

Notes:
- Make sure that setting "Show all graphic files" is activated (see my previous post)
- XnView MP 0.83 x32 displays this file as .001 thumbnail and doesn't crash

Hopefully Pierre can also reproduce the problem, track it down and finally fix it.

[xnview]

See Issue 1045 for details.

[helmut]

See Issue 1045 for details.

XnView MP 0.84 beta 4 will contain the fix?! Good!

[JMM72]

Those are great news. Not that it was a really fatal bug which hinders XMP usage, but certainly he's fixing things as they appear. I hope the 'filename too long' bug I reported is also fixed, althought the thread hasn't had any answer yet.

[helmut]

Those are great news. Not that it was a really fatal bug which hinders XMP usage, but certainly he's fixing things as they appear.

I had tested the 0.84 betas and these didn't crash anymore when browsing .001 files.

I hope the 'filename too long' bug I reported is also fixed, althought the thread hasn't had any answer yet.

I much doubt that that one has been fixed, already.