983885 - Contact app leaks memory over a period of time and killed by LMK

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Contacts, defect, P1)

Description

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

STR:

1) Flash a new build on device or reset gaia to ensure that contact app has zero contacts. 
2) Open contact app .
2) Click on "+" icon to add a new contact
3) Take pic from camera and save this new contact. You will see list of contacts after saving contact with pic.
4) Repeat step (2) and (3) quickly until you see contact app is killed by OOM
5) Repeat step (2), (3) and (4) for 2-3 times.

If you follow above STR then you can see contact app huge memory growth within 30mins.
Observation:

1) |adb shell cat /sys/kernel/debug/ion/iommu| shows that contact app allocated 31731712 KB ION as orphan allocation. This means that contact app has created ION handle but didn't close it. 

2) Contact App USS grows 15MB to 40MB very quickly and if you keep following above STR then you can see USS is becoming 70-100MB before it is killed by LMK.

2) if you kill contact app (after following above STR) and reopen it Contact App ION allocation will be < 20MB and also USS will become 15740 MB for same number of contacts.


I attached IOMMU logs and gecko memory report for both affected device and unaffected device.

Device Used:
I am using v1.3 (JB based) gaia/gecko and MSM8610 WVGA device . I collected DMD logs for following gaia/gecko revision. And I am sure that it is also present in latest v1.3 tip.

gecko revision: https://www.codeaurora.org/cgit/quic/lf/b2g/mozilla/gecko/commit/?h=mozilla/v1.3&id=fcf711bbb0affff0925cb133c82073998bb46abf

gaia revision: https://www.codeaurora.org/cgit/quic/lf/b2g/mozilla/gaia/commit/?h=mozilla/v1.3&id=e8bf7326ce5ed63bc8ef8b2cff1eba094887b9bf

Comment 1

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: affected device memory reports

Comment 2

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: unaffected device memory reports

Comment 3

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: logcat and dmesg

I attached multiple attachments as bugzilla has limitation of 10MB.

Comment 4

[Andreas Gal :gal]

Why is this JS engine?

Comment 5

[Gregor Wagner [:gwagner]]

I thought these are ION-jit allocations.

Comment 6

[Andreas Gal :gal]

Can you please email the JS team to get someone on this?

Comment 7

[Michael Vines [:m1] [:evilmachines]]

Tapas was referring to gralloc ION buffers, not something in the jit.

Comment 8

[Andreas Gal :gal]

Michael, can you guys make sure that bugs that block your CS are marked as b2g-blocking=1.3+ asap? Until that flag goes to + our drivers team isn't looking at them. Thanks!

Comment 9

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Any update here ?

Comment 10

[Eric Rahm [:erahm]]

A quick look at the DMD log for the Communications process indicates two image related allocations of 12MiB, one reported one not. It seems quite possible these are related and certainly large enough to warrant concern.

Unreported: 1 block in stack trace record 1 of 405
 12,582,912 bytes (12,582,912 requested / 0 slop)
 29.81% of the heap (29.81% cumulative);  77.64% of unreported (77.64% cumulative)
 Allocated at
   replace_malloc
   sk_malloc_flags(unsigned int, unsigned int)
   SkBitmap::HeapAllocator::allocPixelRef(SkBitmap*, SkColorTable*)
   SkBitmap::allocPixels(SkBitmap::Allocator*, SkColorTable*)
   SkBitmap::copyTo(SkBitmap*, SkBitmap::Config, SkBitmap::Allocator*) const
   mozilla::gfx::SourceSurfaceSkia::InitFromData(unsigned char*, mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits> const&, int, mozilla::gfx::SurfaceFormat)
   mozilla::gfx::DrawTargetSkia::CreateSourceSurfaceFromData(unsigned char*, mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits> const&, int, mozilla::gfx::SurfaceFormat) const
   gfxPlatform::GetSourceSurfaceForSurface(mozilla::gfx::DrawTarget*, gfxASurface*) 

===========================================================

