1259183 - crash in OOM | large | NS_ABORT_OOM | nsACString_internal::Assign | IPC::ParamTraits<T>::Read

Status: RESOLVED WORKSFORME

(Core :: Networking: HTTP, defect, P1)

Description

[Erin Lancaster [:elan]]

This bug was filed from the Socorro interface and is 
report bp-936932cd-0288-4555-804e-b57492160314.
=============================================================

Comment 1

[Andrew McCreight [:mccr8]]

Aaron, is it expected that these crashes won't have size annotations? For instance, this crash from a Nightly build from a few days ago.
  https://crash-stats.mozilla.com/report/index/2dd44054-188e-4a1b-ad2c-7892b2160322

Comment 2

[Andrew McCreight [:mccr8]]

I looked at about a dozen of these crash reports, and they were all inside IPC::ParamTraits<nsACString_internal>::Read(IPC::Message const*, void**, nsACString_internal*) and mozilla::net::PHttpChannelChild::OnMessageReceived(IPC::Message const&). I'm guessing that the parent is sending the child some gigantic string, and then content process doesn't have a large enough block of contiguous memory to create the string.

Comment 3

[Andrew McCreight [:mccr8]]

It might be nice to add IPC::ParamTraits<T>::Read to the skip list so we see in general where these are coming from, but if they are really all just networking maybe it isn't worth the effort.

Comment 4

[Andrew McCreight [:mccr8]]

This is kind of a dupe of bug 1199490, though nothing much happened there.

Comment 5

[Jim Mathies [:jimm]]

(In reply to Andrew McCreight [:mccr8] from comment #1)
> Aaron, is it expected that these crashes won't have size annotations? For
> instance, this crash from a Nightly build from a few days ago.
>  
> https://crash-stats.mozilla.com/report/index/2dd44054-188e-4a1b-ad2c-
> 7892b2160322

Pretty sure this is covered by bug 1236108.

Comment 6

[Andrew McCreight [:mccr8]]

(In reply to Jim Mathies [:jimm] from comment #5)
> Pretty sure this is covered by bug 1236108.

Sorry, I should have been more explicit. The crash I linked is in a build that includes the patches for  bug 1236108, and I wasn't sure if that was expected or not. The annotation seems to be failing sometimes, though maybe not enough to worry about.

Comment 7

[(No longer employed by Mozilla) Aaron Klotz]

It's probably bug 1256541.

Comment 8

[u408661]

Jason, not sure we need an assignee for this one immediately (not a topcrash, that I can see), but you might feel differently (also take a look at comment 4)

Comment 9

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to Nicholas Hurley [:nwgh][:hurley] from comment #8)
> Jason, not sure we need an assignee for this one immediately (not a
> topcrash, that I can see), but you might feel differently (also take a look
> at comment 4)

This is a top crash within the e10s population.

Comment 10

[Andrew McCreight [:mccr8]]

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #9)
> This is a top crash within the e10s population.

It is curious that this is a top crash on beta e10s, but I only see a couple of crashes on Nightly.

Comment 11

[Andrew McCreight [:mccr8]]

Bug 1235633 (and possibly bug 1263235) should help with this by reducing peak memory usage. Bug 1263028 should help more directly by reducing the size of these messages.

Comment 12

[Andrew McCreight [:mccr8]]

I'd expect that this won't be a problem on the next beta, thanks to the work that this bug depends on. If it is, then bug 1110596 should fix this.

Comment 13

[Andrew McCreight [:mccr8]]

I'm going to mark this as WORKSFORME because the Http case should be fixed. We can reopen it if there's still enough related crashes once the new beta is out for a bit.