Freeze when using AVX2 with HighQualityResampling enabled, with huge images > ~100MP

[f242]

1. open image 10000x14000 pix jpeg
2. doubleclick for 100% scale
3. hold left mouse button and scroll image
4. after 2-3 seconds app will not respond

latest version without this bug is 1.0.34

[sylikc]

interesting... so if I go back to an older version the freeze doesn't exist? might be the underlying TurboJPEG library...

does it work with any arbitrary 10k x 14x image? Can you attach a sample?

[f242]

interesting... so if I go back to an older version the freeze doesn't exist?

yes, 1.0.34 x64 works fine, 1.0.35 and newer have this bug

does it work with any arbitrary 10k x 14x image?

all images with this resolution will hang application

Can you attach a sample?

in attachment sample image and my config .ini
pack.zip

my monitor has 4K resolution, in case this is important

[sylikc]

@f242 I tested your image file and INI file combination and I didn't exhibit any freezing. What CPU/RAM combo are you running?

[f242]

@sylikc AMD Ryzen 3700x & CRUCIAL Ballistix Sport LT BLS16G4D30AESC DDR4

[sylikc]

I meant how much ram do you have? Hehe

[f242]

@sylikc 32Gb

[OCD-Man]

It seems that I have most likely figured out why you are having an issue starting with JPEGView version 1.0.35. Please make sure to reply to tell use if this solves your issue.

I downloaded your 2 files, and WITHOUT using your global settings ini file, I had no problem opening your file and doubleclicking for 100% scale and holding the left mouse button to scroll through the picture for as long as I wanted. It worked fast and smoothly the whole time. And I am using a descently old laptop with Intel i3 380M CPU, 4GB of RAM, and around a 20 inch widescreen monitor set to the highest resolution of 1440x900, using a crappy on board video card.

Then when I replaced my global ini file in my exe path with YOUR ini file and disabled my user ini file, JPEGView just crashed when trying to open any photo at all. I tried a few more times and it crashed every time.

So I went to diffchecker.com and compared YOUR ini file with the default global ini file from the 64 bit folder of version 1.0.37.1 and noticed that you changed 10 settings. I noticed you changed the processor setting to AVX2 and the CPU cores setting after that to 4. I only have 2 cores, but setting it to 2 cores didn't help. However my CPU is older and doesn't support AVX2, so after changing AVX2 back to the default setting of AutoDetect, I was finally able to load the picture.

I then used YOUR ini file (changing the CPU setting back to autodetect, and the cores setting back to 0) and I loaded your picture and once again it worked well and I could NOT replicate your issue.

I then downloaded version 1.0.34 and 1.0.35 of JPEGView and I used diffchecker.com to compare the default global ini files from the exe paths from the 64 bit folders. I noticed some changes to the ini file. The only change that corresponded to a setting that you also changed the value of is for the description part of the "CPUType=" setting.

First line of description for "CPUType=" from version 1.0.34:
CPUType can be AutoDetect, Generic, MMX or SSE

First line of description for "CPUType=" from version 1.0.35 (same as version 1.0.37.1):
; CPUType can be AutoDetect, Generic, MMX, SSE or AVX2

Your setting for "CPUType=":
CPUType=AVX2

So as you can see, JPEGView began support for AVX2 in version 1.0.35, and even if you tried using YOUR ini file with version 1.0.34 (which I tried), JPEGView version 1.0.34 will just ignore that setting since it is not a valid option in that version of JPEGView, and I suppose it then automatically chooses to use the following default setting:
CPUType=AutoDetect

So in version 1.0.34, the AutoDetect setting most likely selected SSE as the best compatible option for your CPU.

But maybe first try setting it to CPUType=AutoDetect

But that will probably choose to use AVX2, and you will have the same issue. If that is the case, then try setting it to CPUType=SSE

SSE would be perfectly fine for JPEGView, and hopefully that should solve the problem. I doubt you will have to try setting it to MMX, or even worse, to Generic.

If not using AVX2 solved your problem, then for all we know it could be an issue with your processor or video card. And if that is the case, then you could try updating your drivers for your processor and motherboard chipset, and especially your video card drivers since video card GPU's will also use AVX2 technology more heavily.

If that doesn't allow you to be able to use the AVX2 setting without an issue, then maybe as an experiment, try opening your computer to get some extra cooling, and if needed even blow a fan inside the computer to cool it down just to see if the problem is the CPU or the video card GPU overheating. If your issue dissappears, then overheating is the problem, and in that case check if the fan on your video card is working, or if there is a large build up of dust somewhere blocking air flow to the CPU or your video card.

I should mention that AVX2 can heat up the processor so much that when it is used, the processor underclocks about 20% to compensate for the power it uses and the heat produced. AMD apparently still won't support AVX-512 since they feel AVX2 is already too much. I don't know if a bug in the programming for AVX2 support in JPEGView could possibly make a CPU or GPU overheat.

I enjoyed reading the following article:
https://www.techspot.com/article/2166-mmx-sse-avx-explained/

If other CPUs or video cards that support AVX2 don't have this issue, and this cannot be replicated on another computer, then it may be impossible to find anything wrong with the JPEGView code, if there is a problem at all.

If AVX2 ends up NOT being the problem, then maybe sylikc could check the changelog for JPEGView version 1.0.35 to see what changes were made and figure out what the problem is from that.

Please make sure to respond and let us know what happened so this issue can either be closed or you can continue to be helped. Plus sylikc will need to know if this is the issue to be able to attempt to fix a bug related to AVX2 so you can use that setting.

