Opening a specific image with xviewer crashes Linux

[fire-eggs]

 * Xviewer version (xviewer --version): 2.6.2
 * Distribution - (Mint 17.2, Arch, Fedora 25, etc...): Linux Mint Cinnamon 20

Issue Opening this image consistently crashes the system [not xviewer, the system!]

Steps to reproduce

1. Download this image
2. Open the image with xviewer

Progress bar goes to 90+% then sits for a few seconds, and boom - out to Linux login.

Expected behaviour Xviewer either shows the image, or if not possible, shows an error message; neither xviewer nor linux crash.

Other information This is an 64-bit processor, with 20G of memory available.

[smurphos]

This is a general issue for xviewer and large resolution images.

The sample image suggested by @fire-eggs is 30000x17078. On attempting to open it with xviewer, xviewer will use all available system ram until the OOM kills xorg and the user is kicked back to the login screen.

On my system dmesg -l emerg,alert,crit,err outputs after logging back in

[62403.207632] Out of memory: Killed process 11346 (chrome) total-vm:4662788kB, anon-rss:7100kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:824kB oom_score_adj:300
[62403.364279] Out of memory: Killed process 273092 (chrome) total-vm:4645856kB, anon-rss:2032kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:804kB oom_score_adj:300
[62404.136524] Out of memory: Killed process 272820 (chrome) total-vm:4632968kB, anon-rss:892kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:792kB oom_score_adj:300
[62404.146900] Out of memory: Killed process 11312 (chrome) total-vm:4644216kB, anon-rss:6452kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:788kB oom_score_adj:300
[62404.321356] Out of memory: Killed process 11486 (chrome) total-vm:4618912kB, anon-rss:744kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:752kB oom_score_adj:300
[62404.928779] Out of memory: Killed process 11267 (chrome) total-vm:4619924kB, anon-rss:1368kB, file-rss:0kB, shmem-rss:16kB, UID:1000 pgtables:736kB oom_score_adj:300
[62405.088275] Out of memory: Killed process 11290 (chrome) total-vm:4592988kB, anon-rss:1168kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:696kB oom_score_adj:300
[62406.017739] Out of memory: Killed process 130837 (chrome) total-vm:4593760kB, anon-rss:440kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:664kB oom_score_adj:300
[62406.157534] Out of memory: Killed process 453382 (chrome) total-vm:4578396kB, anon-rss:96kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:596kB oom_score_adj:300
[62406.825069] Out of memory: Killed process 306539 (VirtualBoxVM) total-vm:5913760kB, anon-rss:27088kB, file-rss:2353548kB, shmem-rss:60kB, UID:1000 pgtables:5964kB oom_score_adj:0
[62408.959954] Out of memory: Killed process 9645 (Xorg) total-vm:14584488kB, anon-rss:699016kB, file-rss:0kB, shmem-rss:2351600kB, UID:0 pgtables:8008kB oom_score_adj:0

With slight smaller resolution images it doesn't necessarily crash the system but it can fail to display the image. On my hardware just over 14000 pixels in either dimension is the rough cut off point.

E.g. xviewer fails to display this image on my system - resize it to 9333x14000 and it shows OK

steve@steve-Inspiron-5580:~$ mediainfo /home/steve/Desktop/14200.jpg
General
Complete name                            : /home/steve/Desktop/14200.jpg
Format                                   : JPEG
File size                                : 10.3 MiB

Image
Format                                   : JPEG
Width                                    : 9 466 pixels
Height                                   : 14 200 pixels
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Compression mode                         : Lossy
Stream size                              : 10.3 MiB (100%)

Xviewer doesn't crash itself or anything else trying to display the pic but it's memory use is excessive

steve@steve-Inspiron-5580:~$ ps aux | grep xviewer | grep -Ev "grep"
steve     540589  2.0 19.0 9185092 1497116 ?     Sl   06:48   0:03 xviewer /home/steve/Desktop/14200.jpg

[fire-eggs]

Steve - Thank you for the confirmation and the additional details! I've learned a couple of new things!

A 9,466 x 14,200 image will likely require 512.76 megabytes [assuming it was promoted to 32 bit pixels]. When sized to 9333 x 14000 it requires 498.44 megabytes. So I bet 512 megabytes is your threshold. [9586 or 9587 x 14000]

Those numbers from your dmesg output (e.g. 4662788kB) look suspiciously like a 4G overrun - are these 32 bit processes?

[smurphos]

Hi,

It's a 64bit machine with 64bit Mint and Chrome is 64bit only so not sure???

Will do some more experiments with images of different resolutions to see if I can tie down a firm breakpoint

[fire-eggs]

Had a chance to try again with the original image, on a different machine [where I would not lose 40 open processes :-) ]

[224427.421770] Out of memory: Killed process 53689 (xviewer) total-vm:6095548kB, anon-rss:1506124kB, file-rss:0kB, shmem-rss:1321048kB, UID:1000 pgtables:7088kB oom_score_adj:0

This is a 3.7G, amd64 system. This time, xviewer eventually is killed, not xorg. It still feels like a ticking bomb to me tho.

[rnclark-psi]

I can perhaps shed some more light on this problem. First, I just built a new machine: an I9-9900K cpu with 128 GBytes ram and a new 4K monitor (3840x2160 pixels) running linux mint 20. I am a scientist doing digital imaging, ranging from spacecraft to field photography. Xviewer has been my bread and butter for many years. Some of my spacecraft data analyses create thousands of 32760 x 16380 pixel images that I need to preview quickly. Knowing this large image size bug has existed for a while, I wrote a tool to downsize the images to 16380 x 8190 pixels. If I see something interesting, I do a control 0 to zoom to 100%. (More efficient for a right handed mouse would be a control 1 which was the case in versions from years ago--why not both control 1 and control 0?). Then if I need full resolution above 16380 x 8190, I use gimp or another program that handles large images.

So 16380 x 8190 pixel images work fine both xviewer versions in mint 19.a and 20.x. But 32760 x 16380 do not, just seems to go into max cpu. In mint 20, I killed xviewer after 15 minutes on the larger image without ever seeing an image come up.

But there are some new aspects that make xviewer not usable for me. On the 4k display, images are set max vertical to what looks like 1600 pixels. If I resize the window, and press forward or backward arrow to change images, the window resizes back to ~1600 pixels vertical and the window gets recentered. Then if the next image went from portrait (e.g. 1.5x taller than width) to landscape, the window stays the width of the portrait image, so the landscape image is very small with a lot of black space above and below the image in the window. However, if one starts with a landscape image, the height is again ~1600 pixels, and the width is the width of the landscape image, e.g. 2400 pixels. Then if the next image is a portrait, the window stays 1600 vertical and the landscape width (e.g. 2400 pixels). So in a mixed portrait/landscape set of images, it seems one must start with a landscape image to have any hint of consistency, but never resize the window.

Maybe add a preference for never resize the window and make it the default?

The specs for jpeg, tiff and many other image formats go up to 32768 x 32768 (or maybe it is 32767) pixels, and it would be great if xviewer handled that, for both 8 and 16-bits/color. 16-bits/color, 3 channels would be a 6.4 GByte image.

[programmer-ceds]

... I do a control 0 to zoom to 100%. (More efficient for a right handed mouse would be a control 1 which was the case in versions from years ago--why not both control 1 and control 0?). Then if I need full resolution above 16380 x 8190, I use gimp or another program that handles large images.

If the image window has focus then pressing 1 (without a modifier) will toggle between 100% and best fit. Where possible it keeps the same area of pixels under the cursor when doing this.

But there are some new aspects that make xviewer not usable for me. On the 4k display, images are set max vertical to what looks like 1600 pixels. If I resize the window, and press forward or backward arrow to change images, the window resizes back to ~1600 pixels vertical and the window gets recentered. Then if the next image went from portrait (e.g. 1.5x taller than width) to landscape, the window stays the width of the portrait image, so the landscape image is very small with a lot of black space above and below the image in the window. However, if one starts with a landscape image, the height is again ~1600 pixels, and the width is the width of the landscape image, e.g. 2400 pixels. Then if the next image is a portrait, the window stays 1600 vertical and the landscape width (e.g. 2400 pixels). So in a mixed portrait/landscape set of images, it seems one must start with a landscape image to have any hint of consistency, but never resize the window.

Apologies this was a side effect of the mod that I made to remember the window maximized state so that it didn't have to be maximized each time the program was activated. This has been fixed in the later versions and the previous behaviour for unmaximized windows restored.

Not answers to your original problem but hopefully still of use.