Trying to upload/attach PDF crashes Firefox/Thunderbird - Crash in [@ TppCallbackCheckThreadAfterCallback]
Categories
(External Software Affecting Firefox :: Other, defect)
Tracking
(Not tracked)
People
(Reporter: galimbertimichele, Assigned: gstoll)
References
Details
Crash Data
Attachments
(1 file)
|
171.57 KB,
application/pdf
|
Details |
Trying to upload a particular PDF on any webpage crashes Firefox. I tested this on three websites, including this Bugzilla instance. This happens in 50% or more of my tries, but I couldn't find any regularity.
I also replicated this issue in Thunderbird 115, trying to attach the same file.
Crash report: https://crash-stats.mozilla.org/report/index/cb8b7ffb-98f8-48e8-b89c-7f38c0240524
Reason: STATUS_CALLBACK_RETURNED_LANG
Top 7 frames:
0 ntdll.dll TppCallbackCheckThreadAfterCallback
1 ntdll.dll TppCallbackEpilog
2 ntdll.dll TppWorkerThread
3 kernel32.dll BaseThreadInitThunk
4 mozglue.dll mozilla::interceptor::FuncHook<mozilla::interceptor::WindowsDllInterceptor<mo... toolkit/xre/dllservices/mozglue/nsWindowsDllInterceptor.h:150
4 mozglue.dll patched_BaseThreadInitThunk(int, void*, void*) toolkit/xre/dllservices/mozglue/WindowsDllBlocklist.cpp:562
5 ntdll.dll RtlUserThreadStart
| Reporter | ||
Updated•1 year ago
|
| Reporter | ||
Comment 1•1 year ago
|
||
As an additional information, the file was made by exporting a canva.com template to PDF, with default settings
Updated•1 year ago
|
| Reporter | ||
Comment 2•1 year ago
|
||
Some more info:
- No crash in Firefox for Android (latest version)
- Microsoft Edge doen't crash but seems to hang the webpage, with a similar frequency to the Firefox crashes. Only the tab used for uploading the PDF hangs.
| Assignee | ||
Comment 3•1 year ago
|
||
Previous reports of crashes like this: bug 1444019, bug 1360029.
I suspect a third-party DLL is causing these - let me see if I can query the existing reports to see what DLLs are in common...
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
Comment 4•1 year ago
|
||
The bug has a crash signature, thus the bug will be considered confirmed.
| Reporter | ||
Comment 5•1 year ago
|
||
I have an update on this: I assumed the problem was related to that specific PDF but it seems I was mistaken. Trying today to upload a simple JPEG file failed and crashed Firefox, so I probably mixed up the origin due to some concomitant software/driver installation or system update. Also, this doesn't happen on another Win11 PC with the latest version of Firefox.
The only additional info that comes to mind is that my GPU is an Nvidia GTX 970 (with updated stable drivers), but that was probably already known from the crash dump.
| Reporter | ||
Comment 6•1 year ago
|
||
Most recent crash report (with JPEG): https://crash-stats.mozilla.org/report/index/04f07d88-3716-46ac-b4bd-e54190240604
| Assignee | ||
Comment 7•1 year ago
|
||
Thanks for the update!
Looking at your crash reports, my guess is one of the third-party DLLs loaded into Firefox is causing this crash. Unfortunately it's hard to tell from the crash report which one it is.
If you have a reliable way to reproduce this, do you think you could try disabling the third-party DLLs and seeing if the crash still happens? There are instructions here - note that after blocking the DLLs you will have to restart Firefox to make the blocking take effect.
If that stops the crash from happening we can go back and disable one at a time to narrow down which module is causing the crash.
Thanks!
| Reporter | ||
Comment 8•1 year ago
|
||
Will do and report back. Sadly for whatever reason Firefox is not crashing right now, without me having disabled anything yet.
:|
| Reporter | ||
Comment 9•1 year ago
|
||
After managing to replicate the crashes without making any modification yet, I disabled all third-party DLLs and began my tests.
The results were a bit baffling:
- At first, trying to attach an image file in Gmail caused Firefox to hang without closing (not to crash as before), and a force close was the only way out. No prompt to send the crash report appeared. This was replicated 3-4 times.
- I then left FF open for, say, 30 seconds and made another try. This time the old-style crashes reappeared.
- After 2 or 3 such crashes, I randomly opened the file chooser from Gmail and closed it again: this was enough to crash Firefox
All these tests were made with all third-party DLLs disabled. From my observations, it seems that Firefox crashing is highly variable depending on some external condition, but it is not clear what it is or why it varies in its behavior. My main suspect is Windows Explorer.
As far as modifications that I made, I use Mega for file sync and I have a Veracrypt volume mounted, but I got by for years without any problems. I remain available for any additional info needed
| Assignee | ||
Comment 10•1 year ago
|
||
Huh, that is confusing.
One more thing to try - can you unblock all the third-party DLLs, and then set the preference widget.windows.utility_process_file_picker to 1? After restarting Firefox, does the crash happen anymore?
(setting this preference makes the file picker run out of process, per bug 1677170, and may help)
| Reporter | ||
Comment 11•1 year ago
|
||
(In reply to Greg Stoll :gstoll from comment #10)
Huh, that is confusing.
One more thing to try - can you unblock all the third-party DLLs, and then set the preference
widget.windows.utility_process_file_pickerto 1? After restarting Firefox, does the crash happen anymore?(setting this preference makes the file picker run out of process, per bug 1677170, and may help)
Well, that definitely made a difference! I made some tries (not a lot), and the crashes seem to have disappeared. Also, I felt a general better responsiveness, but I may have imagined it. Apologies for the delay, but I couldn't replicate the crashes for some time, there may be some file caching done by Firefox that bypasses the chooser, and that might explain the "randomness" of the crashing.
In any case, widget.windows.utility_process_file_picker set to 1 seems to eliminate the crashes
| Assignee | ||
Comment 12•1 year ago
|
||
That's great to hear! We're planning making the value of 1 the default in the not too distant future, so I made this bug depend on that one.
| Reporter | ||
Comment 13•1 year ago
|
||
That's perfect, I'll update the thread if I have anything new to report. Thanks for helping me navigate this problem!
Description
•