Closed Bug 1259192 Opened 9 years ago Closed 5 years ago

crash in mozalloc_abort | NS_DebugBreak | mozilla::ipc::FatalError | mozilla::net::PHttpChannelChild::FatalError | mozilla::net::PHttpChannelChild::OnMessageReceived

Categories

(Core :: Networking, defect, P3)

x86
Windows NT
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
e10s + ---
firefox48 --- affected

People

(Reporter: elan, Unassigned)

References

Details

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

Crash Data

This bug was filed from the Socorro interface and is report bp-e56984e3-1431-4858-bf44-612e52160312. =============================================================
:jduell, e10s top crash can you find an assignee?
Flags: needinfo?(jduell.mcbugs)
I wonder why the message argument to NS_RUNTIMEABORT wasn't included in the crash report...
Putting this on the backlog for now, Jason, feel free to make active once we have an assignee
Whiteboard: [necko-backlog]
Blocks: e10s-crashes
(In reply to Josh Matthews [:jdm] from comment #2) > I wonder why the message argument to NS_RUNTIMEABORT wasn't included in the > crash report... That's bug 1236108 and its dependencies.
It looks like this shows up slightly differently on Nightly due to differences in inlining, I assume.
Crash Signature: [@ mozalloc_abort | NS_DebugBreak | mozilla::ipc::FatalError | mozilla::net::PHttpChannelChild::FatalError | mozilla::net::PHttpChannelChild::OnMessageReceived] → [@ mozalloc_abort | NS_DebugBreak | mozilla::ipc::FatalError | mozilla::net::PHttpChannelChild::FatalError | mozilla::net::PHttpChannelChild::OnMessageReceived] [@ mozalloc_abort | NS_DebugBreak | mozilla::ipc::FatalError | mozilla::net::PHttpChannelChil…
Assuming my line numbers match up, that's crashing here: if ((!(Read((&(cacheKey)), (&(msg__)), (&(iter__)))))) { FatalError("Error deserializing 'uint32_t'");
Assignee: nobody → kchen
Depends on: 1260270
See Also: → 1258312
Flags: needinfo?(jduell.mcbugs)
Priority: -- → P1
Signature will be changed to OOM by bug 1258312. Close for now. If the signature shows up again we could reopen.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Nightly 20160429030215 had 12 occurrences of https://crash-stats.mozilla.com/report/index/9edbd88b-a899-467f-a91f-9e4522160430, but there were all from a single user. Kan-Ru, I'm needinfo'ing you in case you want to take a look.
Flags: needinfo?(kchen)
I took a look and found the error is "[Child 1036] ###!!! ABORT: IPDL error [PHttpChannelChild]: \"Error deserializing 'NetAddr'\". abort()ing as a result." on Msg_OnStartRequest In NeckoMessageUtils.h there is one comment: /* If we get here without hitting any of the cases above, there's not much * we can do but let the deserializer fail when it gets this message */ https://dxr.mozilla.org/mozilla-central/rev/0a25833062a880f369e6f9f622413a94cc671bf4/netwerk/ipc/NeckoMessageUtils.h#101-102 I'm not sure if we are hitting this path but it seems better to crash in the Write side instead of the Read side.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
I see 8 more crashes in the 5/02 build, so clearly this is an ongoing issue. (In reply to Kan-Ru Chen [:kanru] (UTC+8) from comment #9) > I'm not sure if we are hitting this path but it seems better to crash in the > Write side instead of the Read side. Definitely! Crashing in the Write() could give the information the Necko team needs to fix whatever is going wrong.
Depends on: 1270247
On Nightly, there were many crashes on 5-2, and many on 5-3 build, but none since then. However, the 5-2 crashes are all with a single install time, as are those on the 5-3 build, so it seems like this is all due to one or maybe two users.
Depends on: 1271888
(In reply to Jim Mathies [:jimm] from comment #12) > On beta 47 this is currently #24 - Looking at the 63 crashes in there, I'd say the majority of the crashes have a single install time, suggesting a single unlucky persistent user.
Flags: needinfo?(kchen)
Assignee: kchen → nobody
Priority: P1 → P4
Priority: P4 → P1
Priority: P1 → P3

Closing because no crashes reported for 12 weeks.

Status: REOPENED → RESOLVED
Closed: 9 years ago5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.