See testcase, which crashes current trunk build when trying to print. This regressed when the frame display lists patch landed (bug 317375). Marking as security sensitivie, just in case, although it looks like a normal crash to me. http://crash-stats.mozilla.com/report/index/aaaf256b-512f-11dd-836f-001cc45a2ce4?p=1 Frame Module Signature [Expand] Source 0 xul.dll nsPrintEngine::DoPrint layout/printing/nsPrintEngine.cpp:2131 1 xul.dll nsPrintEngine::PrintDocContent layout/printing/nsPrintEngine.cpp:2085 2 xul.dll nsPrintEngine::PrintDocContent layout/printing/nsPrintEngine.cpp:2094 3 xul.dll nsPrintEngine::DonePrintingPages layout/printing/nsPrintEngine.cpp:2727 4 xul.dll nsPagePrintTimer::Notify layout/printing/nsPagePrintTimer.cpp:93 5 xul.dll nsTimerImpl::Fire xpcom/threads/nsTimerImpl.cpp:403 6 xul.dll nsTimerEvent::Run xpcom/threads/nsTimerImpl.cpp:490 7 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:510 8 nspr4.dll PR_GetEnv
Since this is a null deref (backtrace attached) I'm going to set to sg:nse.
Ok, is adding null check then sufficient here?
Attachment #355858 - Flags: review?(bzbarsky)
Attachment #355858 - Flags: review?(bzbarsky) → review?(roc)
Comment on attachment 355858 [details] [diff] [review] patch? roc might be a better reviewer here (e.g. might know why this is null and whether it should be).
I'm afraid I don't know, not without debugging it myself. I'm afraid that this patch might just paper over some bigger bug. Since it's a null-pointer exception on a synthetic testcase (I presume?), I think we're better off not fixing it until someone reworks this code or has time to debug it.
Crash Signature: [@ nsPrintEngine::DoPrint]
WFM, Nightly on Linux64. Martijn, can you still reproduce this crash?
Yes, seems to work in current trunk build.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.