After creating a contact in the contacts app, if the user attempts to attach media to an SMS created through contacts, the are not able to send it. I believe the aggressive task manager clears SMS and Media related app from memory due to how many apps are need to send an MMS through contacts. 3 apps are needed (Contacts, SMS, Media picker), but only Contacts remains in memory after selecting an image. Repro Steps: 1. Update Buri device to 1.2 or 1.3 buildID: 20131119040204 2. Create a contact. 3. Tap contact > SMS. 4. Tap attachment > Gallery > Any picture > Save crop. Actual Results: User is returned to the contacts app after attempting to save crop from gallery. Unable to send MMS. SMS and Gallery are removed from memory (evidenced by the task/card manager). Expected Results: To be able to send MMS from the contacts app. Repro Rate: 5/5 100% Gaia 4ecbc106a3fcf72cbd6dd8a43c46de7bacbedf20 SourceStamp ba9ecdea3a90 BuildID 20131119040204 Version 28.0a1 Attached: Logcat

Can someone find out if this reproduces on 1.2 & 1.1? I'm pretty sure this is a regression, but someone should double check.

I was unable to reproduce this issue on 1.1 or 1.2, however 1.3 shows several different issues. Sometimes the user is blocked entirely from ever sending an MMS as stated in the initial description, other times the user will be able to send one MMS but then run in to the results of the initial description on every other try. Sometimes the user can select and crop an image, and they're shown in the SMS screen, but do not actually send, they just sit with the spinner to their right and don't ever appear to be delivered. Another issue I've seen is that sometimes when the user selects the attachment button from the SMS menu, instead of opening a window where they can just select a picture and are then taken to the croppping screen, the user will just be taken to the gallery app, where selecting a picture will just bring up the standard gallery editing options. Device: Buri v1.3 Mozilla RIL BuildID: 20131120062258 Gaia: 67866e82379e751646aa5f0fd6a7a4268e9529c1 Gecko: 597287004ff5 Version: 28.0a1 Base Image: V1.2_20131115 Will post a regression window when it's pinned down.

Started encountering the issues listed in Comment 2 on the November second build: Last Working Environmental Variables: Device: Buri v1.3 Mozilla RIL BuildID: 20131101040203 Gaia: ccdf357ea150fc7d8b8a4b74c7adf31e7a57e465 Gecko: abe6790a5dd8 Version: 28.0a1 Base Image: V1.2_20131115 First Broken Environmental Variables: Device: Buri v1.3 Mozilla RIL BuildID: 20131102040200 Gaia: 50f0c914fa5cb89694c0cdd41b6e10b714787070 Gecko: 396e59370945 Version: 28.0a1 Base Image: V1.2_20131115

On gecko, the only change in the mobilemessage subsystem is the follow-up in bug 933207, so I don't think this is the issue. In Gaia, all the patches in this range occured in the Messaging app. Bug 815093 notably, which seems related: we changed from a "window" activity to an "inline" activity. So I'd say this is our culprit. I'll try to reproduce today to gather a little more information before flagging the systems FE team.

traige: regression 1.3+

It works for me on a Peak on master except I see a message "Messages has crashed" which is not right because it has not crashed. Probably the gallery app crashed rather, but this seems to be another issue. Lucas, would you please test this again? If this still reproduces for you I'll investigate a bit more.

Ah it happened once when I tried to attach a second image. Maybe it depends on the size of the image. If it's a memory issue, I'm not sure this is easy to fix :(

QA Wanted for comment 6

On the latest Buri 1.3 build, I'm seeing the same sorts of issues as stated in Comment 2. On the latest 1.4, the user is able to send images, but several crash messages are encountered and the gallery does not fill the whole screen. (I'll attach a screenshot of that issue.) 1.3 Environmental Variables: Device: Buri 1.3 Mozilla RIL BuildID: 20131216004002 Gaia: 1752e9e8f2b84b9db5d96ae5940596957fc8ed6c Gecko: 2ec5a40f544e Version: 28.0a2 Base Image: V1.2_20131115 1.4 Environmental Variables : Device: Buri v1.4 Mozilla RIL BuildID: 20131216040201 Gaia: 358cd74fd2b2ef5d541f71a5d53d65d6a7335424 Gecko: f67feb33a974 Version: 29.0a1 Base Image: V1.2_20131115

J Zimbrick - I'm having trouble parsing whether the issues you are cited are directly relevant to the bug above or not. Can you clarify the testing results above against the STR + expected/actual resutls used in comment 0? For anything not related, can you file separate bugs for those issues?

I see the same crash messages, btw. The issue with the "whole screen" is bug 950827.

My apologies for the confusion. I just rechecked this on the latest Mozilla 1.3 Buri build and DID reproduce the issue stated in Comment 0 on my first attempt. After finalising the crop of the picture, I was simply returned to the contacts app and the picture was not sent. I then tried a second time, and the picture was cropped fine and added to an MMS message that I was able to send without issue. On the third attempt, rather than being taken specifically to the picker for attachments, the phone seemed to launch the standard gallery where selecting a picture would just bring up the usual gallery controls (before selecting a picture it was just the icons to go to camera and to pick multiple photos, and after selecting a picture the options to share/edit/delete/etc. were shown) rather than going straight to cropping and adding to an MMS. Every try after this produced this same result. I tried to reproduce this issue roughly ten times. So the issue IS still occurring, but only intermittently, and there are several other possible outcomes while using the same exact steps to reproduce. 1.3 Environmental Variables: BuildID: 20131217004001 Gaia: dca0a3dcf062ce3e422a9c56d141c14543c816fb Gecko: 1f7db4cc788e Version: 28.0a2 Base Image: V1.2_20131115 I'll check today's 1.2 and 1.4 to see how they behave with these steps.

I did not encounter any negative issues on the 1.2 branch, the user is able to crop and send photos as MMS without issue while following the steps from Comment 0. Attempted to reproduce about five times without any problems. 1.2 Environmental Variables (No issues occurring): BuildID: 20131217004001 Gaia: 4f53ba8b3628ac311253fc28dfdf66e7ba6832de Gecko: 129ad3c335a5 Version: 26.0 Base Image: V1.2_20131115 On 1.4, the specific issue stated in this bug does NOT seem to be occurring. However, adding an attachment is still blocked because the gallery is brought up with the screen completely gray and the user can't select any pictures or crop them. Bug 950827 is also still present, though the crash messages are not. 1.4 Environmental Variables (940729 specifically not occurring, but several other issues): BuildID: 20131217040201 Gaia: 545aacf3feff6430140cc9ade757002df4895b77 Gecko: b1e5ade62913 Version: 29.0a1 Base Image: V1.2_20131115

The bug present on the 1.4 branch mentioned in Comment 14 seems to be bug 951088. I suppose rather than declaring that bug 940729 is not happening on the 1.4 branch, I should have said it was blocked. I'll recheck this issue on the 1.4 branch when bug 951088 is resolved.

