New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SubIntepreters don't work with DontWriteBytecodeFlag in Python 3.10 #358
Comments
I am seeing the same error when building jep in the python:3.10 docker container using the Dockerfile below. I commented out various parts of TestPreInitVariables.java and found the problem goes away if we don't test Py_OptimizeFlag.
|
The problem is not specific to the Py_OptimizeFlag like I suspected. Instead the problem seems to be related to using subinterpreters when the bytecode is not loaded from *.pyc files in I was able to eliminate the problem by precompiling python libraries with the optimization level set, either by just running the setup.py as I was also able to trigger the problem with other tests by setting the env var It looks like right now SubInterpreters only work if there are cached pyc files for the system python libraries, we still need to do more digging to see if there is anything we can do about it or if this is a bug in python. |
Are you saying SharedInterpreters are ok? I found on this ticket they changed the format of .pyc files, but they said it went into Python 3.10.1 and they don't seem concerned with breakage so it may be irrelevant. |
Yes, I have only seen this problem in SubInterpreters
I've been trying to pinpoint when this may have started in python without much luck. I've gone all the way back to April with ad442a6 and i see the same problem. In Oct 2020 with 22220ae the problem isn't happening. I'm not sure how to narrow it down further without building and testing every python commit which is very time consuming. If you would like to replicate it with the python you built yourself you just need to delete pycache in your python lib directory(where ever abc.py is) |
I have narrowed it down to a specific commit in cpython where the problem first shows up: python/cpython@ea25180 This change is changing the way unicode objects are interned in sub-interpreters. I have not pieced together why this is causing the error we see but my top suspect is that the string compariosn for @vstinner Do you see any way ea25180 would cause problems for subinterpreters only when the bytecode is not loaded from pyc files? |
@bsteffensmeier: Hi, how can I reproduce the issue? Can you write a reproducer which doesn't use jep? In Python 3.10, I modified _PyUnicode_FromId() to make _Py_IDENTIFIER() per interpreter. Each interpreter has its own Unicode object. Previously, the object was shared between all interpreters. |
I will work on writing a simple reproducer Edit: my initial attempts at a reproducer are not working, this may be more complicated than I suspected. |
In my initial attempts I was not setting PYTHONDONTWRITEBYTECODE correctly. Any application with sub-interpreters should fail if that is set. To get a repeatable test I am testing in docker using the python:3.10 image. In this example I am setting Py_DontWriteBytecodeFlag in code but it also breaks if you set the env var.
And here is subinterp_test.c, it is just the minimal c code to set Py_DontWriteBytecodeFlag and start a subinterpreter.
And finally here is the error when I build it:
|
Oh great! You did a great job to write a short reproducer! I reported the issue upstream https://bugs.python.org/issue46006 and I posted my analysis there. |
The bug triggers if the abc module is not cached (if there is no PYC file for the abc module). The workaround (until the bug is fixed) is to make sure that Python stdlib has cached PYC files. I'm not sure why the Windows CI doesn't have these PYC files. You can try to workaround the bug by compiling the stdlib Python files. See for example the compileall module: |
@vstinner Thank you for following up on this! I agree the problem does not exist when the cached PYC files are present. I don't know if there are any real use cases that will run into this, we just happened to have a unit test that would trigger it. I am considering just skipping this particular test anytime jep is built against 3.10.0 or 3.10.1. If anyone is actually running into this in their environment they would have to implement the workarounds documented here. |
Closing because this has been fixed in upstream python. |
I built Python 3.10 in a Docker container on Linux and tested Jep against it and the tests all passed. However, when I turned on Python 3.10 in appveyor it failed the Windows build with an error in the PyConfig pre-inits.
The text was updated successfully, but these errors were encountered: