Poor handling of very large JPEG images in Backgrounds preferences.

[jstressman]

This extends further than just Backgrounds, but I'll constrain this ticket to just Backgrounds handling.

This also seems like it could be 3 different bugs... I'm not sure if they each need their own ticket?

When attempting to load a very large image, in this case the full size JPEG image from the link at the bottom of this page: ​http://photojournal.jpl.nasa.gov/catalog/PIA15689 (not the link at the top, which is considerably smaller, even though it says full size at the top as well)

The image is 23096 x 7981 pixels, 13.15MB

When you select it in the Open dialog, another bug is triggered in which the delay in loading the preview apparently causes the dialog to think that the mouse is being held down the entire time, and so the context menu pops up when you don't want it to when the preview finally shows. This bug shows up on a number of my wallpapers, anything over around 4 or 5MB for me. Which is about 9 of the wallpapers in my wallpapers folder. Since this appears to be related to the time it takes to load the preview, this might be much more noticeable on slower systems.

Further, the preview itself is corrupted, showing a repeat of the left side of the image where the right side should be. This same bug shows up in ShowImage as well.

Next, if you actually select the image and choose to make it your desktop, it doesn't actually show up in the preview on the main Backgrounds dialog once selected. And when you apply it, it doesn't show up on your desktop either. No errors or warnings are given that I can see, it simply doesn't do anything.

[jstressman]

showing the context menu caused by a slow preview load, and the corrupted preview image.

[jstressman]

showing a larger version of the corrupted preview, this time from ShowImage.

[jstressman]

main Backgrounds dialog showing no preview of the selected image, and no load on the CPU to indicate it's working on showing it either.

[anevilyak]

This and the other two jpeg-related issues sound like they're possibly issues in our version of libjpeg itself. Would need investigating though.

[anevilyak]

Another possibility that comes to mind is memory allocation issues ; when decompressed, an image this size would need ~700MB of memory, and BBitmap would need to allocate that in a single linear chunk. This might be problematic, especially in Web+ where WebCore may well be doing double/triple buffering of some form.

[jstressman]

There's an old closed ticket #7740 that I thought might be related to this, and seems to point to the same memory issue.

I have 12GB of mem in this system, so I would think it should either load it anyway, or at least handle it a bit more gracefully. I'll add this to the WebPositive ticket I filed as well that's related to this.

[anevilyak]

Replying to jstressman:

I have 12GB of mem in this system, so I would think it should either load it anyway, or at least handle it a bit more gracefully. I'll add this to the WebPositive ticket I filed as well that's related to this.

That's not really relevant here though. To clarify: Haiku (currently) is a 32-bit OS. As a consequence, the address space that's visible to any given app is confined to 4GB (the kernel itself can handle > 4 thanks to PAE, but that cannot be exposed to apps directly). That address space however, is split up for various technical reasons (and fundamental requirements/limitations of the underlying hardware). Of that 4GB virtual address space, 2GB is available to user-space, while the other 2GB goes to the kernel. Therefore, any given app can use at *most* 2GB in theory.

In practice the usable number winds up being quite a bit less since those same 2GB also have to contain all the libraries, add-ons and main program code, as well as whatever other data structures the app needs, + the data structures of the memory allocator and other system services. This results in a good chunk of that address space already being used up before the app's started doing any real work, and due to the way things have to be laid out, there also winds up being some fragmentation of the address space. As a consequence, there might e.g. be > 700MB of address space available overall, but it might not be in a single continuous chunk. Something like a uncompressed bitmap however, must be allocated as such because e.g. graphics hardware requires it. Consequently, the allocation may well fail, especially in a double/triple buffering scenario where several such bitmaps might get allocated. If that's indeed the problem, it's not one that can be solved by simply throwing more memory at it, and in fact would only really be fixed by switching over to 64-bit, which significantly enlarges the physical/virtual address space.

[jstressman]

Ah, good point. I'd completely forgotten about that.

So the bug we're seeing in the preview could be an example of it running out of space and just repeating what part of it it did manage to fit in memory or something? And like you said, something likely with libjpeg itself, as the exact same thing shows up in ShowImage.

[anevilyak]

Replying to jstressman:

