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
importlib.h should be regenerated when the marshaling code changes #59557
Comments
Today I was hacking on a patch that changes the marshaling format for Code objects. When building the patch I was met with: ValueError: bad marshal data (unknown type code) This is because the frozen importlib was not rebuilt with the new marshaling format. |
Patch attached. |
Looks good to me. It probably won't cover all cases (such as e.g. changing the bytecode format), but it's a good step forward. |
FYI: the .pyc magic number is now built/kept in Lib/importlib/_bootstrap.py, so updates to it will trigger a rebuild of frozen importlib during make. |
What I mean is, shouldn't changes to marshal have an accompanying bump to the pyc magic number? |
Eric, that is a good point, but if someone forgets (like I did) or just hasn't gotten around to bumping the number yet, then the build breaks because the interpreter crashes. I think we should always try to avoid building an interpreter that is in an inconsistent state. Anyway, I am hitting another problem now -- _freeze_importlib is *not* idempotent. Thus adding this rule might cause some noise in the builds because importlib.h is different when nothing has actually changed. I am still investigating that problem. Assuming I can fix the idempotency problem, then maybe _freeze_importlib should just be always run. |
Hmmm, I guess the idempotency issue is no worse than it already is -- the Consider this small example (you might have to run sample program multiple $ cat dis-closure.py
import dis def adder(a, b):
def add():
return a + b
return add print(dis.dis(adder(1, 2).__code__)) $ ./python.exe dis-closure.py
5 0 LOAD_DEREF 0 (a)
3 LOAD_DEREF 1 (b)
6 BINARY_ADD
7 RETURN_VALUE
None
$ ./python.exe dis-closure.py
5 0 LOAD_DEREF 1 (a)
3 LOAD_DEREF 0 (b)
6 BINARY_ADD
7 RETURN_VALUE
None The order of 'co_cellvars', 'co_varnames', and 'co_freevars' can be Thus there may be times where importlib.h is regenerated, but the changes I will just commit this patch as is. |
What do you mean with "idempotent"? Deterministic? |
Le lundi 16 juillet 2012 à 05:42 +0000, Meador Inge a écrit :
I don't know, but you could open an issue just for the record. |
On Mon, Jul 16, 2012 at 5:20 AM, Antoine Pitrou <report@bugs.python.org> wrote:
Whoops, yeah, deterministic. I got mixed up with my terminology. |
On Mon, Jul 16, 2012 at 7:13 AM, Antoine Pitrou <report@bugs.python.org> wrote:
Yeah, I was somewhat surprised and it took some digging to figure |
Meador, is this still a problem? There was a flurry of activity in this area. |
Yup, it is still an issue. The recent activity was mostly related to Windows builds (bpo-15431). |
FWIW, the patch looks good to me. This is probably the last week to get this in for 3.3.0. |
New changeset 344f44bd793f by Eric Snow in branch 'default': |
Thanks for the patch Meador. |
Hmmm, not sure why I forgot to apply this myself. Thanks for committing it Eric. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: