Crash in [@ @0x0 | wbload.dll | round]
Categories
(Core :: Graphics: WebRender, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox67 | --- | wontfix |
firefox68 | --- | fixed |
People
(Reporter: kats, Assigned: kats)
References
(Blocks 1 open bug)
Details
(Keywords: crash, regression)
Crash Data
Attachments
(1 file)
This bug is for crash report bp-836229e9-b264-4c20-8007-84a3a0190415.
Top 10 frames of crashing thread:
0 @0x0
1 wbload.dll wbload.dll@0x10bf5
2 xul.dll round
3 xul.dll round
4 xul.dll round
5 xul.dll round
6 d3d11.dll CSampler::GetDesc
7 d3d11.dll CDevice::CreateQuery_Worker
8 @0xffffffff
9 mozglue.dll void* arena_t::MallocSmall memory/build/mozjemalloc.cpp:2776
It seems like with WR enabled we are getting quite a few crashes with this wbload.dll thing, which is part of WindowBlinds. I'm assuming that when this crash happens we just disable the GPU process (and WR) and go back to basic, so it's not the end of the world, but it would be nice if we could either fix it on our side, or suggest something to Stardock to fix it on their end.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
Thanks, I had forgotten about that bug. Per the discussion in bug 1477447 comment 12 onwards, it looks like the crash is basically the same as was happening back then, and we do end up disabling the GPU process after four crashes and falling back to Basic. The fallback seems to work well so that's good. Also good is that since each startup will generate four crash reports we should be able to ignore 75% of these crash reports which makes the effective volume much lower.
But we should still track this and maybe try to come up with some way to fix it.
Comment 2•5 years ago
|
||
This is the top non-hang Windows crash for the 4/24 Nightlies.
Comment 3•5 years ago
|
||
Maybe Aaron has some ideas on what could be the next step here?
Comment 4•5 years ago
|
||
I actually thought we blocked wbload.dll from loading. Maybe we could just do that?
Assignee | ||
Comment 5•5 years ago
|
||
It's not listed in mozglue/build/WindowsDllBlocklistDefs.h
which appears to be the DLL blocklist. I can add it although I have no idea what I'm doing :)
Assignee | ||
Comment 6•5 years ago
|
||
Pushed by kgupta@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6d4fe74b51ca Block wbload.dll as it causes GPU process crashes. r=aklotz
Comment 8•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Updated•5 years ago
|
Comment 9•5 years ago
•
|
||
Firefox 67: Only 1 user with 48 crashes; multiple crash signatures. (WR "topcrash")
https://crash-stats.mozilla.org/search/?app_notes=~WR%2B&signature=~wbload&product=Firefox&version=67.0&platform=Windows&process_type=gpu&date=%3E%3D2019-05-23T19%3A29%3A00.000Z&date=%3C2019-05-30T19%3A29%3A00.000Z&_facets=signature&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 12•5 years ago
|
||
P3, low level of crashes, wontfix for 67.
Updated•5 years ago
|
Updated•5 years ago
|
Updated•4 years ago
|
Description
•