1008071 - [Tarako][Messages]Sometimes attach Gallery image will cause Messages app be killed (not LMK)

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::SMS, defect)

Description

[Mike Lien[:mlien]]

Attachment: logcat.txt

[Device]
  Tarako
---------------------------------------------
[Reproduction build] - 0429pac + PVT v1.3T
  Gaia      554fd996205fef74d88e988f3596c58dcd05df28
  Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/ae5430bd4bbd
  BuildID   20140508164003
  Version   28.1
---------------------------------------------
[Reproduce Steps]
  1. Launch Camera app
  2. Take a picture
  3. Back to homescreen
  4. Launch Message app -> Compose a message
  5. Attach step 2's image from Gallery
  6. Repeat step 5 2~4 times
---------------------------------------------
[Expected Result]
  Can attach normally
---------------------------------------------
[Actual Result]
  Sometimes messages app be killed but not due to LMK
  I/Gecko   (   85): Security problem: Content process does not have `device-storage:pictures-read'.  It will be killed.
---------------------------------------------
[Reproduce Rate]
  70%

Comment 1

[Julien Wajsberg [:julienw]]

David, any idea about this?

Comment 2

[David Flanagan [:djf]]

If I follow the STR, I can reproduce a SMS crash, but it is clearly an OOM. I don't see anything related to security.

My hypothesis is that this happens when a new pick activity is launched while images are still being resized. Mike: can you reproduce this if you wait for the "resizing attached image" banner to go away before clicking the paperclip again?

Julien: I suggest you disable the attach button while resizing is going on.

Comment 3

[Mike Lien[:mlien]]

(In reply to David Flanagan [:djf] from comment #2)
> If I follow the STR, I can reproduce a SMS crash, but it is clearly an OOM.
> I don't see anything related to security.
> 
> My hypothesis is that this happens when a new pick activity is launched
> while images are still being resized. Mike: can you reproduce this if you
> wait for the "resizing attached image" banner to go away before clicking the
> paperclip again?
> 
> Julien: I suggest you disable the attach button while resizing is going on.

I still can reproduce it after waiting the banner "Converting to media message" and "resizing attached image" going away
Gaia      fabc8154b31178515795b0a32068257fd5a16269
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/a500e34d8819
BuildID   20140511164002
Version   28.1

Comment 4

[Julien Wajsberg [:julienw]]

Fabrice, any idea what could produce this:

>  I/Gecko   (   85): Security problem: Content process does not have `device-storage:pictures-read'.  It will be killed.

Is it "possible" that the Blob we get from the Gallery app has not finished reading all the data from storage, and when we try to access it from the SMS app, we ends up needing this permission?

Comment 5

[[:fabrice] Fabrice Desré]

On tarako, the message and the gallery app will sharing the same process in this case since the gallery is started by an activity. So both die at the same time when we OOM, and the "Security problem" message is likely from tearing down some objects out of order. Not much we can do there...

Comment 6

[Joe Cheng [:jcheng] (please needinfo)]

(In reply to Mike Lien[:mlien] from comment #3)
> (In reply to David Flanagan [:djf] from comment #2)
> > If I follow the STR, I can reproduce a SMS crash, but it is clearly an OOM.
> > I don't see anything related to security.
> > 
> > My hypothesis is that this happens when a new pick activity is launched
> > while images are still being resized. Mike: can you reproduce this if you
> > wait for the "resizing attached image" banner to go away before clicking the
> > paperclip again?
> > 
> > Julien: I suggest you disable the attach button while resizing is going on.
> 
> I still can reproduce it after waiting the banner "Converting to media
> message" and "resizing attached image" going away
> Gaia      fabc8154b31178515795b0a32068257fd5a16269
> Gecko    
> https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/a500e34d8819
> BuildID   20140511164002
> Version   28.1

hi Mike, is the reproduce rate still 70% after you wait for things to finish? can you provide the reproduce rate? thanks

Comment 7

[Mike Lien[:mlien]]

verified with the latest daily build, reproduce rate is 1/7
Gaia      9699b942b6d0c79c64aa33c2c2ed533ee2c9c852
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/292f924a4475
BuildID   20140515164002
Version   28.1

Comment 8

[Joe Cheng [:jcheng] (please needinfo)]

given that the reproduce rate is much lower if we wait for the resizing to be done
Julien, do you think it makes sense to take djf's suggestion in comment 2? Thanks 

"Julien: I suggest you disable the attach button while resizing is going on."

Comment 9

[Julien Wajsberg [:julienw]]

I'll look on an actual Tarako later on.

Comment 10

[Julien Wajsberg [:julienw]]

My Tarako does not have the latest code so I'll try to get it flashed and report later.

djf's suggestion sound reasonable though.

Comment 11

[Joe Cheng [:jcheng] (please needinfo)]

will you be able to provide a patch this week? :)

Comment 12

[Julien Wajsberg [:julienw]]

I can if the bug is made 1.3t+, but it's still not.

Comment 13

[Julien Wajsberg [:julienw]]

Also, I'd like to know if this is still an issue with the latest code.

I just flashed my Tarako with the latest build and I can't reproduce (while I could reproduce with older builds).

Comment 14

[Mike Lien[:mlien]]

verify with today's daily build, "Security problem" reproduce rate is still very low like comment 7
additionally, if doesn't wait the banner "Converting to media message" and "resizing attached image" going away, OOM rate is higher than waiting it finished

Gaia      de7f2cb97b548f6e882e9a5077577827f1bcc054
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/446f2970cf94
BuildID   20140520164000
Version   28.1

If you think this issue's summary mismatch current fixing trend, please feel free to modify it

Comment 15

[Julien Wajsberg [:julienw]]

Mike, do you please have the average reproduce rate for OOM when not waiting for "resizing image" to disappear?

Comment 16

[Mike Lien[:mlien]]

attach 4 images, OOM reproduce rate
waiting "resizing image" disappear: 1/7
not waiting "resizing image" disappear: 7/7

Comment 17

[Joe Cheng [:jcheng] (please needinfo)]

triage: 1.3T+, this is a parnter blocker

Comment 18

[Joe Cheng [:jcheng] (please needinfo)]

hi Julien, mind taking? :)

Comment 19

[Steve Chung [:steveck]]

Since Julien might busy on other tasks, I can take it forst. And maybe we can just uplift bug 995116 and block attach action while resizing to avoid OOM issue.

Comment 20

[Julien Wajsberg [:julienw]]

+1 to everything you said in comment 19. And thanks for taking!

Comment 21

[Steve Chung [:steveck]]

Attachment: Link to github

Hi Julien, this patch uplift bug 995116 with some conflict changes and block file attaching while resizing. Maybe we should file another patch to master for the attachment blocking behavior?

Comment 22

[Julien Wajsberg [:julienw]]

Comment on attachment 8426968 [details] [review]
Link to github

r=me in the current form

Still I found a small issue, so if you decide to fix it, please ask review again. Otherwise, maybe it's better to do it in another bug and leave 1.3t with the smallest change to fix the reported issue.

Comment 23

[Julien Wajsberg [:julienw]]

Obviously, please merge on a green travis :)

Comment 24

[Steve Chung [:steveck]]

Comment on attachment 8426968 [details] [review]
Link to github

I think we should'nt allow this behavior which will block the usage even it's hard to reproduce. Requesting the review again with issue addressed, thanks for discovering this bug!

Comment 25

[Julien Wajsberg [:julienw]]

Comment on attachment 8426968 [details] [review]
Link to github

r=me
works perfectly.

I'm landing it !

Comment 26

[Julien Wajsberg [:julienw]]

v1.3t: 310924dd38f5130955f9ceeb2a3855ce028b27d2

Comment 27

[Rachel Pribble [:rpribble]]

Verified as fixed on the latest Tarako build.

1.3T Environmental Variables:
Device: Tarako 1.3T
BuildID: 20140602014001
Gaia: 335486c42498fa7a93c21e4d6121199728602ab8
Gecko: 55e4d83019e5
Version: 28.1
Firmware Version: SP6821a-Gonk-4.0-4-29

Can attach images as expected.