So the bug we're seeing in the preview could be an example of it running out of space and just repeating what part of it it did manage to fit in memory or something? And like you said, something likely with libjpeg itself, as the exact same thing shows up in ShowImage.

Right now it's merely conjecture as a possibility because of the sheer size of the image involved. 700MB shouldn't be big enough to be triggering any integer overflow errors or anything in that vein so memory consumption just seems like the most probable culprit. One commonality between ShowImage and Backgrounds is that they both go through the JPEG translator, which could well be masking/mishandling an error return from libjpeg resulting in the behavior above. WebCore on the other hand uses libjpeg directly so the issue there might be a bit different but still related. Would need some more investigation to be certain.

[jstressman]

Split the odd mouse click behavior off into #8788

The rest of this is probably specific to JPEG loading, while the mouse click is probably related to click handling.

[korli]

Replying to anevilyak:

translator, which could well be masking/mishandling an error return from libjpeg resulting in the behavior above. WebCore on the other hand uses libjpeg directly so the issue there might be a bit different but still related. Would need some more investigation to be certain.

Could also happen on the appserver which handles the bitmap in both case.

[korli]

Replying to jstressman:

Split the odd mouse click behavior off into #8788

The rest of this is probably specific to JPEG loading, while the mouse click is probably related to click handling.

Have you tried with a very large TIFF image?

[jstressman]

Tried it with the TIFF version of the image ( 270.76MB )... first I tried loading it in ShowImage and it said there wasn't an available translator or something for it... so I loaded the smaller TIFF of the same image ( 5788x2000, 33.13MB ) and that loaded fine.

Then I tried loading the full size TIFF again and it loaded as a 1x1 pixel image in ShowImage...

So then I tried loading it as a background... at that point everything went terribly wrong. A debugger flashed up on the screen and took down part of the system... so you could still navigate workspaces by clicking on the WorkSpaces app, but keyboard navigation didn't work... Deskbar and Tracker didn't work... you could still move and focus windows etc... but when you tried to type, only some letters showed up in a box on the left side of the screen... I ended up having to hard reset the machine. :/

[jstressman]

after I tried loading the full size TIFF.... this led to me having to hard reset the machine.

[diver]

Sounds like app_server semi-crashed. Might be related to hrev44081.

vm_soft_fault: va 0xc0000 not covered by area in address space 
vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0xc0007, ip 0x2671d2, write 1, user 1, thread 0xd4d9 
vm_page_fault: thread "a:54487:x-vnd.Haiku-ShowImage" (54489) in team "app_server" (111) tried to write address 0xc0007, ip 0x2671d2 ("app_server_seg0ro" +0x671d2) 
debug_server: Thread 54489 entered the debugger: Segment violation 
stack trace, current PC 0x2671d2  Free__21ClientMemoryAllocatorP5block + 0x212: 
  (0x70fbcd9c)  0x2675c5  _._12ClientMemory + 0x35 
  (0x70fbcdcc)  0x28e386  _._12ServerBitmap + 0x86 
  (0x70fbcdfc)  0x5e895e  LastReferenceReleased__14BReferenceable + 0x2e 
  (0x70fbce2c)  0x5e891b  ReleaseReference__14BReferenceable + 0x3f 
  (0x70fbce5c)  0x28c215  _DeleteBitmap__9ServerAppP12ServerBitmap + 0x55 
  (0x70fbce8c)  0x283e1b  _._9ServerApp + 0x1b7 
  (0x70fbcecc)  0x28ba9d  _MessageLooper__9ServerApp + 0x1c5 
  (0x70fbcf7c)  0x27ebfc  _message_thread__13MessageLooperPv + 0x28 
  (0x70fbcfac)  0x8c86e3  thread_entry + 0x23 

[axeld]

I have a faint memory that views could only get 16384 pixels in size in BeOS -- maybe that's something Haiku inherited, I don't remember. This could more or less match the point where the image is painted the second time.

[jstressman]

You appear to be correct. I just checked, and that is in fact the exact point at which the image wraps. 16384 pixels from the left.

[Janus]

Part 1 is reported in #8788 (Mouse click). Part 2 is reported in #8779 (Corrupted image). Part 3 is a system limit as explained in comment:4. There are no problems with the x86_64 version.

[Janus]

Part 3 if you set the background image and reboot you have a good chance that the image is in the background.