Once-reported: 1 block in stack trace record 1 of 687
 12,582,912 bytes (12,582,912 requested / 0 slop)
 29.81% of the heap (29.81% cumulative);  48.38% of once-reported (48.38% cumulative)
 Allocated at
   replace_memalign
   replace_posix_memalign
   TryAllocAlignedBytes
   gfxImageSurface::gfxImageSurface(nsIntSize const&, gfxImageFormat, bool)
   nsRefPtr<gfxImageSurface>::operator=(gfxImageSurface*)
   mozilla::image::RasterImage::InternalAddFrame(unsigned int, int, int, int, int, gfxImageFormat, unsigned char, unsigned char**, unsigned int*, unsigned int**, unsigned int*, imgFrame**)
   mozilla::image::RasterImage::EnsureFrame(unsigned int, int, int, int, int, gfxImageFormat, unsigned char, unsigned char**, unsigned int*, unsigned int**, unsigned int*, imgFrame**)
   mozilla::image::RasterImage::EnsureFrame(unsigned int, int, int, int, int, gfxImageFormat, unsigned char**, unsigned int*, imgFrame**)
   mozilla::image::Decoder::AllocateFrame()
   mozilla::image::RasterImage::InitDecoder(bool)
   mozilla::image::RasterImage::SyncDecode()
   mozilla::image::RasterImage::GetFrame(unsigned int, unsigned int, gfxASurface**)
   nsLayoutUtils::SurfaceFromElement(nsIImageLoadingContent*, unsigned int)
   ~nsCOMPtr
   nsRefPtr<gfxASurface>::get() const
   drawImage

Comment 11

[Ben Kelly [:bkelly, not reviewing]]

I wonder if this is a case of contacts trying to downsample a large image to generate the contacts thumbnail.  In theory, though, I would have thought the camera exif preview would have prevented this from operating on a giant image.

Michael, does your QRD device firmware generate exif previews for camera images?

We should try to reproduce this on an open c.

Comment 12

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Ben Kelly [:bkelly] from comment #11)
> I wonder if this is a case of contacts trying to downsample a large image to
> generate the contacts thumbnail.  In theory, though, I would have thought
> the camera exif preview would have prevented this from operating on a giant
> image.
> 
> Michael, does your QRD device firmware generate exif previews for camera
> images?
> 
> We should try to reproduce this on an open c.

If you follow the given STR then you should be able to see contact list with thumbnails in STEP-3 . You can keep your device idle for minutes but still memory is not freed. 

I guess that contact app must free all big chunks of memory (which it allocated either in thumbnail generation process or during camera preview) after finishing STEP-3. But that does not happen.

Comment 13

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Can you please suggest for what is causing contact app not to release USS memory or releasing ION buffer handle even after displaying contact list (with newly saved contacts using camera) with thumbnails ?

Comment 14

[Ben Kelly [:bkelly, not reviewing]]

So I initially tried to reproduce this on buri.  I can see memory usage climb up to ~70MB after taking pictures, but it then falls back to ~15MB as I continue to add contacts and take pictures.

I can't check the ion usage as the buri does not have that allocator.  I will try to reproduce on my open c.

Comment 15

[Ben Kelly [:bkelly, not reviewing]]

So on my open c I can reproduce something similar, but not quite the same.

If I have camera app running on its own before starting the steps in comment 0, then I see camera memory grow until it OOMs.

With or without camera running, though, the communications process bounces between 40MB and 70MB without OOMing.

Comment 16

[Ben Kelly [:bkelly, not reviewing]]

Also, as far as I can tell the output from |adb shell cat /sys/kernel/debug/ion/iommu| is a little bit misleading.  It seems to consider all gecko ION allocations as "orphaned", but you can see they get closed out as you navigate on the phone.

Still, its a handy tool to see what the ION allocator is doing.  Thanks!

Comment 17

[Jason Smith [:jsmith]]

Going to assume that Ben's testing in comment 15 met the QA Wanted request, as the testing needed was for Open C.

Comment 18

[Ben Kelly [:bkelly, not reviewing]]

I think contacts app can be a lot more efficient by aggressively cleaning up its canvas and img elements.  I have a patch I'm testing now that keeps our memory at ~15MB instead of ballooning up to 60MB.

Comment 19

[Ben Kelly [:bkelly, not reviewing]]

