Closed Bug 1376177 Opened 7 years ago Closed 5 years ago

Crash in nvd3d9wrapx.dll@0x28bb

Categories

(Core :: Gecko Profiler, defect, P3)

Unspecified
Windows 7
defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: jseward, Unassigned)

References

Details

(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-b50d4d00-6ba8-4b56-8787-f6be00170624.
=============================================================

This is topcrash #5 in the Windows nightlies of 20170622030208.
Looks like it is profiler or, really, hang-detector, related.
Flags: needinfo?(mstange)
Hello NVidia drivers, my old friends...
No progress on this bug yet? I have been crashing since firefox 54 I believe, and am still crashing on Firefox 56 beta.

Just a CTD with no crash report or error message generated.

Event viewer shows event ID 1000 application error :

Faulting application name: firefox.exe, version: 56.0.0.6436, time stamp: 0x59931079
Faulting module name: nvd3d9wrapx.dll, version: 22.21.13.8528, time stamp: 0x598b835f
Exception code: 0xc0000005
Fault offset: 0x00000000000028bb
Faulting process id: 0xbb0
Faulting application start time: 0x01d317be057ea3a9
Faulting application path: C:\Program Files\Mozilla Firefox\firefox.exe
Faulting module path: C:\Program Files\NVIDIA Corporation\CoProcManager\nvd3d9wrapx.dll
Report Id: 57413e6d-83b9-11e7-8296-7c11be384500

Firefox managed to generate a few crash reports when it started happening again but it has since stopped generating crash reports, so im not sure if its the same issue.

https://crash-stats.mozilla.com/report/index/bp-d3714b5f-2c9e-4c63-a98d-bd5740170817

According to jya in the firefox IRC channel, firefox hangs and then it crashes when the profiler is trying to retrieve my system information or something like that, but there is no way to stop it from retrieving my system information to prevent the crash.

Disabling auto send technical data in options didnt stop the crash, and turning it back on doesnt cause it to generate any more crash reports.
Priority: -- → P3
#3 top crash on the 9-20 Nightly, with 356 crashes from 6 installations.
Is there still no progress on this? What's going on? I've been stuck on ESR for months because the newer firefox versions just keep crashing without generating any crash reports.
Is it possible to add a blacklist so we can skip collecting info from nvd3d9wrapx.dll?
Crash Signature: [@ nvd3d9wrapx.dll@0x28bb] → [@ nvd3d9wrapx.dll@0x28bb] [@ nvd3d9wrap.dll@0xcf0d ]
Flags: needinfo?(michael)
(In reply to Kan-Ru Chen [:kanru] (UTC+8) from comment #5)
> Is it possible to add a blacklist so we can skip collecting info from
> nvd3d9wrapx.dll?

When this crash is happening we aren't collecting hang information from a specific DLL, rather we're trying to process the hang information we had previously collected. In order for us to get native stack information for a stack frame we need the offset in memory of the DLLs which are currently loaded, so we can transform addresses into module offset information, and this crash is occurring in profiler code which is requesting this information.

Theoretically if you have extended telemetry disabled, this could should never run, even in nightly. In addition, this code should be disabled via a compile time flag outside of nightly. If this problem also reproduces in devedition 57, then I definitely want to see a stack from it.

(In reply to Anonymous from comment #4)
> Is there still no progress on this? What's going on? I've been stuck on ESR
> for months because the newer firefox versions just keep crashing without
> generating any crash reports.

This code shouldn't run anywhere outside of nightly - it's disabled at compile time in beta and release builds. Are you also running into crashes there?
Flags: needinfo?(michael) → needinfo?(question2005)
(In reply to :Nika Layzell from comment #6)
> (In reply to Kan-Ru Chen [:kanru] (UTC+8) from comment #5)
> > Is it possible to add a blacklist so we can skip collecting info from
> > nvd3d9wrapx.dll?
> 
> When this crash is happening we aren't collecting hang information from a
> specific DLL, rather we're trying to process the hang information we had
> previously collected. In order for us to get native stack information for a
> stack frame we need the offset in memory of the DLLs which are currently
> loaded, so we can transform addresses into module offset information, and
> this crash is occurring in profiler code which is requesting this
> information.
> 
> Theoretically if you have extended telemetry disabled, this could should
> never run, even in nightly. In addition, this code should be disabled via a
> compile time flag outside of nightly. If this problem also reproduces in
> devedition 57, then I definitely want to see a stack from it.
> 
> (In reply to Anonymous from comment #4)
> > Is there still no progress on this? What's going on? I've been stuck on ESR
> > for months because the newer firefox versions just keep crashing without
> > generating any crash reports.
> 
> This code shouldn't run anywhere outside of nightly - it's disabled at
> compile time in beta and release builds. Are you also running into crashes
> there?

I was not using nightly.

Im not even sure what is causing the problem exactly, but this is happening since I upgraded to ESR 52.8. I am now getting constant CTDs almost every time i try to restore a session. No crash reporter either.

And everytime firefox crashes, there is a leftover firefox.exe process in process list. It looks like the newest ESR does some kind of multiple processes thing.

Either way, almost every time i try to restore a session, it just CTDs, no crash reporter, nothing in about:crashes. Event viewer shows :

Faulting application name: firefox.exe, version: 52.8.0.6694, time stamp: 0x5ae794d3
Faulting module name: mozglue.dll, version: 52.8.0.6694, time stamp: 0x5ae794c2
Exception code: 0x80000003
Fault offset: 0x00000000000114f5
Faulting process id: 0x1c18
Faulting application start time: 0x01d3f521d9e2268b
Faulting application path: C:\Program Files\Mozilla Firefox\firefox.exe
Faulting module path: C:\Program Files\Mozilla Firefox\mozglue.dll
Report Id: 3428a52a-6115-11e8-a9fb-ee00c9a14a11

Faulting application name: firefox.exe, version: 52.8.0.6694, time stamp: 0x5ae794d3
Faulting module name: nvd3d9wrapx.dll, version: 23.21.13.9135, time stamp: 0x5ab5816f
Exception code: 0xc0000005
Fault offset: 0x00000000000028bb
Faulting process id: 0x1ce8
Faulting application start time: 0x01d3f521ba9f86ae
Faulting application path: C:\Program Files\Mozilla Firefox\firefox.exe
Faulting module path: C:\Program Files\NVIDIA Corporation\CoProcManager\nvd3d9wrapx.dll
Report Id: 340b0a9b-6115-11e8-a9fb-ee00c9a14a11

I dont even know why its flagging nvd3d9wrapx.dll because I know that firefox is forced to use integrated graphis on my machine due to optimus. The last time, i spent ages trying to find a solution and people on IRC just blamed Nvidia for forcing firefox to use the integrated card and Nvidia tech support reps just said they didn't do anything like that, and nobody seemed to have any idea what was causing it.

I can restore the session, but only the first few tabs it seems. The weirdest part is that in the afternoon, i restored the first few tabs, worked for a few hours, then tried loading all the tabs again...and despite not doing anything different, this time, it loaded with no crash...everything was fine for a few hours, then i restarted the browser and now its crashing every time i try to load the session...

I am already using the latest drivers, etc. This didnt happen in ESR 52.7. Is there a way to downgrade to it?
Flags: needinfo?(question2005)
Flags: needinfo?(nika)
I dont know if its related but I was trying a bunch of things and reset browser.display.use_document_fonts to 1 and i was able to restore the session (I had set it to 0 before).
It looks like setting browser.display.use_document_fonts to 0 causes firefox to crash to desktop (CTD) when trying to load sessions for some web pages, which is odd because when browser.display.use_document_fonts is set to 0, Firefox uses the font set in preferences instead. I had it set to Verdana, font size 17 or 18.
this looks like it might be graphics related? david can you take a look?
Flags: needinfo?(nika) → needinfo?(dbolter)
Fonts and gfx makes me think of Lee. Can you take a look/triage?

Note we had a bunch of crashes back in late January but this sig hasn't been showing up in crash-stats much at all since (so far).
Flags: needinfo?(dbolter) → needinfo?(lsalzman)
What crash stacks we have don't say much that would implicate text specifically as the problem. Given the circumstantial evidence, text seems like it might only be coincidentally involved here.

To elaborate, the stack first runs into the background hang monitor, which calls into some utility code that happens to be living in the profiler directory to get library versions. This in turn goes through a black hole in and somehow punts back into mozjemalloc, possibly freeing or reallocing memory. From there we take a ride through another black hole into d3d9wrapx.dll land. And all I've got is guesses as to how it gets there from mozjemalloc, either intercepting some syscall we're doing or through some kind of fault.

Only other bug we have on file to give us clues right now seems to be bug 1240848.

So, on my end, not too many ideas, unless maybe Jonathan has seen anything like this before?
Flags: needinfo?(lsalzman) → needinfo?(jfkthame)
See Also: → 1240848
Oops, I meant bug 1241921
See Also: 12408481241921
No, I don't have anything to add here, except that like Lee, I kinda suspect the fonts thing may be a red herring.
Flags: needinfo?(jfkthame)

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
See Also: → 1607574
Flags: needinfo?(mstange.moz)
You need to log in before you can comment on or make changes to this bug.