[stobor827]

I have been struggling with a similar hang when zooming into much smaller images (~1900x1200)
Zooming in to 500% or more and panning around would cause a hang fairly reliably.
OCD-Man's suggestion of explicitly falling back to SSE fixed this for me. I had to create the settings file for this, so the rest of the settings are defaulted.

System hw:
Dual Xeon Silver's 4110 2.1 Ghz
32GB RAM
GPU: NVIDIA Quadro P620

[OCD-Man]

@stobor827, thanks for letting everyone know that this is a working solution for what looks like the same issue, and for posting your sytem hardware. I'm guessing that your OS may be useful as well.

Now that I know this issue can be fixed that way, I wonder if the setting for CPUType can be set back to AVX2 if instead the setting for HighQualityResampling is set to false. Maybe that could help narrow down what it is about the programming of the AVX2 CPUType that is causing the issue. Maybe it is the HighQualityResampling interaction with the AVX2 CPUType that is making the AVX2 registers heat up the processor too much (which can be checked with a CPU temperature monitoring program), or maybe it is a memory issue from a bug, I wouldn't know what else to think since I am not a programmer.

@sylikc, hopefully you can find a computer that supports AVX2 which also has this issue, that you also can have regular access to in order to troubleshoot and fix the problem.

And if it will take a long time to fix, then maybe it would be best to set the default CPUType to SSE until this issue is fixed, unless you feel it is advantageous to have others post their related issues here, or unless AVX2 provides advantages over SSE that are useful for JPEGView.

[stobor827]

I'm using win10 21H1 (19043.1165)
Re-enabling AVX2 and disabling HighQualityResampling also prevented the hang.
Either of these workarounds are acceptable for my use, thanks for the suggestions!

In the hung state, TaskManager reported the app as Not Responding, but using 0% CPU and a stable ~50MB of RAM.
I grabbed a DMP file but wasn't able to learn anything from debugging it or upload it to this comment.
In case it's useful to someone, here is a screenshot of the thread status...

[sylikc]

@OCD-Man thanks for the deep dive investigation. My current desktop supports AVX2. I'll have to test in these combinations sometime to see if anything jumps out at me.

[sylikc]

is this still an issue @f242

[stobor827]

Yes, I reproduced today on the same system as above with 1.0.39.
HighQualityResampling=true
CPUType=AutoDetect

Setting CPU to SSE or disabling HQResampling still prevents the hang.

[OCD-Man]

I was just reading through the comments again and I noticed that stobor827 said that task manager showed that JPEGView was frozen at a steady 50MB of ram usage when JPEGView stopped responding.

So maybe this issue only happens the moment JPEGView attempts to use more than 50MB of RAM, and maybe AVX2/HighQualityResampling may or may not have anything to do with the issue other than the combination of those 2 things causing JPEGView to attempt to use more than 50MB of RAM when zooming into a high resolution image and dragging the screen to a different part of the image (Another user in issue #97 reported this same issue and said he was using a display with 4k screen resolution).

So it would be interesting if anyone else with this same issue can check how much RAM task manager reports is being used by JPEGView when this issue occurs. If it is always frozen at 50MB, then investigating the reason this happens when JPEGView attempts to use more than 50MB may help solve this issue.

[sylikc]

I was jumping in the code yesterday looking at the crash for huge images in #141, it appears that the AVX2 or the SSE code is only executed when HighQualityResampling=true. Which is likely why this crash only manifests when, BOTH these options are used.

Because either disabling AVX2 by manually by setting CpuType= something other than AutoDetect or AVX2, or disabling HQR with HighQualityResampling=false fixes this crash, there's likely a small bug deep in the AVX2 math.

I'll have to set that as backlog until someone who's well versed in the low level aspects of AVX2 can get involved. That code "looks simple" but is pretty advanced as it deals directly with assembly-level instructions: https://github.com/sylikc/jpegview/blob/master/src/JPEGView/ApplyFilterAVX.cpp

[sylikc]

@f242 @stobor827 can you test the latest development snapshot and see if the workaround that I put in fixes the freezing?

Download the latest 64-bit dev snapshot https://github.com/sylikc/jpegview/wiki/Dev-Snapshots#links and report back, thanks!

[f242]

@sylikc all fine with .ini and picture from my old comment
or i need make some additional tuning? i saw changelogs with new parameters in .ini

[sylikc]

@sylikc all fine with .ini and picture from my old comment or i need make some additional tuning? i saw changelogs with new parameters in .ini

You can revert the changes in your ini to CPUType=AutoDetect and HQR=true is ok... the workaround will fallback to SSE only when specific conditions are met which trigger the freeze.

You don't have to upgrade the INI at this time, just change the CPUType back and all. The INI workaround should no longer be needed with this fix

[f242]

@sylikc with autodetect also fine, but i tested all modes too and with mmx works very slow and hudge memory consumption, maybe it doesn't matter

[sylikc]

That's awesome. So the 4K monitor spec that you reported back then did end up mattering, although it's not really the monitor size but the window size. Now that I know exactly what the conditions were, I was able to reproduce the crash on a multimonitor system, by just stretching it across all the monitors.

Thanks for reporting back.

[sylikc]

v1.2.45 has been released that fixes this issue. You should be able to undo the changes to HiDPI settings, and CPUType/HighQualityResampling INI options. Please reopen issue if crash/freeze still happens.