Crash when importing ImageFont

[euronautic]

What did you do?

from PIL import ImageDraw

Run in File and in Interactive Mode

What did you expect to happen?

Import of ImageDraw and not crashing

What actually happened?

Python exits without any error while trying to import. Script or Interactive Mode is closed.

What are your OS, Python and Pillow versions?

• OS: Windows 10 Pro 21H2
• Python: 3.8.2 and 3.9.5
• Pillow: 9.0.0 and 9.1.1

Script:

print("1")
from PIL import ImageDraw
print("2")

Output:

1

Crash without any error

[radarhere]

Without an error, this is hard to investigate. Here are some questions

• It's only ImageDraw? This doesn't happen when try to import Image?
• How did you install Pillow?
• What is the exact command that you're using to start Python? Does the same thing happen if you try and run your Python script any other ways? Through IDLE maybe? Does that provide you with an error message?

[euronautic]

• from PIL import Image works as expected
• Installed via pip in a clean virtual environment pip install pillow
• Other pillow versions work fine. I tested pillow==7.0.0 and pillow==8.0.0
• started script in the commandline: python example.py
• happens also in interactive mode. Started in command line with python and then from PIL import ImageDraw. Results in an exit of the interactive mode without any error or feedback
• I could reproduce the problem on a different machine.
• Commands to reproduce: python -m venv venv, activate venv, python -m pip install --upgrade pip, pip install pillow, python, from PIL import ImageDraw (tested with the python versions mentioned above. Tested on two machines)
• No feedback or error message. Just closed like I typed exit()

[nulano]

No feedback or error message. Just closed like I typed exit()

This is how a C error behaves on Windows. This is most likely an access violation, similar to a segfault on Linux. If you are running from command line you can type echo %ERRORLEVEL% (or echo $LASTEXITCODE in PowerShell) right after the crash to confirm.

It might be possible to get a stack trace using Visual Studio or another debugger, although I'm not sure if the release binaries contain enough debug information to obtain anything usable.

[euronautic]

Here is the result of running echo $LASTEXITCODE:

C:\Example> python
>>> from PIL import ImageDraw

C:\Example> echo $LASTEXITCODE
-1073741819

With PyCharm I was not able to get a stack trace.

[nulano]

As I expected, -1073741819 is C0000005 in hex, which is an Access Violation on Windows.

With PyCharm I was not able to get a stack trace.

You would have to use a C debugger (native debugger in Visual Studio, WinDBG, lldb via CLion, etc.), not a Python debugger (PyCharm, etc.).

---

The file ImageDraw.py imports three other Pillow modules: Image, ImageColor, ImageFont. You already said you can import Image without an error. Do the other two work correctly as well?

[euronautic]

The import of Image and ImageColor works without an error. ImageColor fails just like ImageDraw.

Unfortunately, I'm not able to debug and retrieve a stack trace.

[radarhere]

The import of Image and ImageColor works without an error. ImageColor fails just like ImageDraw.

Could you rephrase this? The first sentence seems to say that ImageColor is fine, then the second sentence says that it fails. Did you mean to say that ImageColor is fine and ImageFont fails?

[euronautic]

Sorry! You are right: The import of ImageFont fails

[radarhere]

I've created #6341 to not import ImageFont by default in ImageDraw. If merged, it will help your situation, but only by avoiding the real problem.

[radarhere]

ImageDraw only started importing ImageFont by default in Pillow 8.3.0 with #5510.

So when you said earlier that Pillow 7 and Pillow 8 worked fine, that would be the explanation.

If you try and from PIL import ImageFont in an earlier Pillow version, I'm guessing that it will still fail?

[euronautic]

I tested from PIL import ImageFont and from PIL import ImageDraw.
Both failed since version pillow==8.3.1.
In the versions before (pillow==8.3.0 and older) both imports succeded.
-> Something broke with version 8.3.1

[radarhere]

Nothing in the changelog looks related to me. Seeing this comment, I think #5062 is what triggered it.

That issue starts linking to font dependencies dynamically on Windows. @nulano will have a better understanding of this than me, but if I'm right, the release notes for that change would suggest that something is wrong with your fribidi.dll or fribidi-0.dll. This would also explain why we don't have many more users reporting ImageFont issues.

[nulano]

Yes, I would agree that is the most likely explanation.

I did test having the wrong version (x86 FriBiDi with x86_64 Python) and it just ignores that, so I'm not sure if the crash is in Pillow or just in FriBiDi. @euronautic 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?

[radarhere]

#6341 has been merged, so in the next release of Pillow (due on July 1), the ImageDraw import problem should be fixed, leaving just the ImageFont import problem.

@euronautic are you able to provide an answer to the last comment?

[radarhere]

This clearly isn't happening in our CI environments, nor for the vast majority of Windows users. You haven't mentioned anything unusual about your setup, so without further responses, we aren't able to effectively debug this problem.

[nulano]

In #6374 a similar issue was caused by the file C:\OSGeo4W64\bin\fribidi.dll.

@euronautic do you also have this file on your system?
Does renaming or removing it resolve your issue?

[github-actions]

Closing this issue as no feedback has been received.