Attachment: Pull request at https://github.com/mozilla-b2g/gaia/pull/17335

This pull request aggressively cleans up img and canvas elements used to resize images in contacts.

Comment 20

[Ben Kelly [:bkelly, not reviewing]]

Tapas, can you run your test with the patch in attachment 8393647 [details] [review]?  That should apply against v1.3 cleanly.

Comment 21

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Ben Kelly [:bkelly] from comment #20)
> Tapas, can you run your test with the patch in attachment 8393647 [details] [review]?
> That should apply against v1.3 cleanly.

Thanks I will try it asap and update here. Thanks for your effort.

Comment 22

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to Ben Kelly [:bkelly] from comment #19)
> Created attachment 8393647 [details] [review]
> Pull request at https://github.com/mozilla-b2g/gaia/pull/17335
> 
> This pull request aggressively cleans up img and canvas elements used to
> resize images in contacts.

So, the pattern is: draw it to context, then get rid of all the images that were just drawn into context, then do the "toBlob" from the context?  I like it.  That should hopefully reduce the peak memory usage, and Tapas will tell us if it removes the "leaks".  If this ends up being the case, we should check for other places where we "toBlob" and see if the similar pattern applies, and move this bug to the contact app for the right credit.

Comment 23

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Comment on attachment 8393647 [details] [review]
Pull request at https://github.com/mozilla-b2g/gaia/pull/17335

Contact APP is limited to <25MB and Total orphan allocation is limited to <23MB even after 30mins to testing. I asked our internal team to test for longer duration. I will update soon here again. It is surely a big improvement compared to my 1st comment in this bug.

Comment 24

[Jose Manuel Cantera]

Hi Ben,

I left a couple of comments on GH. Once fixed I will test it and r+ accordingly.

thanks for the work!

Comment 25

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Jose M. Cantera from comment #24)
> I left a couple of comments on GH. Once fixed I will test it and r+
> accordingly.

Thanks Jose!

In regards to your comment about moving some of the code to a utils, I was actually thinking maybe we should just have "resize image" function defined in shared/js.  I think a lot of apps need to do this, not just contacts.

David, do you have any objections to me creating a new shared/js/media/jpeg_resize.js file?  I think the only tricky part would be creating an API to support resizing to fixed dimensions vs maintaining aspect ratio, etc.

Comment 26

[David Flanagan [:djf]]

Ben,

I've got no objection. I assume you're going to use the new #-moz-samplesize media fragment to do it, right?  

I can't imagine any use case where altering the aspect ratio would be the right thing to do, so I suspect that the API will just have to have a choice between letterboxing ("fit"/"contain") and overflowing ("fill"/"cover").

Note that in order to use -moz-samplesize you have to know the dimensions of the source image.  apps/gallery/js/imagesize.js has code that can do this. It depends on shared/js/media/jpeg_metadata_parser.js and shared/js/blobview.js

Using imagesize.js to get the size of a jpeg will also get you some EXIF metadata from the image, and in particular it will tell you if there is an EXIF preview for the image. If there is, you can recursively check the size of that preview and use it instead of the full-size image if it is big enough.

Comment 27

[Ben Kelly [:bkelly, not reviewing]]

