GeezerVison is showing github.com — object.__sizeof__(1) have different output between 3.9.10 and 3.12.2 · Issue #117195 · python/cpython
object.__sizeof__(1) have different output between 3.9.10 and 3.12.2 #117195Labels 3.12only security fixesonly security fixes3.13only security fixesonly security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or errortype-crashA hard crash of the interpreter, possibly with a core dumpA hard crash of the interpreter, possibly with a core dump DescriptionBug report
Bug description:
on a Windows x64 machine
>>> #python 3.9.10
>>> object.__sizeof__(1)
28
>>>
>>> #python 3.12.2
>>> object.__sizeof__(1)
56
>>> CPython versions tested on:
3.9, 3.12
Operating systems tested on:
Windows
Linked PRs
Activityterryjreedy commented on Mar 24, 2024 In 3.11, size of -1000, -1, 0, 1. 1000 are 20, 20, 24, 28, 28. In 3.13, 64, 64, 28, 56 , 56. I am not sure if really a 'bug' rather than intentional, but the only mention of 'size of' in 3.12 What's New is that str object size decreased and no mention that size of ints doubled. I seem's like a regression in memory use. The changelog has several mentions of sizes decreasing and only mentions a stack size increase. pochmann3 commented on Mar 24, 2024 object.__sizeof__(1) gives me 56, but int.__sizeof__(1) and 1 .__sizeof__() and sys.getsizeof(1) all give me 28. And id(1) - id(0) and id(2) - id(1)) both give me 32. So it's certainly only object.__sizeof__ misreporting the size. (In Python 3.12.0.)
Reacted by Kirill Podoprigora Eclips4 commented on Mar 24, 2024 It's ends up with an assertion error on debug build for me (current main branch):
./python
Python 3.13.0a5+ (heads/main:eebea7e515, Mar 24 2024, 21:43:31) [GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> object.__sizeof__(1)
python: ./Include/object.h:344: Py_SIZE: Assertion `ob->ob_type != &PyLong_Type' failed.
Aborted vitaldmit commented on Mar 24, 2024 ./python
Python 3.13.0a5+ (heads/main:9967b568ed, Mar 23 2024, 16:10:16) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> object.__sizeof__(1)
56 Eclips4 commented on Mar 24, 2024
./python
Python 3.13.0a5+ (heads/main:9967b568ed, Mar 23 2024, 16:10:16) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> object.__sizeof__(1)
56
Is this a debug build? For the debug build, you should use ./configure --with-pydebug on Linux or pcbuild/build.bat -c Debug on Windows ronaldoussoren commented on Mar 24, 2024 Note that the result of object.__sizeof__(1) being an unexpected value is not necessarily a bug, the __sizeof__ method is overridden in int and gives the expected value there. Also as a user the interface to get the size of an object is sys.getsizeof(1).
The crash in debug mode is likely because PyLongObject is not a PyVarObject in 3.12 even though the type has ob_itemsize set to a nonzero value. In 3.9 the type is a PyVarObject, but doesn't follow the protocol entirely because the sign of the int value is stored in ob_itemsize.
I'm not familiar enough with the code in longobject.c and its evolution to know what's the best fix for 3.12. Long term it is probably better to unset ob_itemsize, but who knows what will break when that change is made in 3.12. Reacted by Kirill Podoprigora and Виталий Дмитриев Eclips4 commented on Mar 24, 2024 Perhaps @markshannon is the right person for this discussion. markshannon commented on Mar 25, 2024 The result of object.__sizeof__(1) is not meaningful, but it shouldn't crash.
MetadataMetadata3.12only security fixesonly security fixes3.13only security fixesonly security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or errortype-crashA hard crash of the interpreter, possibly with a core dumpA hard crash of the interpreter, possibly with a core dump DevelopmentNo branches or pull requestsIssue actions
|