Opened 10 years ago

Closed 3 years ago

Last modified 17 months ago

#7740 closed bug (fixed)

High resolution JPEG images crash ShowImage due to failure to clone area from app_server

Reported by: leavengood Owned by: axeld
Priority: normal Milestone: R1/beta2
Component: Servers/app_server Version: R1/alpha3
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description (last modified by leavengood)

I have spent hours trying to debug this but I think it is outside my skillset at this point.

Opening the attached photo (a picture of my yard if you are wondering) which is more than 8000 pixels wide will always crash ShowImage from hrev42239 (and before, I've seen this for a while on big images.)

Edit: WARNING: this image also causes very bad behavior in WebPositive, maybe due to the same bug!!! I would try downloading it with wget!

After much printf debugging I narrowed it down to BBitmap::_InitObject failing to clone an area from app_server. BBitmapStream::WriteAt just doesn't check the bitmap InitCheck like it should (that is another bug which I can fix) and then tries to access the bitmap Bits() which are null, causing a segfault. My backtrace is also attached, but the line numbers are probably wrong due to my added printfs. But this should be reproducable with the attached image.

I used the area command in KDL to look at the area_id being returned from the app_server, and it seems valid and is owned by the app_server. The result from clone_area is B_BAD_VALUE, so I assume it is failing at the lookup_area call on line 1961 of vm.cpp. Maybe for some reason the source address space returned from the MultiAddressSpaceLocker is wrong?

If I fix BBitmapStream::WriteAt to actually check the InitCheck of the bitmap it creates, the segfault is fixed, but the image still won't load of course. It seems to be a deeper problem in either the app_server or kernel.

I've also included my debug output, and the result of the KDL command area for the area from the debug output (as well as the teams output to see it is indeed owned by app_server, team_id 70 = 0x46.)

Attachments (6)

big_yard_image.jpg (4.6 MB ) - added by leavengood 10 years ago.
A high resolution image guaranteed to crash ShowImage
showimage_crash_high_res_jpg.txt (7.4 KB ) - added by leavengood 10 years ago.
printf_debug_output_showimage_crash.txt (1.6 KB ) - added by leavengood 10 years ago.
printf debug output
kdl_areas_teams_showimage_crash.txt (1.9 KB ) - added by leavengood 10 years ago.
KDL output
screenshot1.jpeg (499.2 KB ) - added by cocobean 3 years ago.
Test JPEG oddly not filling ShowImage display window
ImageOnAMac.png (703.2 KB ) - added by Janus 3 years ago.

Change History (21)

by leavengood, 10 years ago

Attachment: big_yard_image.jpg added

A high resolution image guaranteed to crash ShowImage

by leavengood, 10 years ago


by leavengood, 10 years ago

printf debug output

by leavengood, 10 years ago

KDL output

comment:1 by leavengood, 10 years ago

Description: modified (diff)

comment:2 by mmlr, 10 years ago

I've started investigating this but ran out of time. What I could gather was that the B_BAD_VALUE actually comes from browser:haiku/trunk/src/system/kernel/vm/VMUserAddressSpace.cpp#L675 which is rather curious, as it indicates the addressSpec to be B_EXACT_ADDRESS which isn't what the BBitmap function supplies. As mentioned I ran out of time then. I'll continue investigating tonight/tomorrow. I wanted to share the finding in case someone else wants to take a look sooner than that.

comment:3 by axeld, 10 years ago

Fixed the BitmapStream part in hrev42297. I'll look into the other problem as well, but I don't have much time, so feel free to continue to investigate it yourself.

comment:4 by axeld, 10 years ago

Looking at already reveals the problem: a 128 MB area is successfully reserved to contain the area. However, the area is larger than this, so the cloning (at the exact reserved address) is likely to fail.

comment:5 by axeld, 10 years ago

Status: newin-progress

comment:6 by leavengood, 10 years ago

Thanks Axel.

That indeed sounds like the problem. Wow, an image this big requires more than 128 MB! I wouldn't have thought which is why I glanced over that code.

comment:7 by leavengood, 10 years ago

Actually doing the math the image should only take around 46 MB but as you said I guess it is the area that is bigger than 128 MB.

comment:8 by axeld, 10 years ago

Resolution: fixed
Status: in-progressclosed

Fixed in hrev42298 (just came back and noticed that Trac refused to add the comment, as Ryan got in between -- really annoying feature).

Not sure what you have calculated there, but 8000*5000*4 (4 byte per pixel) is more than 128 MB :-)

comment:9 by leavengood, 10 years ago

Yeah that Trac "feature" bit me a few times on this bug too.

Oops, my silly math was for 1 byte per pixel :-D

Thanks for fixing this!

comment:10 by cocobean, 3 years ago

Tested on hrev51875 x86_64. This bug is still valid. Loading same picture in ShowImage gives "Can't load image. Either file or an image translator does not exist". Webpositive shows the image initially while loading, then shows a grey image of it after completion. Tested a few other smaller high res JPEGs which worked. Retesting the test picture, ShowImage will eventually display the test picture but as a small picture not filling the display window (see screenshot). I had to zoom in to enlarge it and displaying the picture work properly afterwards. I can also display it in WebPositive. NOTE: Getting it to work with the test images is not consistent. If you close the image in Webpositive/ShowImage, ShowImage will start displaying the same "Can't load Image..." error eventually.

NOTE: Observing resource/memory usage spikes. Possible that intensive resource apps like WebPositive or another system resource was starving other system resources (i.e. app_server, system memory, etc) in background causing this intermittent problem.

You can close this ticket at your discretion. If a user keeps other apps/system resources usage low, there are no major issues. Using high res JPEGs is not the issue.

Last edited 3 years ago by cocobean (previous) (diff)

comment:11 by cocobean, 3 years ago

Resolution: fixed
Status: closedreopened

by cocobean, 3 years ago

Attachment: screenshot1.jpeg added

Test JPEG oddly not filling ShowImage display window

in reply to:  11 comment:12 by Janus, 3 years ago

Replying to cocobean:

Test JPEG oddly not filling ShowImage display window

I think the jpeg is corrupted, I have the same problem on macOs

Last edited 3 years ago by Janus (previous) (diff)

by Janus, 3 years ago

Attachment: ImageOnAMac.png added

comment:13 by cocobean, 3 years ago

We can do View->Full screen in ShowImage. Also, I retested other JPEG images up to 50.3 Megapixels with ShowImage - no major issues on hrev51877 x86_64.

Although, what is still happening is that if we view 'medium->large' files extensively using USB devices - we can/will hit a kernel paging issue (known issue). So, don't think it is specific to ShowImage itself.

Last edited 3 years ago by cocobean (previous) (diff)

comment:14 by waddlesplash, 3 years ago

Resolution: fixed
Status: reopenedclosed

That is not an app server crash, and if it is actually an issue, deserves a separate ticket.

comment:15 by nielx, 17 months ago

Milestone: R1R1/beta2

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone

Note: See TracTickets for help on using tickets.