Description: After sending an MMS picture message with a cropped image, the sender is unable to open sent picture by tapping it in message thread. Until Messages app is closed and reopened, attempting to open a sent MMS picture will show a black screen before crashing back to message thread. Repro Steps: 1) Updated Buri Build ID: 20131204115608 2) Open Messages app 3) Tap compose icon to begin new message 4) Enter recipient information 5) Select paperclip icon to attach media 6) Press gallery 7) Tap existing image 8) Drag crop selection so that only rightmost portion of image is selected and press "Done" 9) Send message 10) Tap on thumbnail of picture just sent Actual: Cropped images sent by MMS cannot be opened by sender. Expected: Tapping on sent MMS image opens full image. Environmental Variables Device: Buri v 1.3 Mozilla RIL Build ID: 20131204115608 Gecko: http://hg.mozilla.org/mozilla-central/rev/526e12792fc8 Gaia: 324c467fc6b202fd09efe4b16cd83960fd2901eb Platform Version: 28.0a1 Firmware Version: V1.2_US_20131115 Notes: Repro frequency: 3/3, 100% See attached: video clip - http://youtu.be/hWsMjzO9Pus
Does this reproduce on 1.1 or 1.2?
FYI I don't reproduce on a Peak on current master/gaia
(In reply to Jason Smith [:jsmith] from comment #1) > Does this reproduce on 1.1 or 1.2? This does not reproduce on the v1.1 build for the Leo or Buri devices. This does reproduces on the Buri v1.2 build. Environmental Variables: Device: Buri v1.2 Com Ril BuildID: 20131205004003 Gaia: 0659f16b9790b1cf9eba4d80743fcc774d2ffe3a Gecko: af2c7ebb5967 Version: 26.0 RIL Version: 01.01.00.019.281 Firmware Version: V1.2_US_20131115
(In reply to rkunkel from comment #3) > (In reply to Jason Smith [:jsmith] from comment #1) > > Does this reproduce on 1.1 or 1.2? > > This does not reproduce on the v1.1 build for the Leo or Buri devices. > > This does reproduces on the Buri v1.2 build. > > Environmental Variables: > Device: Buri v1.2 Com Ril > BuildID: 20131205004003 > Gaia: 0659f16b9790b1cf9eba4d80743fcc774d2ffe3a > Gecko: af2c7ebb5967 > Version: 26.0 > RIL Version: 01.01.00.019.281 > Firmware Version: V1.2_US_20131115 Sorry, forgot to include the environmental variables for the 1.1 build. Buri v1.1 - Environmental Variables: Device: (example: Buri v1.2 Mozilla RIL) BuildID: 20131205041342 Gaia: 6ff3a607f873320d00cb036fa76117f6fadd010f Gecko: 05117f42088f Version: 18.0 Firmware Version: V1.2_US_20131115
This looks bad - looks like viewing a cropped image from a SMS thread isn't working in context. Two things: 1. Can you get a logcat? 2. Can you get a dmesg log?
Can I have a video as well, because I couldn't reproduce with the included STR ? Thanks!
Created attachment 8343852 [details] logs archive (In reply to Jason Smith [:jsmith] from comment #5) > 1. Can you get a logcat? > 2. Can you get a dmesg log? Attaching logcat and dmesg logs. Here is the kill message from the dmesg log: <4>[ 882.131919] select 461 (Usage), adj 10, size 5964, to kill <4>[ 882.131936] select 493 (Communications), adj 10, size 7322, to kill <4>[ 882.131951] send sigkill to 493 (Communications), adj 10, size 7322 <4>[ 883.610413] select 461 (Usage), adj 10, size 5623, to kill <4>[ 883.610439] select 516 (Settings), adj 10, size 6788, to kill <4>[ 883.610456] send sigkill to 516 (Settings), adj 10, size 6788
Comment on attachment 8343852 [details] logs archive Going to attach the log files directly instead of archive...
I'd still want a video of it's possible :) Thanks!
(In reply to Julien Wajsberg [:julienw] from comment #11) > I'd still want a video of it's possible :) Thanks! There's already a video included in comment 0. See http://youtu.be/hWsMjzO9Pus.
Created attachment 8343876 [details] Bug 946519 Video (In reply to Julien Wajsberg [:julienw] from comment #6) > Can I have a video as well, because I couldn't reproduce with the included > STR ? Attached video.
(In reply to Jason Smith [:jsmith] from comment #10) The fist occurrence of this issue appears to be in the 12/5 build. This issue is not present in the 12/6 build, however it will repro in all builds after that. - Last Working - Environmental Variables: Device: Buri v1.2 COM RIL BuildID: 20131204004003 Gaia: 8d762f3376318fd6be390432db750ae4904c9ab6 Gecko: 758f3fb32dda Version: 26.0 RIL Version: 01.02.00.019.102 Firmware Version: - First Broken - Environmental Variables: Device: Buri v1.2 Com Ril BuildID: 20131205004003 Gaia: 0659f16b9790b1cf9eba4d80743fcc774d2ffe3a Gecko: af2c7ebb5967 Version: 26.0 RIL Version: 01.01.00.019.281 Firmware Version: V1.2_US_20131115
Kyle, could this be the same root cause than bug 944276?
Doesn't seem like it. This looks like an OOM. Bug 944276 is an IPDL actor lifetime problem.
QA, Can we please confirm the patch that caused this regression? Need a back out here.
Blocking+ for critical regression - will look into comment 17 as well. I'm moving this to needsinfo rather than qawanted.
There are three commits in the Gaia regression range: 1. https://github.com/mozilla-b2g/gaia/commit/8d762f3376318fd6be390432db750ae4904c9ab6 2. https://github.com/mozilla-b2g/gaia/commit/1e33fd87d61de023b18961270e2f2abe2ead07c1 3. https://github.com/mozilla-b2g/gaia/commit/0659f16b9790b1cf9eba4d80743fcc774d2ffe3a  is unrelated, as it's involving the Music app.  seems unrelated & unlikely as well.  is possible, as it touches on previewing images. David - Could bug 935373 cause this regression?
(In reply to Jason Smith [:jsmith] from comment #19) > There are three commits in the Gaia regression range: > > 1. > https://github.com/mozilla-b2g/gaia/commit/ > 8d762f3376318fd6be390432db750ae4904c9ab6 > 2. > https://github.com/mozilla-b2g/gaia/commit/ > 1e33fd87d61de023b18961270e2f2abe2ead07c1 > 3. > https://github.com/mozilla-b2g/gaia/commit/ > 0659f16b9790b1cf9eba4d80743fcc774d2ffe3a > >  is unrelated, as it's involving the Music app.  seems unrelated & > unlikely as well.  is possible, as it touches on previewing images. > > David - Could bug 935373 cause this regression? Bug # should be - bug 935273.
This definitely has to be caused by bug 935273. Nothing else seems plausible in the regression range.
Talked with djf in IRC about this. jsmith djf: Context - bug 946519. The regression range seems to be pointing at your Gaia commit. Any ideas why? djf jsmith: looking djf jsmith: that is very weird. I can't think of any reason why that patch would have caused it. Are you sure this is a regression? jsmith djf: Looks like it. The regression range indicates this broke on 12/4/2013 on the 1.2 branch. jsmith by something that landed* djf jsmith: you can't back out that patch permanently because it fixed a blocker. But if backing it out fixes this bug, then please assign the bug to me (and send me an email?) jsmith djf: Right. Any chance you could look into bug anyways to see why this is happening? djf jsmith: the reason I'd like someone to confirm it was my patch is that that patch only affects the image pick part, and the failure is happening when viewing the image. So I kind of think it is more likely that this is graphics layer weirdness. djf jsmith: also, my Buri is pretty borked. I htink it needs a firmware update. I can't even see images when I attach them to a MMS message. djf So I'm unlikely to be able to reliably reproduce the bug since I don't have working hardware. djf jsmith: and as far as I know, getting new firmware for my Buri requires a window machine. djf|afk jsmith: I'm going to be afk for a couple of hours. Let's continue the discussion by email.
Note - I didn't really see any gfx related issues in the regression range.
Okay, looking at this at least. I misread the report and thought it was the receiver of the message that could not see the image, and that seemed completely unrelated to cropping on the sender. I still don't understand how the changes to cropping could have caused this issue, however. With a 1.2 build I can actually see images when I attach them to messages, so my Buri is not as broken as I feared. However, it appears that I cannot send MMS messages. Plain text works, but maybe my SIM card does not allow MMS messages for some reason? Anyway, it sits there forever trying to deliver the MMS with the photo. While it does that, viewing the photo works perfectly for me. So I'm not sure I'm going to be able to reproduce this.
One thing I notice from the attached video is that the image being sent is a screenshot that is then cropped. So it is quite small, and the MMS app does not need to resize it. I wonder if there is a difference between big images that get resized and small images that are used as-is.
Ah ha! I can reproduce this with a cropped screenshot as shown in the video, even though it never actually gets sent. The other difference, of course, is that with screenshots it is a png image not a jpeg.
Okay, so a big jpeg, cropped or uncropped, but big enough to require a resized, works. A small png, not reiszed does not work Is it the file size or the file type that causes the bug? Let's try the other cases: A png image that is large enough to require resize (whether cropped or not) does not exhibit this bug. A small png image that does not require resize does exhibit this bug if it is cropped, but does not if it is uncropped. A small jpeg uncropped and and not resized does not exhibit the bug. The same small jpeg cropped and not resized does exhibit the bug. If I kill the sms app and restart, then viewing all of the images works. So the bug does not seem related to png images. I do see two relevant pieces of information here: * the bug only occurs if the gallery app crops (resizes) the image and the MMS app does not resize it. * restarting the MMS app (and retreiving the images from persistant storage) makes the bug go away. To me, these point to an in-memory blob issue. Here's my thinking: 1) If the user does not crop the image, then the gallery app sends a file-backed blob to the MMS app. If the user does crop the image, then the gallery app sends a memory-backed blob to the MMS app. (I don't know whether the memory is shared by the gallery and MMS apps or whether a copy is made when the blob is transferred). 2) If the MMS app has to resize the image, it is somehow making its own independent copy of the image. I don't know if that copy is file backed or memory backed, but it the MMS app owns it. If it does not have to resize, it is presumably using the blob it receives unmodified. 3) The MMS app also saves images somehow, and when restarted, reads them from persistant storage, getting a private copy. It would be interesting to know (and I can't test since my sim card won't let me send MMS messages) if these small cropped images can actually be sent and received by other phones. They are obviously saved successfully, so it is not like the blob is completely corrupt. Maybe the issue only occurs when the blob from gallery is passed to MMS and then passed back to a new invocation of the gallery app to view it. I've seen blob-and-activity issues like this two or three times before. The workaround for the MMS app would be to always make a private copy of the image. Maybe by storing it to the DB and them immediately reading it back? The long-term solution, however, is always to get Ben Turner involved.
Ben: I think blobs might be involved here. Would you look at comment 28 and see what you think? Jason: almost certainly not a gallery bug, so I'm setting the component back to SMS since that is where the symptom is exhibited. (And if my reasoning in comment #28 is correct, where the workaround will have to be made.)
I actually think this is a dupe of bug 944276 and have not seen evidence of OOM. And fortunately, bent is already thinking about 944276
(In reply to David Flanagan [:djf] from comment #30) > I actually think this is a dupe of bug 944276 and have not seen evidence of > OOM. And fortunately, bent is already thinking about 944276 Yup, looks like it. That should have been koi+, not fugu+.