[haiku-bugs] Re: [Haiku] #7740: High resolution JPEG images crash ShowImage due to failure to clone area from app_server

#7740: High resolution JPEG images crash ShowImage due to failure to clone area
from app_server
----------------------------------+-----------------------
   Reporter:  leavengood          |      Owner:  axeld
       Type:  bug                 |     Status:  new
   Priority:  normal              |  Milestone:  R1
  Component:  Servers/app_server  |    Version:  R1/alpha3
 Resolution:                      |   Keywords:
 Blocked By:                      |   Blocking:
Has a Patch:  0                   |   Platform:  All
----------------------------------+-----------------------
Description changed by leavengood:

Old description:

> 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
> r42239 (and before, I've seen this for a while on big images.)
>
> 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.)

New description:

 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
 r42239 (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.)

--

-- 
Ticket URL: <http://dev.haiku-os.org/ticket/7740#comment:1>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.

Other related posts: