1667405 - Crash in [@ nsPrinterWin::DefaultSettings], due to failure of MOZ_DIAGNOSTIC_ASSERT(printerDc, "CreateICW failed");

Status: RESOLVED FIXED

(Core :: Printing: Setup, defect, P2)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

First crash was with 82.0a1 20200915092930, this report is for the latest 83.0a1 Nightly.

Crash report: https://crash-stats.mozilla.org/report/index/3d024893-885f-4f5d-94a4-f7cb20200925

Top 10 frames of crashing thread:

0 xul.dll nsPrinterWin::DefaultSettings const widget/windows/nsPrinterWin.cpp:102
1 xul.dll static std::_C__Invoker_functor::_Call<`lambda at /builds/worker/checkouts/gecko/widget/PrintBackgroundTask.h:54:17'> 
2 xul.dll mozilla::SpawnPrintBackgroundTask<nsPrinterBase, mozilla::PrintSettingsInitializer>::<unnamed-tag>::operator const widget/PrintBackgroundTask.h:53
3 xul.dll mozilla::detail::RunnableFunction<`lambda at /builds/worker/checkouts/gecko/widget/PrintBackgroundTask.h:48:11'>::Run xpcom/threads/nsThreadUtils.h:577
4 xul.dll nsThreadPool::Run xpcom/threads/nsThreadPool.cpp:299
5 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1234
6 xul.dll mozilla::ipc::MessagePumpForNonMainThreads::Run ipc/glue/MessagePump.cpp:332
7 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:327
8 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:309
9 xul.dll static nsThread::ThreadFunc xpcom/threads/nsThread.cpp:442

Comment 1

[Daniel Holbert [:dholbert]]

This crash report is from the following MOZ_DIAGNOSTIC_ASSERT failing:

  MOZ_DIAGNOSTIC_ASSERT(printerDc, "CreateICW failed");

Source link:
https://hg.mozilla.org/mozilla-central/file/8734082cd6de033539bb6c5e24709bc9647b5b1a/widget/windows/nsPrinterWin.cpp#l102

bobowen, looks like you've been poking around in this code recently - mind taking a look? (Maybe this is the answer to your question in bug 1663494 comment 2?)

Comment 2

[Bob Owen (:bobowen)]

I was thinking that maybe bug 1664981 might have fixed this (it is in b4), but we've had one in Nightly since that landed.

I'll try and take a look at the crash reports, but I agree if this is just an unexplained system API failure then we probably shouldn't keep the diagnostic assert.

jwatt: do you think we should move this sort of failure to telemetry to at least track the numbers on release?
perhaps we already have good enough higher level tracking of failures ... or we should put something in at a higher level?

Comment 3

[Bob Owen (:bobowen)]

This assert is removed by the patch in bug 1667952.

Comment 4

[Sean Voisen (:svoisen)]

Per comment 3, with bug 1667952 landed and soon-to-be-uplifted to 82 beta, I think we can close this.

Comment 5

[Jonathan Watt [:jwatt]]

(In reply to Bob Owen (:bobowen) from comment #3)

This assert is removed by the patch in bug 1667952.

Which has now been uplifted to beta.