fails to load very big constant numbers about bytecode HOT 11 CLOSED

Thanks for the report. Could you make a PR adding LOAD_CONST to _stack_effects so that we avoid the offending call ? Add a test and an entry in the changlog.

from bytecode.

Very glad to do that. I'll make it done.

from bytecode.

I can't reproduce the error. What python version do you use?

from bytecode.

I did not have time to try to reproduce but the line 34 in _opcode.c seemed like a possible reason for the error:

oparg_int = (int)PyLong_AsLong(oparg);

from bytecode.

@serhiy-storchaka This 0xFFFFFFFF...

from bytecode.

And I'm using Python 3.6.5 in Windows 10 x86_64.

from bytecode.

@MatthieuDartiailh Yes, you're right! (int)PyLong_AsLong(oparg) causes this, but note that standard compiler could even compile 0xFFFFFFFFFF..

I've found the way to solve this problem, a few minutes.

from bytecode.

I am not sure that specifying a whitelist for opcodes whose stack effect depends on its argument is a good approach. The list is not complete. It lacks following opcodes: BUILD_LIST, BUILD_LIST_UNPACK, BUILD_MAP_UNPACK, BUILD_SET, BUILD_SET_UNPACK, BUILD_TUPLE, BUILD_TUPLE_UNPACK, BUILD_TUPLE_UNPACK_WITH_CALL, CALL_FUNCTION_VAR, CALL_FUNCTION_VAR_KW, MAKE_CLOSURE. Also in new Python versions new opcodes can be added, and the meaning of old opcodes can be changed.

Are there other opcodes that need a workaround besides LOAD_CONST?

from bytecode.

#41 addresses this.

from bytecode.

Thanks for the ping @serhiy-storchaka . Actually I probably was in too much of a rush when reviewing the #43.
Looking through Python opcode and our implementation, I believe you are correct that only LOAD_CONST can manipulate arbitrary objects. And limiting the workaround to this one seems safer. I will review your PR sometimes next week. I want in particular to understand the need for the modified tests.
Thanks again for catching this.

from bytecode.

I have extracted the fix for this issue into separate PR #44.

from bytecode.