1337134 - Crash in IPC::ParamTraits<mozilla::ipc::TransportDescriptor>::Read

Status: RESOLVED WORKSFORME

(Core :: IPC, defect, P3)

Description

[Marcia Knous [:marcia]]

This bug was filed from the Socorro interface and is 
report bp-a776e0f8-ff46-4409-b961-6d96d2170206.
=============================================================

Seen while reviewing nightly crash stats - crashes spiked a bit starting with 20170204030205: http://bit.ly/2lgTBj0.

Possible regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2aede0a97bc685e163196cc451b947a04ae6a598&tochange=7aa5e444af0ff686714d6165bd0e7e6d1abd0970

Comment 1

[(Away)]

This is a MOZ_RELEASE_ASSERT; how come the text doesn't appear as an annotation? Or rather, how come the annotation appears only when process_type==content?

Comment 2

[(not currently active) Ted Mielczarek]

I'm not really sure what code is involved here--can you link me to the MOZ_RELEASE_ASSERT in question?

Comment 3

[(Away)]

https://dxr.mozilla.org/mozilla-central/rev/20a8536b0bfa/ipc/glue/Transport_win.h#80

  static bool Read(const Message* aMsg, PickleIterator* aIter, paramType* aResult)
  {
...
    MOZ_RELEASE_ASSERT(aResult->mDestinationProcessId == base::GetCurrentProcId());

Comment 4

[(not currently active) Ted Mielczarek]

Hm, I don't know what's going wrong there. Can you download the dump and look at the disassembly there to see if it's setting gCrashReason? From looking at the guts of moz_release_assert that's all it really does:
https://dxr.mozilla.org/mozilla-central/rev/f505911eb333d5ae8c2bf5c44f7b85add6450b53/mfbt/Assertions.h#362
https://dxr.mozilla.org/mozilla-central/rev/f505911eb333d5ae8c2bf5c44f7b85add6450b53/mfbt/Assertions.h#36

It's possible one of those defines isn't being set right for this code and we're not actually setting the crash annotation somehow.

Comment 5

[(Away)]

I'm rather enjoying life without crash dump access :) but I disassembled a nightly:

Here's a crash with this bug's signature in a parent process with no MozCrashReason: https://crash-stats.mozilla.com/report/index/971f3166-4ebd-46ce-88a8-df6322170209#tab-metadata

0:000> u xul+0xd8c0d2 -13 L5
xul!IPC::ParamTraits<mozilla::ipc::TransportDescriptor>::Read+0x12b [c:\builds\moz2_slave\m-cen-w64-ntly-000000000000000\build\src\obj-firefox\dist\include\mozilla\ipc\transport_win.h @ 80]:
00000001`80d8c0bf 741d            je      xul!IPC::ParamTraits<mozilla::ipc::TransportDescriptor>::Read+0x14a (00000001`80d8c0de)
00000001`80d8c0c1 488b05b0e88101  mov     rax,qword ptr [xul!__imp_gMozCrashReason (00000001`825aa978)]
00000001`80d8c0c8 488d0d91cea601  lea     rcx,[xul!`string' (00000001`827f8f60)]
00000001`80d8c0cf 488908          mov     qword ptr [rax],rcx
00000001`80d8c0d2 cc              int     3
0:000> da 01`827f8f60
00000001`827f8f60  "MOZ_RELEASE_ASSERT(aResult->mDes"
00000001`827f8f80  "tinationProcessId == base::GetCu"
00000001`827f8fa0  "rrentProcId())"

In contrast here's a gfx IPC assert in the same build that _does_ give us MozCrashReason in the parent process: https://crash-stats.mozilla.com/report/index/04845532-a11a-44d2-b35b-4219c2170209#tab-rawdump

0:000> u xul+0xd974d3-13 L5
xul!mozilla::gfx::FeatureChange::AssertSanity+0x4c [c:\builds\moz2_slave\m-cen-w64-ntly-000000000000000\build\src\obj-firefox\ipc\ipdl\_ipdlheaders\mozilla\gfx\graphicsmessages.h @ 490]:
00000001`80d974c0 741d            je      xul!mozilla::gfx::FeatureChange::AssertSanity+0x6b (00000001`80d974df)
00000001`80d974c2 488b05af348101  mov     rax,qword ptr [xul!__imp_gMozCrashReason (00000001`825aa978)]
00000001`80d974c9 488d0d38f7a101  lea     rcx,[xul!`string' (00000001`827b6c08)]
00000001`80d974d0 488908          mov     qword ptr [rax],rcx
00000001`80d974d3 cc              int     3
0:000> da 1`827b6c08
00000001`827b6c08  "MOZ_RELEASE_ASSERT((mType) == (a"
00000001`827b6c28  "Type)) (unexpected type tag)"

The asm is the same.

I see that the first crash is also missing some common fields like AvailableVirtualMemory and friends. I vaguely remember there being some difference about this in e10s but I don't remember the details at all. Is this one of those cases where one process captures a dump of itself as well as the other, or something?

Comment 6

[(not currently active) Ted Mielczarek]

Oh! Maybe this is just bug 1323097?

Comment 7

[Marcia Knous [:marcia]]

Resolving this as WFM. 2 crashes overall in the 69 cycle.