(In reply to David Flanagan [:djf] from comment #26)
> Ben,
> 
> I've got no objection. I assume you're going to use the new #-moz-samplesize
> media fragment to do it, right?  

Unfortunately I need something that will work on v1.3 which does not have bug 854795.

Can I land without it initially, and then do a second bug to upgrade it on v1.4?

> I can't imagine any use case where altering the aspect ratio would be the
> right thing to do, so I suspect that the API will just have to have a choice
> between letterboxing ("fit"/"contain") and overflowing ("fill"/"cover").

Well, contacts has its image_square.js:

  https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/contacts/js/utilities/image_square.js

> Note that in order to use -moz-samplesize you have to know the dimensions of
> the source image.  apps/gallery/js/imagesize.js has code that can do this.
> It depends on shared/js/media/jpeg_metadata_parser.js and
> shared/js/blobview.js
> 
> Using imagesize.js to get the size of a jpeg will also get you some EXIF
> metadata from the image, and in particular it will tell you if there is an
> EXIF preview for the image. If there is, you can recursively check the size
> of that preview and use it instead of the full-size image if it is big
> enough.

Hmm, I think this is fancier than what contacts is currently doing.  There we load the entire img to get width/height.  Part of my fix here is to aggressively free the img afterwards.

Comment 28

[Ben Kelly [:bkelly, not reviewing]]

Comment on attachment 8393647 [details] [review]
Pull request at https://github.com/mozilla-b2g/gaia/pull/17335

I've pushed an updated version of code to the PR that moves the resizing logic to:

  shared/js/media/resize_image.js

Since a lot of code seems to want to do something slightly different to calculate size parameters I ended up using a callback function.  So the user provides something like:

  function transform(origWidth, origHeight, draw, cancel) {
    // calculations...
    draw(srcX, srcY, srcWidth, srcHeight, targWidth, targHeight);
  }

Or if they detect that resizing is not needed, then can call cancel() instead.

If there are common transformations we could in theory provide stock transform functions for these, but currently I do not.

David, what do you think?  Are there any improvements here that we could make that are also 1.3 compatible?

Jose, Francisco, please note that I changed the thumbnails from PNG to JPEG here.  I assume it was a bug they were being created as PNG?  Or was that intentional?

Comment 29

[David Flanagan [:djf]]

Comment on attachment 8393647 [details] [review]
Pull request at https://github.com/mozilla-b2g/gaia/pull/17335

Your resizeImage() function seems like a clever design.  My feedback- is only about landing it in shared/js/

The reason is that this function always decoded the image at full size, which can take a lot of memory.  Current bug 854795 gives us a way to downsample an image while decoding it and save memory. That bug may be backed out in favor of 945161.  But either way, we are going to get a way to get smaller versions of images without ever having to decode the fullsize image. (The tricky bit to using this new feature is that we have to be able to determine the size of the original image without decoding it.)

Anyway, if we're going to create a generic image resizing function in shared/js/ I'd like it to use whichever of these new decode-while-downsampling features becomes available.  

So for now I recommend you land this only in contacts and that we revisit for inclusion in shared/ when we can do the memory-saving version.

Comment 30

[Ben Kelly [:bkelly, not reviewing]]

Thanks David!  I created a new bug to track getting a shared/js implementation in the future.  See bug 986229.

Comment 31

[Ben Kelly [:bkelly, not reviewing]]

Comment on attachment 8393647 [details] [review]
Pull request at https://github.com/mozilla-b2g/gaia/pull/17335

Ok, I've updated the PR again.

I'm dropping David's f- as I moved resize_image.js from shared/js to contacts/js/utilities.

I've tested that creating a new contact with an image from the camera and importing from facebook both work.

Jose, Francisco, I'm still curious what you think about jpeg vs png.  Again, this patch converts things to use JPEG for our thumbnails.

Also, it feels like images might load a bit slower now.  I'm not sure if that's just how image loading is now with APZ or if its this patch.

Unfortunately I am going on PTO tomorrow, so I won't be able to work on this any more until Monday.  If this gets an r+, can you go ahead with the landing and uplift to v1.3 and v1.4?

Comment 32

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

It looks fine to me in automation. please land it asap

Comment 33

[Jose Manuel Cantera]

Comment on attachment 8393647 [details] [review]
Pull request at https://github.com/mozilla-b2g/gaia/pull/17335

too complicated solution, indirections introduced, high regression risk. We should aim at another solution that simply cleans up resources and perhaps places the clean up code in a common function

Comment 34

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Jose M. Cantera from comment #33)
> too complicated solution, indirections introduced, high regression risk. We
> should aim at another solution that simply cleans up resources and perhaps
> places the clean up code in a common function

Well, this is why I suggested just fixing the three cases of image resizing directly. :-)

I don't think its as easy as just sticking this in utils:

  function cleanupImg() {
    img.src = '';
    URL.revokeObjectURL(url);
  }

For a number of reasons:

