Closed Bug 1067348 Opened 7 years ago Closed 7 years ago

content process crash in mozilla::OffTheBooksMutex::Lock() during crash reporting

Categories

(Toolkit :: Crash Reporting, defect)

x86
Windows NT
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME
Tracking Status
e10s - ---

People

(Reporter: kairo, Assigned: billm)

References

Details

(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-6a666660-4396-41c8-bda6-6788f2140915.
=============================================================

Top frames:
0 	xul.dll 	mozilla::OffTheBooksMutex::Lock() 	xpcom/glue/Mutex.h
1 	xul.dll 	mozilla::BaseAutoLock<mozilla::Mutex>::BaseAutoLock<mozilla::Mutex>(mozilla::Mutex&) 	xpcom/glue/Mutex.h
2 	xul.dll 	CrashReporter::OnChildProcessDumpRequested 	toolkit/crashreporter/nsExceptionHandler.cpp
3 	xul.dll 	google_breakpad::CrashGenerationServer::HandleDumpRequest(google_breakpad::ClientInfo const&) 	toolkit/crashreporter/google-breakpad/src/client/windows/crash_generation/crash_generation_server.cc
4 	xul.dll 	google_breakpad::CrashGenerationServer::OnDumpRequest(void*, unsigned char) 	toolkit/crashreporter/google-breakpad/src/client/windows/crash_generation/crash_generation_server.cc


This started appearing in nightly 35 with the 20140911064110 build, so the regression should have been on 9/10.

For stats and more reports, see https://crash-stats.mozilla.com/report/list?signature=mozilla%3A%3AOffTheBooksMutex%3A%3ALock%28%29
This is the first build after bug 1064885 so I guess any regression range I can get will point to this as the cause and this is an e10s regression.
Note that those are crashes in content processes
Summary: Nightly crash in mozilla::OffTheBooksMutex::Lock() during crash reporting → content process crash in mozilla::OffTheBooksMutex::Lock() during crash reporting
Related: bug 1050210, bug 820716 comment 65, bug 820716 comment 71, bug 641685. The main problem here is that we have nested child processes (plugin processes as children of content processes) and we don't set crash reporting up to handle that properly. bug 641685 is going to make us stop doing that, but in the meantime we should probably just hack around that so we don't put ourselves in that broken scenario.
Happened for me once today as I was testing various settings on these preferences in about:config:
-gfx.direct2d.disabled
-layers.offmainthreadcomposition.enabled
-layers.prefer-opengl
-layers.prefer-d3d9
for bug #1064864

https://crash-stats.mozilla.com/report/index/f509591c-3a89-4928-9c4b-0500b2140929
I crashed with this signature after disabling e10s in the Nightly options before restarting to apply
Blocks: 899758
tracking-e10s: --- → ?
Assignee: nobody → wmccloskey
Depends on: e10s-plugin-ipc
In bug 1081686, the reporter posted a link which crashes FF with this signature.
STR:

1) Go to http://en.lichess.org/
2) Click `Play with the machine' (or any other means of playing a chess game)
3) Start the game
Blocks: 1081686
I didn't detect any behavior which would trigger this. Happens even when I'm not doing anything in the browser.
e10s-m3 is long over - re-nomming.
This doesn't seem to be happening anymore in 37.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.