(In reply to J Zimbrick from comment #14) > Bug 950827 is also still present. Yep, the fix landed just now :)

Milan, could this be also a skia regression, since we're using the canvas a lot in this STR? Can you recall how to disable skia to check this? (we should really export this pref to the Settings Developer panel ;) )

QA Wanted for: 1. Test this with Skia GL turned off (see https://bugzilla.mozilla.org/show_bug.cgi?id=947523#c21 for how to do this) 2. On reproduction of the bug, get a dmesg log & logcat

pref("gfx.canvas.azure.accelerated", false); will turn off Skia GL. You'd then look in the logcat for something like: ... /dev/pmem: No more pmem available ... Falling back to ashmem

I checked this on the latest 1.4 build with gfx.canvas.azure.accelerated set to false. Generally when attempting to reproduce this, the app was functioning as the user would expect it to, but I was able to get a reliable repro with slightly altered steps. 1. Create a contact in the contacts app. 2. Select that contact and press the message icon. 3. Press the attachment button to select a picture. 4. Crop the picture and accept the changes to add it to the MMS. 5. Press the attachment button a second time and select and crop a picture 6. Observe that the user is returned to the Contacts screen rather than remaining on the SMS thread. It should be noted, however, that the messages app is still opened in the background if the user holds the home button, which is not quite the same as the initial writeup. The messages app is no longer being closed like it was in the initial writeup. So the issue is not quite as severe, though potentially still very frustrating for an end user. The logcat does have several instances of the "... /dev/pmem: No more pmem available" and "... Falling back to ashmem" lines referenced in Comment 19. I will be attaching both the logcat and the dmesg log shortly. Hopefully these files are of some use, if not, I'll be happy to provide whatever else might be needed. Environmental Variables: Device: Buri v1.4 Mozilla RIL BuildID: 20131218040201 Gaia: e2f0e09e980b1cb3275a0bb033931cb48f9d521c Gecko: 862cb6a1cc88 Version: 29.0a1 Base Image: V1.2_20131115

So, just to be clear, we can reproduce the problem with Skia GL disabled as well.

Yes but it seems that you need 2 images instead of one ;)

So, just to be clear, skia GL seems to make the issue a lot easier to reproduce. All this is related to the discussion David Flanagan started about how we do resizes. I don't think we can do better with the current APIs, but I'm more than welcome to have hints to optimize this. I'm gonna flag Gabriele to see if he can helps with the memory patterns we use in this STR.

Sorry for not acting on this sooner. I'm trying to reproduce it today, I'll report back as soon as I have a bunch of memory dumps to understand exactly what's going on. I will be using the STR from comment 20 which seem the most recent.

I've experimented with this issue today on my hamachi and I can confirm that this is a good, old plain OOM condition. What makes it troublesome is that the scenario we're creating here is not something we had in mind when assigning the OOM kill priorities so let me elaborate on that. When attaching the image that causes the OOM condition we're in the following situation: - the gallery app is open and consuming more memory than usual due to the user editing the image, it's in the foreground - the SMS app is open and in the foreground probably because it's an inline activity - the communications app is open and also in the foreground, I'm not sure why this is the case but it's likely to have something to do with how activities work The values used by the OOM killer in this situation favor killing the SMS app over the communications one because they're both considered to be in the foreground and the SMS app is using more memory. When we're finished editing the image the gallery app memory usage spikes thus causing the SMS app to die. I'm not 100% sure what would be the best approach to fix this but I have the feeling that we need to fix bug 892371 in order to get some saner behavior. Just to be clear here, the desired behavior is that when we run out of memory we want the *gallery* app to be killed sending the user back in the SMS app, correct?

There was some work in the Gallery app to make it use less memory. Therefore I'm asking QA Wanted with a build from today, to check the STR from comment 0 and from comment 20 in versions 1.3 and 1.4. Thanks!

This issue reproduces for me on the 01/10/14 1.3 and 1.4 builds following the STR from comment 20; issue does not reproduce using the STR from comment 0. - 1.3 Build - Device: Buri v1.3 MOZ RIL BuildID: 20140110004009 Gaia: c606b129a2d1647c0fc7bfb197555026e9b27f9e Gecko: c5109884ae3a Version: 28.0a2 Firmware Version: V1.2_US_20131115 - 1.4 Build - Device: Buri Master (1.4) MOZ RIL BuildID: 20140110040206 Gaia: f400efc804366c7b7cf5476d1d5d325e6651ee71 Gecko: 37516445a0b5 Version: 29.0a1 Firmware Version: V1.2_US_20131115

Ok, so the SkiaGL regression were fixed. The issue from comment 20 seems to be more a Window Management issue. Then I'd like to close this bug as the STR in comment 20 is not the same initial bug. Alive, can you look at the STR in comment 20? Do you already have a bug covering this?

The STR in comment 20 is definitely fixable with a fix to bug 892371 that would set the priorities of the various apps correctly. Though depending on the expected behavior I'm not sure what would be best to do: do we expect the Contacts app to be killed and the SMS app to be saved so that we can complete the second attachment operation or do we prefer the Gallery app to be killed and the user sent back to the SMS app w/o being able to attach the second image?

Gabriele, as far as I know, the STR in comment 20 does not kill any app. Or is it killing the Gallery app?

(In reply to Julien Wajsberg [:julienw] from comment #33) > Gabriele, as far as I know, the STR in comment 20 does not kill any app. Or > is it killing the Gallery app? On my handset the STR from comment 20 reliably kills the SMS app which is way you are sent back to the Contacts app. The description there mentions that the SMS app is still visible in the switcher which may or may not mean that the app is still alive. The card could just be a leftover or caused by a WM bug.

Weird, then it's not a Window Management issue at all, and maybe not a dupe?

(In reply to Julien Wajsberg [:julienw] from comment #35) > Weird, then it's not a Window Management issue at all, and maybe not a dupe? With the behavior I've seen then this is definitely caused by bug 892371. In a nutshell when running out of memory because we're attaching too many images the OOM killer has to pick an application to kill. The computation that decides which application to kill multiplies the amount of memory of every application by a score we set in the process manager. This normally works well as background applications have an higher score and will get killed sooner than foreground applications. In this case however due to the activites both SMS and Contacts are considered to be in the foreground and Gallery as well. Since SMS is the app consuming more memory, when Gallery tries to allocate more memory SMS gets killed. Alive's description on how to fix this (bug 892371 comment 3) basically entails communication to the process priority manager which processes opened an activity and adjusting their priorities so that the most recent activity opener gets a high priority than others. In this way the Contacts app would be killed instead of the SMS app. Note: OOM killer scores and priorities are linked which is why I use both terms: the higher the priority an app as the less likely it is to be killed by the OOM killer.

ok thanks. I keep the dupe as is because this is what fixed comment 0, and we have bug 892371 for comment 20.

This is not a dupe - that bug is talking about long term solution to this problem, but isn't focusing on what regressed here. This is a confirmed regression with a range shown, which means the fix here should focus on resolving the regression.

qawanted for comment 20, then. Can we try the STR from comment 20 in 1.1, 1.2, 1.3, 1.4? Thanks !

(In reply to Julien Wajsberg [:julienw] from comment #39) > qawanted for comment 20, then. > > Can we try the STR from comment 20 in 1.1, 1.2, 1.3, 1.4? > > Thanks ! This was already tested & confirmed above as a regression, so clearing keyword.

Jason, the STR from comment 20 was not tested & confirmed as a regression, afaik. Either we mark this bug a dupe for comment 0 and we file a new one for the STR in comment 20, either we investigate the STR in comment 20. Qawanted, please see comment 39.

(In reply to Julien Wajsberg [:julienw] from comment #41) > Jason, the STR from comment 20 was not tested & confirmed as a regression, > afaik. > > Either we mark this bug a dupe for comment 0 and we file a new one for the > STR in comment 20, either we investigate the STR in comment 20. > > Qawanted, please see comment 39. That's not what this bug is talking about. Please re-read comment 0 which is focus of what this regression focuses on. There's been way too many qawanted requests asked for here, which leads to believe that the investigation here is running around in circles with a lack of focus of what the real problem here is. Please stay focused on what regressed on November 1st & get that fixed.

This also is definitely not a dupe, as the other bug points to the long term solution to this problem, but not what regressed here to cause this bug.

(In reply to Jason Smith [:jsmith] from comment #42) > Please re-read comment 0 which is > focus of what this regression focuses on. The problem here is that the STR in comment 0 cannot be reproduced anymore which suggests we close this bug as WORKSFORME instead. However, this is with the sample images I tried it with. Since the underlying problem is related to how the OOM killer acts in this situation it might be possible that picking a large enough image should be able to trigger the STR from comment 0 again. So IMHO the way forward here is the following: let's find the largest image it makes sense to attach (for example a picture taken with the camera) and see if comment 0 is reproducible or not with that. If it's not then let's close this as WORKSFORME. If it reproduces on the other hand then I have a hard time figuring out a Gaia solution for the problem without a proper fix for bug 892371. In that case I fear that we won't be able to fix this in time for 1.3. Julien mind if I steal this from you? I can test the scenario quickly on both master and 1.3 and verify if comment 0 reproduces or not and if it's caused by the OOM killer behavior I've seen.

Jason, Gabriele, please read again comment 20: without SkiaGL, the bug is not happening, or at least is happening differently. Then please read comment 29: the STR from comment 0 does not reproduce in current build. To me, that means that the fix to bug 939962 fixed this as well. So now, what do you want us to do? We can't fix something that works, right? If you want us to investigate what's happening in comment 20, then I need more qawanted, or another bug to do this. If you want us to fix what's in comment 0, then well, I've nothing for you since it's already fixed. Gabriele, there are other memory-related opened bugs, for example bug 956226. I've requested there some help from Jerry Shih who also investigate the canvas memory issues in the Gallery app. I don't think we need to be too many people to work on the same issues now, but if you have good ideas on how to make this better then please propose :)

(In reply to Julien Wajsberg [:julienw] from comment #45) > Jason, Gabriele, > > please read again comment 20: without SkiaGL, the bug is not happening, or > at least is happening differently. comment 20 is a different problem - not directly related to this bug. > Then please read comment 29: the STR from comment 0 does not reproduce in > current build. To me, that means that the fix to bug 939962 fixed this as > well. That would imply that this bug should be closed then if the original STR no longer reproduces. > > So now, what do you want us to do? We can't fix something that works, right? > > If you want us to investigate what's happening in comment 20, then I need > more qawanted, or another bug to do this. If you want us to fix what's in > comment 0, then well, I've nothing for you since it's already fixed. The bug here should stay focused on what was originally filed, not the other issues mentioned. Those should be tracked in separate bugs.

Duping against the bug that fixed this. bug 956226 holds nearly the same steps as comment 20. Bug 959422 does too. But none of them are exactly like comment 20. Jason, do you think we should file a separate bug?

(In reply to Julien Wajsberg [:julienw] from comment #47) > Duping against the bug that fixed this. > > bug 956226 holds nearly the same steps as comment 20. Bug 959422 does too. > But none of them are exactly like comment 20. Jason, do you think we should > file a separate bug? > > *** This bug has been marked as a duplicate of bug 939962 *** Probably only if that issue reproduces on the latest 1.4 build. jzimbrick - Can you check if the bug cited in comment 20 still reproduces?

The issue from Comment 20 does reproduce on the latest 1.4 mozilla buri build, though the SMS app is now being killed as noted in Comment 34. Comment 36 lists this behaviour being easily fixed by bug 892371, so that would lead me to believe that there does not need to be a new bug logged for this issue. If that is not the case, I'd be happy to write one up. 1.4 Environmental Variables : Device: Buri v1.4 Mozilla RIL BuildID: 20140115041401 Gaia: 255a56ac67e5b28f1fc78307969cc83391c9652f Gecko: 81bced59e8b3 Version: 29.0a1 Base Image: V1.2-device.cfg

I'll add the STR to bug 959422 and it should be enough. Thanks.