Crash in [@ cupsGetDestMediaDefault] (CUPS threadsafety issue?)
Categories
(Core :: Print Preview, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox-esr78 | --- | unaffected |
firefox80 | --- | unaffected |
firefox81 | --- | disabled |
firefox82 | --- | verified |
People
(Reporter: emilghitta, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: crash, regression, Whiteboard: [print2020_v82] [old-ui-] [Fixed by 1661157])
Crash Data
Crash report: https://crash-stats.mozilla.org/report/index/b9cea16e-7141-435e-a3bd-c13d50200907
Top 10 frames of crashing thread:
0 libcups.2.dylib cupsGetDestMediaDefault
1 libcups.2.dylib cupsArrayDup
2 libcups.2.dylib cupsArrayFind
3 libcups.2.dylib cupsGetDestMediaByName
4 libcups.2.dylib cupsGetDestMediaDefault
5 XUL nsPrinterCUPS::DefaultSettings const widget/nsPrinterCUPS.cpp:45
6 XUL void mozilla::SpawnPrintBackgroundTask<nsPrinterBase, mozilla::PrintSettingsInitializer, > const widget/PrintBackgroundTask.h:53
7 XUL mozilla::detail::RunnableFunction<void mozilla::SpawnPrintBackgroundTask<nsPrinterBase, mozilla::PrintSettingsInitializer, > xpcom/threads/nsThreadUtils.h:577
8 XUL nsThreadPool::Run xpcom/threads/nsThreadPool.cpp:299
9 XUL nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1234
Reproduced this crash on Beta 7 & latest nightly + the build from https://bugzilla.mozilla.org/show_bug.cgi?id=1663140#c13
Encountered this crash while opening the print option from a pdf document (pdf.js). At first I've encountered this crash pretty fast (just clicking the print option for this document) but I've noted that after encountering this crash for several times..I had to spam opening and closing the print preview in order to reproduce again.
Reporter | ||
Comment 1•4 years ago
|
||
Leaving a ni? on myself to further investigate
Comment 2•4 years ago
|
||
ni? to Emily and Emilio for thoughts.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 3•4 years ago
|
||
There are other cups operations going on in other threads. Looking a bit at the CUPS source, it mutates the cups_dinfo_t*
(mPrinterInfo
) without synchronization. I'm moderately sure that that's the underlying issue and we're going to need to serialize the CUPS calls for a given printer on the same thread somehow.
Emily, does that sound plausible to you? I can take this if you want, we have talked of doing this anyhow because getting the cups_dinfo_t*
is the expensive thing anyhow.
Updated•4 years ago
|
Comment 4•4 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)
There are other cups operations going on in other threads. Looking a bit at the CUPS source, it mutates the
cups_dinfo_t*
(mPrinterInfo
) without synchronization. I'm moderately sure that that's the underlying issue and we're going to need to serialize the CUPS calls for a given printer on the same thread somehow.
Ugh.
I abandoned an earlier implementation of the patch for bug 1656146 in which I used NS_CreateBackgroundTaskQueue and nsISerialEventTarget.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 5•4 years ago
|
||
This isn't really too bad (from an architecture perspective) if the issue really is thread-safety in the cups_dinfo_t, since a part of our tentative solution for bug 1661157 would necessarily make the cups_dinfo_t thread-safe as well. Hopefully making that change will clear up this crash as well.
Updated•4 years ago
|
Comment 6•4 years ago
|
||
This should be resolved as part of the fix from bug 1661157. Emil: Can you verify as part of your next test run?
Reporter | ||
Comment 7•4 years ago
|
||
I am unable to reproduce this crash using Firefox 82.0a1 (BuildId:20200911093056) on macOS 10.14
Reporter | ||
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 8•4 years ago
|
||
Updated•4 years ago
|
Description
•