Open Bug 1898746 Opened 1 year ago Updated 1 year ago

Trying to upload/attach PDF crashes Firefox/Thunderbird - Crash in [@ TppCallbackCheckThreadAfterCallback]

Categories

(External Software Affecting Firefox :: Other, defect)

Firefox 126
Unspecified
Windows 11
defect

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: galimbertimichele, Assigned: gstoll)

References

Details

Crash Data

Attachments

(1 file)

Attached file Crash-causing PDF

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
Attachment #9403773 - Attachment description: This PDF causes the crash → Crash-causing PDF

As an additional information, the file was made by exporting a canva.com template to PDF, with default settings

Component: Networking: File → Other
Product: Core → External Software Affecting Firefox

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.

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...

Crash Signature: TppCallbackCheckThreadAfterCallback
Crash Signature: TppCallbackCheckThreadAfterCallback → @ TppCallbackCheckThreadAfterCallback
Crash Signature: @ TppCallbackCheckThreadAfterCallback → [@ TppCallbackCheckThreadAfterCallback]
Severity: -- → S3

The bug has a crash signature, thus the bug will be considered confirmed.

Status: UNCONFIRMED → NEW
Ever confirmed: true

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.

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!

Flags: needinfo?(galimbertimichele)

Will do and report back. Sadly for whatever reason Firefox is not crashing right now, without me having disabled anything yet.

:|

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

Flags: needinfo?(galimbertimichele)

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)

Flags: needinfo?(galimbertimichele)

(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_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)

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

Flags: needinfo?(galimbertimichele)

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.

Assignee: nobody → gstoll
Status: NEW → ASSIGNED
Depends on: 1883943

That's perfect, I'll update the thread if I have anything new to report. Thanks for helping me navigate this problem!

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: