Closed Bug 1259183 Opened 4 years ago Closed 4 years ago

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

Categories

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

x86
Windows NT
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
e10s + ---
firefox46 --- wontfix
firefox47 --- affected
firefox48 --- affected

People

(Reporter: elan, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: crash, Whiteboard: [necko-backlog][MemShrink:P2])

Crash Data

This bug was filed from the Socorro interface and is 
report bp-936932cd-0288-4555-804e-b57492160314.
=============================================================
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
Flags: needinfo?(aklotz)
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.
Component: IPC → Networking: HTTP
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.
This is kind of a dupe of bug 1199490, though nothing much happened there.
(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.
Flags: needinfo?(aklotz)
(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.
It's probably bug 1256541.
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)
Flags: needinfo?(jduell.mcbugs)
Whiteboard: [necko-backlog]
Blocks: e10s-crashes
Depends on: 1256541
Blocks: e10s-oom
No longer blocks: e10s-crashes
(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.
Crash Signature: [@ OOM | unknown | NS_ABORT_OOM | IPC::ParamTraits<T>::Read] → [@ OOM | unknown | NS_ABORT_OOM | IPC::ParamTraits<T>::Read] [@ OOM | large | NS_ABORT_OOM | nsACString_internal::Assign | IPC::ParamTraits<T>::Read ]
Summary: crash in OOM | unknown | NS_ABORT_OOM | IPC::ParamTraits<T>::Read → crash in OOM | large | NS_ABORT_OOM | nsACString_internal::Assign | IPC::ParamTraits<T>::Read
(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.
See Also: → 1199490
Whiteboard: [necko-backlog] → [necko-backlog][MemShrink]
Whiteboard: [necko-backlog][MemShrink] → [necko-backlog][MemShrink:P2]
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.
Depends on: 1263028, 1263235
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.
Depends on: 1110596
Flags: needinfo?(jduell.mcbugs)
Priority: -- → P1
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.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.