1) I think part of the tricky bit is making sure this gets called at the proper places.  In the success path this needs to happen after |canvas.drawImage()|, but before |canvas.toBlob()|.  It also needs to be called in the onerror path.  Right now contacts fails to provide an onerror in two of its three image resizing routines.

2) The code is going to have to pass in |img| and |url|.  If the calling code needs to know exactly what needs to be cleaned up, what is the benefit of creating a utility routine?  We haven't really abstracted anything.

3) It will take more code to define the utils module and load it than it will to actually perform the |cleanupImg()| work.

The patch I proposed here factors out all the common code to resize the image.  I think this, or something like it, is necessary if you want to remove duplicate code between these routines.

For these reasons I would prefer to go with either:

a) The original patch which just fixed the three cases of image resizing directly.
b) This proposed patch (with review cleanup) that factors out the common parts of the image resizing work.

Please let me know which way you'd like me to proceed.  Thanks.

Comment 35

[Jose Manuel Cantera]

(In reply to Ben Kelly [:bkelly] from comment #34)
> (In reply to Jose M. Cantera from comment #33)
> > too complicated solution, indirections introduced, high regression risk. We
> > should aim at another solution that simply cleans up resources and perhaps
> > places the clean up code in a common function
> 
> Well, this is why I suggested just fixing the three cases of image resizing
> directly. :-)
> 
> I don't think its as easy as just sticking this in utils:
> 
>   function cleanupImg() {
>     img.src = '';

> a) The original patch which just fixed the three cases of image resizing
> directly.

I would prefer a/ as it is less risky. Sorry for changing my mind ... ;)

Comment 36

[Ben Kelly [:bkelly, not reviewing]]

Attachment: Pull request at https://github.com/mozilla-b2g/gaia/pull/17535

Ok, here is a new pull request that returns to the previous approach.  I made some slight improvements to more consistently cleanup in the right order in all three cases.

I left the 'image/jpeg' parameters (or missing ones) to canvas.toBlob() untouched.

Comment 37

[Andreas Gal :gal]

Why not jpeg?

Comment 38

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Andreas Gal :gal from comment #37)
> Why not jpeg?

Francisco, can you explain?  It sounded like this was intentional, but I did not follow the rationale during our IRC conversation.

Comment 39

[Jose Manuel Cantera]

Comment on attachment 8395754 [details] [review]
Pull request at https://github.com/mozilla-b2g/gaia/pull/17535

thanks

Comment 40

[Francisco Jordano [:arcturus] [:francisco]]

(In reply to Ben Kelly [:bkelly] from comment #38)
> (In reply to Andreas Gal :gal from comment #37)
> > Why not jpeg?
> 
> Francisco, can you explain?  It sounded like this was intentional, but I did
> not follow the rationale during our IRC conversation.

Hi Ben!

Sorry, long day for me and couldn't explain myself well on IRC, let's see if now I can do better ;)

I was trying to say, that we do use the advantage from the web activities to ask for jpeg, no matter if we don't have jpeg images on our gallery, the gallery will give us a jpeg blob. So we were using that advantage to get smaller images.

In the other places we SHOULD ask for jpeg as well, (unless Jose will say something about the FB images).

Hope this clarifies a bit.

Thanks Ben!

Comment 41

[Ben Kelly [:bkelly, not reviewing]]

Thanks Francisco.  I split the image/jpeg issue off into a separate bug since we probably want some additional testing with that change and its not necessary for the blocker here.  See bug 987692.

Comment 42

[Francisco Jordano [:arcturus] [:francisco]]

Thanks Ben, sounds like the best option!

Comment 43

[Ben Kelly [:bkelly, not reviewing]]

Comment on attachment 8395754 [details] [review]
Pull request at https://github.com/mozilla-b2g/gaia/pull/17535

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): 983885
[User impact] if declined: Contacts app uses too much memory while manipulating images which can result in an OOM.
[Testing completed]: On device testing on v1.3 creating new contact with thumbnail taken with camera and importing ~170 FB contacts.
[Risk to taking this patch] (and alternatives if risky): Moderate
[String changes made]: None

Comment 44

[Ben Kelly [:bkelly, not reviewing]]

Merged to master:

  https://github.com/mozilla-b2g/gaia/commit/85a8b83f5ef61f182d2128a33b609a60d6953391

