Opened 8 years ago

Closed 6 years ago

#8780 closed bug (fixed)

Very large JPEG crashes WebPositive

Reported by: jstressman Owned by: leavengood
Priority: normal Milestone: R1
Component: Applications/WebPositive Version: R1/Development
Keywords: Cc: rossi@…
Blocked By: Blocking:
Platform: All


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: (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

WebPositive crashes every time.

Attachments (3)

webpositive-big-jpeg-crash.txt (5.2 KB ) - added by jstressman 8 years ago.
backtrace of the crash.
syslog (235.4 KB ) - added by jstressman 8 years ago.
syslog from after the crash (shows me crashing it a couple times) (28.7 KB ) - added by pulkomandy 6 years ago.
Still crashing as of hrev46516. Complete backtrace saved with Debugger.

Download all attachments as: .zip

Change History (8)

by jstressman, 8 years ago

backtrace of the crash.

by jstressman, 8 years ago

Attachment: syslog added

syslog from after the crash (shows me crashing it a couple times)

comment:1 by jstressman, 8 years ago

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.

by pulkomandy, 6 years ago

Still crashing as of hrev46516. Complete backtrace saved with Debugger.

comment:2 by pulkomandy, 6 years ago

So, what happens is app_server does not want to allocate a bitmap that big. I added a check for this in Web+ and I can avoid the crash, rendering a white page instead.

The image needs about 700MB of memory when decoded. ShowImage manages to get this going, but it seems WebKit is keeping two copies of the image, which gets dangerously close to the limit of 2GB of user space memory. This may be because of the incremental decoding feature, where intermediate versions of the image are rendered while it's still loading.

Finally, when you navigate away from the page, it seems the memory is not freed immediately. This will prevent allocating even very small bitmaps in other parts of the code, with a similar crash (I got an allocation failure on an 1x20 pixels bitmap this way...)

I could try to reduce the memory use for this case, but it would be possible to get the same problem by loading a bigger image anyway.

comment:3 by jstressman, 6 years ago

Wasn't there a discussion somewhere about this that included talk of breaking up the image in order to handle it better?

Like either only loading into memory the part that would actually be displayed (if full size), or only a scaled version if viewed scaled or something.

"Tiling" or something. (Sorry for my non-technical explanation.)

Is this, or would this be, included on the OS side rather than on an application specific basis?

comment:4 by rossi, 6 years ago

Cc: rossi@… added

comment:5 by pulkomandy, 6 years ago

Resolution: fixed
Status: newclosed

jstressman: while the image can be tiled once decoded, it's not really possible to decode only a part of a JPEG file. So this would need saving the decoded bitmap to disk as it is decoded, and then reading tiles from that decoded "cache".

While we could implement this OS-wide in the translator API, it wouldn't solve the problem for Web+, which uses libjpeg directly.

Closing this issue since we don't crash anymore. I don't think there is a reasonable way to handle this, and ShowImage can be used without problems.

Note: See TracTickets for help on using tickets.