Crash in ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.6210015070520384445

RESOLVED FIXED in Firefox 65

Status

()

defect
P1
critical
RESOLVED FIXED
8 months ago
8 months ago

People

(Reporter: calixte, Assigned: valentin.gosu)

Tracking

(Blocks 2 bugs, {crash, regression})

Trunk
mozilla65
Unspecified
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox63 unaffected, firefox64 unaffected, firefox65 fixed)

Details

(Whiteboard: [necko-triaged], crash signature)

This bug was filed from the Socorro interface and is
report bp-7bcdf4a4-7247-48bc-a03a-147640181127.
=============================================================

Top 10 frames of crashing thread:

0 xul.dll ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.6210015070520384445 mfbt/Assertions.h:311
1 xul.dll mozilla::ipc::FatalError ipc/glue/ProtocolUtils.cpp:301
2 xul.dll mozilla::ipc::IProtocol::HandleFatalError ipc/glue/ProtocolUtils.cpp:532
3 xul.dll mozilla::net::PNeckoChild::SendPHttpChannelConstructor ipc/ipdl/PNeckoChild.cpp:375
4 xul.dll nsresult mozilla::net::HttpChannelChild::InitIPCChannel netwerk/protocol/http/HttpChannelChild.cpp:2808
5 xul.dll mozilla::net::nsHttpHandler::NewProxiedChannel2 netwerk/protocol/http/nsHttpHandler.cpp:2236
6 xul.dll nsresult mozilla::net::nsIOService::NewChannelFromURIWithProxyFlagsInternal netwerk/base/nsIOService.cpp:861
7 xul.dll mozilla::net::nsIOService::NewChannelFromURIWithClientAndController netwerk/base/nsIOService.cpp:755
8 xul.dll NS_NewChannelInternal netwerk/base/nsNetUtil.cpp:412
9 xul.dll static nsresult NewImageChannel image/imgLoader.cpp:873

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

There are 93 crashes (from 71 installations) in nightly 65 with buildid 20181127100134. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1260527.

[1] https://hg.mozilla.org/mozilla-central/rev?node=d15f0ac561d9
Flags: needinfo?(valentin.gosu)
Crash Signature: [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.6210015070520384445] → [@ ?MOZ_CrashOOL@@YAXPEBDH0@Z.llvm.6210015070520384445] [@ ?MOZ_CrashOOL@@YAXPBDH0@Z.llvm.14621262704534561051]
This is indeed caused by bug 1260527.

@Calixte: I would have expected the crash annotation to be present. Is there an outstanding issue for that?

According to this crash:
https://crash-stats.mozilla.com/report/index/e8f68943-b0ee-4d6a-8efb-56a410181128

On frame 51 we have TabChild::ActorDestroy()
So we probably need to add a check similar to [1] to InitIPCChannel. Trouble is that we don't always have the tabChild when SetLoadInfo is called, so this needs a bit of extra thought.
I'll backout the patch, and reopen 1260527.

[1] https://searchfox.org/mozilla-central/rev/0859e6b10fb901875c80de8f8fc33cbb77b2505e/netwerk/protocol/http/HttpChannelChild.cpp#2248-2265
Assignee: nobody → valentin.gosu
Flags: needinfo?(valentin.gosu) → needinfo?(cdenizet)
Priority: -- → P1
Whiteboard: [necko-triaged]
https://hg.mozilla.org/mozilla-central/rev/9468e111ca98
Status: NEW → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
(In reply to Valentin Gosu [:valentin] from comment #1)
> This is indeed caused by bug 1260527.
> 
> @Calixte: I would have expected the crash annotation to be present. Is there
> an outstanding issue for that?
> 
:valentin, I don't know.
:gsvelto, any idea ?
Flags: needinfo?(cdenizet) → needinfo?(gsvelto)
Duplicate of this bug: 1511240
Which annotations did you expect to be present? The reports for these two signatures have different stacks and different MozCrashReason annotations.
Flags: needinfo?(gsvelto)
I would have expected the string passed to fatalError to be present in the annotation:
https://crash-stats.mozilla.com/sources/highlight/?url=https://gecko-generated-sources.s3.amazonaws.com/2713e4353dfb6432e68925028b4c709205312054f88ddb287d776c2b48437306bff8e4f61d3bacb34d74019fa8abd63a7ffb2cf8e163b98ed93bc5525338b681/ipc/ipdl/PNeckoChild.cpp#L-375

(In reply to Gabriele Svelto [:gsvelto] from comment #6)
> Which annotations did you expect to be present? The reports for these two
> signatures have different stacks and different MozCrashReason annotations.

Indeed there are some with different stack traces, but even so, for the [@ ?MOZ_CrashOOL@@YAXPBDH0@Z.llvm.14621262704534561051 ] signature, I would have expected https://crash-stats.mozilla.com/report/index/dfa07283-39ed-4014-b60e-15f7f0181127 to also have an annotation, just like https://crash-stats.mozilla.com/report/index/e1160314-c25a-4213-b88f-ae0020181128.
You need to log in before you can comment on or make changes to this bug.