1293555 - Crash in IPCError-browser | (msgtype=0x2E0004,name=PBrowser::Msg_PDocAccessibleConstructor) Processing error: message was deseri

Status: RESOLVED DUPLICATE of bug 1270916

(Core :: Disability Access APIs, defect)

Description

[Ting-Yu Chou [:ting] (away)]

This bug was filed from the Socorro interface and is 
report bp-c13fdef4-3908-4763-a953-81b492160808.
=============================================================

#5 of 0807 Nightly on Windows, 16 crashes from 7 installations.

Based on the error message, it seems that RecvPDocAccessibleConstructor() returns false, however the process type is content.

Comment 1

[Ting-Yu Chou [:ting] (away)]

(In reply to Ting-Yu Chou [:ting] from comment #0)
> Based on the error message, it seems that RecvPDocAccessibleConstructor()
> returns false, however the process type is content.

The process type is incorrect, checked the minidumps, the content process was waiting for the response from chrome process, but chrome process was creating minidumps with the stack:

xul.dll!google_breakpad::ExceptionHandler::WriteMinidump() Line 747	C++
xul.dll!google_breakpad::ExceptionHandler::WriteMinidump(const std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > & dump_path, bool(*)(const wchar_t *, const wchar_t *, void *, _EXCEPTION_POINTERS *, MDRawAssertionInfo *, bool) callback_context, void * dump_type, _MINIDUMP_TYPE) Line 771	C++
xul.dll!CrashReporter::CreateMinidumpsAndPair(void * aTargetPid, unsigned long aTargetBlamedThread, const nsACString_internal & aIncomingPairName, nsIFile * aIncomingDumpToPair, nsIFile * * aMainDumpOut) Line 3924	C++
xul.dll!mozilla::dom::CrashReporterParent::GenerateCompleteMinidump<mozilla::dom::ContentParent>(mozilla::dom::ContentParent * t) Line 277	C++
xul.dll!mozilla::dom::ContentParent::KillHard(const char * aReason) Line 3184	C++
xul.dll!mozilla::dom::ContentParent::ProcessingError(mozilla::ipc::HasResultCodes::Result aCode, const char * aReason) Line 1695	C++
xul.dll!mozilla::ipc::MessageChannel::MaybeHandleError(mozilla::ipc::HasResultCodes::Result code, const IPC::Message & aMsg, const char * channelName) Line 2037	C++
xul.dll!mozilla::ipc::MessageChannel::DispatchMessageW(IPC::Message && aMsg) Line 1602	C++
xul.dll!mozilla::ipc::MessageChannel::OnMaybeDequeueOne() Line 1568	C++
...

Comment 2

[Trevor Saunders (:tbsaunde)]

(In reply to Ting-Yu Chou [:ting] from comment #1)
> (In reply to Ting-Yu Chou [:ting] from comment #0)
> > Based on the error message, it seems that RecvPDocAccessibleConstructor()
> > returns false, however the process type is content.
> 
> The process type is incorrect, checked the minidumps, the content process
> was waiting for the response from chrome process, but chrome process was
> creating minidumps with the stack:

ok, the PDocAccessibleConstructor part is a dup of bug 1270916

Comment 3

[Alice0775 White]

I can reproduce the crash on Nigtlr51.0a1 Windows10.

Reproducible: 50/50 probability

Steps to Reproduce:
1. Force enable e10s (My windows10 seems to be enabled accessibility)
2. Open https://www.youtube.com/ in the first tab
3. Click a thumbnail
   (or open https://www.youtube.com/watch?v=nOAUh6nvTiM in the same tab)
4. Move seek bar quickly, (repeat this step 3-5 times)
5. Click Back button on the NavBar while the video is busy

Actual Results:
Tab crashes :
  bp-c8c9f65f-e5f6-434c-a8f3-215972160811
  bp-ebbb9393-fbd8-4980-8de9-d1e122160811
Browser crashes :
  bp-49650991-2819-490d-b051-adbc22160811 --- Bug 1271645

Comment 4

[Alice0775 White]

bp-8d8b6cf3-c807-43bf-bd01-573fb2160814

Comment 5

[Matt Cosentino]

I get this crash on every visit to any eBay item page.

https://crash-stats.mozilla.com/report/index/ea9d3a3d-9042-441a-8de5-a96652160824

Comment 6

[Chris Peterson [:cpeterson]]

I hit this crash 5-10 times per day in Nightly 51. Since switching to Aurora 50 yesterday, I haven't hit it once. I'm using e10s on Windows 10, though I did have to use the browser.tabs.remote.force-enable = true pref to force-enable e10s because Firefox refused to enable e10s by default because it detected a Windows accessible feature in use (I don't know which; maybe touchscreen?).

Comment 7

[Matt Cosentino]

Ahh, I also had browser.tabs.remote.force-enable set to true, because of my touchscreen. I reset that preference, restarted Firefox, and now I don't get the crash anymore.

Comment 8

[Matt Cosentino]

I can have browser.tabs.remote.force-enable set to true if I have accessibility.force_disabled set to 1.

Comment 10

[Alice0775 White]

probably Bug 1270916