Crash of _imagingft.cp39-win_amd64.pyd under Windows 10

[pakal]

When I install recent Pillow versions on Windows 10, under both python3.8 or 3.9, it crashes brutally when loading ImageDraw.py

No information except in Windows logs, e.g. for Python3.9:

Nom de l’application défaillante python.exe, version : 3.9.1150.1013, horodatage : 0x5fce62a8
Nom du module défaillant : _imagingft.cp39-win_amd64.pyd, version : 0.0.0.0, horodatage : 0x6283b299
Code d’exception : 0xc0000005
Décalage d’erreur : 0x000000000010687a
ID du processus défaillant : 0x5c20
Heure de début de l’application défaillante : 0x01d88228c040f35f
Chemin d’accès de l’application défaillante : p:\workspace\.virtualenvs\pychronia39\scripts\python.exe
Chemin d’accès du module défaillant: p:\workspace\.virtualenvs\pychronia39\lib\site-packages\PIL\_imagingft.cp39-win_amd64.pyd
ID de rapport : 3b5c33e5-109d-45c8-977c-04a956f7da05
Nom complet du package défaillant : 
ID de l’application relative au package défaillant :

It checked this _imagingft.cp39-win_amd64.pyd with a dependency lister, all DLL dependencies seem ok.

The only workaround I found was installing an old version Pillow<=8.3.0

• OS: Windows 10 Home Version 10.0.19044 Numéro 19044
• Python: 3.8.6 or 3.9.1
• Pillow: 9.1.1

[radarhere]

Interesting. I presume this is the same problem as #6314.

PR #6341 will help this slightly, so that importing ImageDraw should be fixed, but importing ImageFont will still fail. That will be released as part of Pillow 9.2.0, due out on July 1.

In that other issue, we have determined what the change was that caused the problem, but not why it is happening. Would you be able to answer the following question (from this comment)?

do you have a fribidi.dll or fribidi-0.dll in one of the following directories (from MSDN):

The directory from which the application loaded.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The current directory.
The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

I'm guessing the last one (one of the PATH directories) is the culprit, if so what is this directory?

[pakal]

Thanks for the feedback !

I have some libfribidi-0.dll in some application folders (Geany, Avidemux, Inkscape), but they seem unrelated

I have this DLL, though, which is in the PATH :
C:\OSGeo4W64\bin\fribidi.dll

When I rename it to _fribidi.dll, the crashing of ImageDraw stops!

So this seems to be the culprit, however I don't even know where one can find proper fribidi.dll, I only find source codes, online, or dubious dlls on third-party file depots.
It looks like having both OSGeo4W64 (for django-gis) and Pillow together in PATH is a problem for now.

I thought that since python3.8, DLL resolution ignored the PATH ? https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew
But I guess that the loading of fribidi.dll uses a different system, more similar to the default one of Windows, and thus collides with PATH dlls ?

Here is the faulting fribidi, in case it helps seing what's wrong with this version ?
fribidi.zip

[nulano]

I'll take a look at why it's crashing.

I don't even know where one can find proper fribidi.dll

For now you can download fribidi.dll from https://www.lfd.uci.edu/~gohlke/pythonlibs/, but that seems to be going away by the end of this month.

You can also use the scripts in https://github.com/python-pillow/Pillow/tree/main/winbuild to compile your own fribidi.dll.

I thought that since python3.8, DLL resolution ignored the PATH ?

When loading fribidi.dll, Pillow doesn't ignore PATH, just checks it last after all other places (as listed in the comment above). If you have a non-crashing fribidi.dll in an earlier directory (e.g. next to python.exe), it would prevent a crash.

Edit: Actually, I think I was confused by a separate change to the loading mechanism. In addition to changing how DLLs are loaded in ctypes, there was also a change to which DLL search order is the default. Pillow does not use ctypes to load fribidi, so is affected only by the latter change.

[nulano]

It looks like your fribidi.dll is FriBiDi 0.19.2 (likely released on 2009-03-26). For some reason, it seems to be missing fribidi_version_info in its export table (the version information is still present in the file, just not exported).

This is causing a null pointer dereference in Pillow.
There is a null check, but I accidentally put it after the dereference:

Pillow/src/thirdparty/fribidi-shim/fribidi.c

Lines 97 to 98 in 765d66c

	fribidi_version_info = *(const char**)GetProcAddress(p_fribidi, "fribidi_version_info");
	if (error || (fribidi_version_info == 0)) {

I have created PR #6376 to correct the null check.
I have checked that with the PR Pillow correctly rejects your fribidi.dll without crashing.

[nulano]

I have some libfribidi-0.dll in some application folders (Geany, Avidemux, Inkscape), but they seem unrelated

If neither fribidi.dll or fribidi-0.dll is found, the name libfribidi-0.dll is also checked if this file is in one of the directories listed above.

While the Inkscape directory is not listed in PATH, I just tested its libfribidi-0.dll by copying it next to python.exe and it seems to work correctly with Pillow. However, examining its imports table suggests that it uses a different C runtime, which could cause issues if you use it.

[pakal]

Niiiice, thanks for the fixes :)

They mention on lfd.uci.edu that their DLLs are most likely not compatible with OSGeo4W and the likes, so it's nice that it be solvable in Pillow directly !

[bramhaag]

I have this DLL, though, which is in the PATH : C:\OSGeo4W64\bin\fribidi.dll

When I rename it to _fribidi.dll, the crashing of ImageDraw stops!

Same issue, and @pakal's workaround worked for me. On Windows, you can use where fribidi.dll to find the conflicting file to rename. In my case, it was bundled with traffic simulation software.