Comment 45

[Ben Kelly [:bkelly, not reviewing]]

Fabrice indicated he'd like to get this verified on master before approving for uplift.

Comment 46

[Ben Kelly [:bkelly, not reviewing]]

Note, on our builds I could not exactly reproduce with STR from comment 0.  You should be able to watch contacts memory usage with b2g-info, though, to compare with and with-out the patch.

Comment 47

[Ben Kelly [:bkelly, not reviewing]]

Fabrice, would it be acceptable if Tapas verified this on the CAF side with the specific patch that landed?

Tapas, can you verify if this commit fixes the issue for you on 1.3?

  https://github.com/mozilla-b2g/gaia/commit/85a8b83f5ef61f182d2128a33b609a60d6953391

Its similar to previous patches you tested, but did have some slight modifications.

I just don't want to let this languish too long as it seems people are moving focus to 1.4.

Thanks!

Comment 48

[[:fabrice] Fabrice Desré]

Yes that would work for me.

Comment 49

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Ben Kelly [:bkelly] from comment #47)
> Fabrice, would it be acceptable if Tapas verified this on the CAF side with
> the specific patch that landed?
> 
> Tapas, can you verify if this commit fixes the issue for you on 1.3?
> 
>  
> https://github.com/mozilla-b2g/gaia/commit/
> 85a8b83f5ef61f182d2128a33b609a60d6953391
> 
> Its similar to previous patches you tested, but did have some slight
> modifications.
> 
> I just don't want to let this languish too long as it seems people are
> moving focus to 1.4.
> 
> Thanks!

It looks fine in my testing . Thanks a lot for your help :)

Comment 50

[Ben Kelly [:bkelly, not reviewing]]

Jason, same question about approval on this bug as well.  I think we have the criteria Fabrice was asking for, but I believe he is on PTO this week..  See comment 45, comment 47, comment 48, and comment 49.

Comment 51

[Ben Kelly [:bkelly, not reviewing]]

Preeti, Bhavana, can one of you grant approval for the patch here to be uplifted.  Please comments 45 to 49 for the testing completed that Fabrice had asked for.  He is on PTO this week, so need help with the approval.  Thanks!

Comment 52

[Ryan VanderMeulen [:RyanVM]]

v1.4: https://github.com/mozilla-b2g/gaia/commit/df89f42cc6f3da5c059432c5391fbb9657a231d2
v1.3: https://github.com/mozilla-b2g/gaia/commit/b50a6a62911e92b33fa47b3bd82f269762f0928f

Comment 53

[Preeti Raghunath(:Preeti)]

Thanks Ben. Looks like Bhavana has approved this one.

Comment 54

[Roland Kunkel [:RolandK]]

Verified as fixed, Master v1.5. I am unable to reproduce the oom as described in comment #0 on the latest v1.5 Master Buri build:

Environmental Variables:
4/3 v1.5 Device: Buri 1.5 MOZ RIL
BuildID: 20140403040201
Gaia: 0e974ff33ba47f3d1e59df1e0ad534f1bbe3ef8a
Gecko: 91be2828f17e
Version: 31.0a1
Firmware Version: V1.2-device.cfg

-

Verified as fixed, v1.4. I am unable to reproduce the oom as described in comment #0 on the latest v1.4 Buri build:

Environmental Variables:
4/3 v1.4 Device: Buri 1.4 MOZ RIL
BuildID: 20140403000210
Gaia: e0186439b9c2c03acd78e9ae011a0071865e7ffb
Gecko: 5bccd264a0e3
Version: 30.0a2
Firmware Version: V1.2-device.cfg

-

Verified as fixed, v1.3. I am unable to reproduce the oom as described in comment #0 on the latest v1.3 Buri build:

4/3 v1.3 Environmental Variables:
Device: Buri 1.3 MOZ RIL
BuildID: 20140403004001
Gaia: c5cd3a11e91339163b351d50769eaca0067da860
Gecko: c6c7b01cdb8e
Version: 28.0
Firmware Version: V1.2-device.cfg

-

1) Verified against Master v1.5, changing bug status to verified.