PDF pages are failing to load

[Genki-jp0]

Describe the bug
When you go open pdf files from the internet, they just don't load,
it is worth noting that not all PDF files do not load, infact some do load fine

For example:

failed to load:
https://www.opencompute.org/files/Intels-Journey-w-OpenBMCJamesMihm-OCP18.pdf
https://indico.cern.ch/event/1411901/contributions/6017914/attachments/2919965/5124988/Puneet-ATCF8-TIFR-SR.pdf
https://indico.cern.ch/event/1329196/contributions/5677619/attachments/2755346/4797476/KolkataTier2_JammuAliceIndiaCollaborationMeeting231123.pdf
https://indico.cern.ch/event/1345690/contributions/5665082/attachments/2749029/4784321/7thATCFUpdate.pdf

loaded:
https://indico.cern.ch/event/1386015/contributions/5826817/attachments/2805855/4895984/Kolkata%20Tier2%20Centre-February-2024.pdf
https://indico.cern.ch/event/1322307/contributions/5564713/attachments/2709617/4704804/GridUpdateSeptember2023.pdf
https://indico.cern.ch/event/1322307/contributions/5564715/attachments/2709940/4705389/Puneet-DPM-dCacheMigration.pdf

To Reproduce
Steps to reproduce the behavior:

1. Go to said pdf
2. See error

Expected behavior
PDF Pages loading successfully

Screenshots

Desktop (please complete the following information):

• OS: Windows 7 Ultimate x64 with ESU 2024
• x64

Additional Context
This started happening after updating from a older supermium version to the latest, Version 126.0.6478.249 (Official Build) (64-bit)

[zap369]

Just letting you know that I'm on Supermium 126.0.6478.249 R3-32bit with winXP SP3 and all the PDFs above are loading correctly on my end.

[XakerTwo]

Win 7 SP1 x64 (ESU 2024.09)
Supermium 126.0.6478.249 R3 x64

all PDFs successfully loaded and displayed, even with actively leaking extension and lots of DevTools (also leaking and consuming cpu)

[Genki-jp0]

made a completely new profile in supermium with no extensions at all, experiencing the same issue

[Genki-jp0]

i was running 124.0.6367.245 previously

[Genki-jp0]

went back to 124.0.6367.245, every pdf loads fine now with the exact same settings and profile

[Genki-jp0]

Did some further testing:

124.0.6367.245 - loads all pdfs
124.0.6367.245 R2 - loads all pdfs
126.0.6478.249 - fails to load pdfs
126.0.6478.249 R2 - fails to load pdfs
126.0.6478.249 R3 - fails to load pdfs

All were tested with a completely new User Data folder.

https://www.opencompute.org/files/Intels-Journey-w-OpenBMCJamesMihm-OCP18.pdf

[jimjonesbased69]

Can confirm that on my end, using Windows 7 (x64), some PDF's (such as the ones listed in this issue) are not properly loading.

[Vangelis66]

126.0.6478.249 - fails to load pdfs
126.0.6478.249 R2 - fails to load pdfs
126.0.6478.249 R3 - fails to load pdfs
(...)
https://www.opencompute.org/files/Intels-Journey-w-OpenBMCJamesMihm-OCP18.pdf

Windows Vista SP2 32-bit 3GB RAM
Sm-126-r3_x86 (DWrite.dll working as intended)

No problem here 😄 :

[Genki-jp0]

126.0.6478.249 Prerelease has the exact same issue as all the releases after it, the only difference is that a memory error shows up in the prerelease with the PDF failing to load.
Tested with a fresh User Data folder with default settings, no extensions

[win32ss]

This is a DirectWrite issue. I'm going to make some changes to DirectWrite's internal exception handling to catch DirectWrite-specific errors better, as they are difficult to catch in the auxiliary processes.

But I also noticed that the crash is caused by an attempt to access a null pointer... which was set to 0 by the caller! This is deep into pdfium.

Or maybe not. But only one iteration after the patch was made, it stopped crashing on the particular PDF regardless of the presence of the patch, which seemed to have no effect. Although the root of the issue is that there is an issue with the "fallback" fonts used by pdfium.

UPDATE: this newer iteration of the crash has also been reproduced with other renderers.

[win32ss]

The fallback font used by the PDF font renderer is Arial. If it's changed to Segoe UI the crashes disappear, but I will probably change to Times New Roman or Tahoma to maintain XP compatibility.

Arial Unicode MS, the "Universal Default Font Name" in pdfium, also seems to work.

[Vangelis66]

... IIUC, changes in pdfium between Sm-v124 and 126 are believed to be "the trigger" of this bug; what I don't get is how this bug ONLY affects specific setups (and PDF files); i.e., we have XP SP3 32-bit, Vista SP2 32-bit and Win7 SP1 64-bit (with Sm_x64) where the bug doesn't manifest itself, at the same time Win7 SP1 64-bit (with Sm_x64) where the bug is present... A mystery for the uninitiated such as I 😄 ...

[XakerTwo]

can i assume a specific Windows locale(language)? if so - probably it's somehow related cuz for certain locales Windows has uniq font substitutions, see C:\Windows\inf\fontsetup.inf for some info (it's not so easy to read, but it has comments)

for me display language and non-unicode locale is en-US, but non-unicode locale not affect font substitution(if i'm correct) and for the moment i have no other languages installed

btw - does renaming DWrite.dll to something like _DWrite.dll solve the issue? if so it can be used as temporary workaround

[Genki-jp0]

For me, it is also en-US for both display and non-unicode, im running w7 SP1 x64 with ESU 2024.09 (7601.win7sp1_ldr_escrow.240814-1814).

[Genki-jp0]

Renaming DWrite.dll to anything or removing it does not solve the issue.

[XakerTwo]

iso MD5 is B86A374B412917C704F7AB86059B7D22?
if so - put this in google site:archive.org C9F7ECB768ACB82DAACF5030E14B271E, use VM to check the issue

UPD: Win XP SP2 x64; Supermium 126.0.6478.249 R3 x64 - no issues

[win32ss]

Looking at the first linked PDF in this issue, the text on the second slide is affected, as it uses the selected fallback font.

There was an iteration of the bug that triggered exceptions in DirectWrite, but the DirectWrite issue was later fixed (it was linked to the issue with Latin characters in Chinese fonts), and the issues persist even with system DirectWrite and GDI.