Skip to content

object.__sizeof__(1) have different output between 3.9.10 and 3.12.2 #117195

Closed
Closed
object.__sizeof__(1) have different output between 3.9.10 and 3.12.2#117195
Assignees
markshannon
Labels
3.12only security fixes3.13only security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)type-bugAn unexpected behavior, bug, or errortype-crashA hard crash of the interpreter, possibly with a core dump

Description

@oldoldman
oldoldman
opened on Mar 24, 2024

Bug 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

Activity

  1. oldoldman
    added
    type-bugAn unexpected behavior, bug, or error
    on Mar 24, 2024
  2. terryjreedy
    added
    interpreter-core(Objects, Python, Grammar, and Parser dirs)
    on Mar 24, 2024

  3. terryjreedy commented on Mar 24, 2024

    @terryjreedy
    terryjreedy
    on Mar 24, 2024
    Member

    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.

  4. pochmann3 commented on Mar 24, 2024

    @pochmann3
    pochmann3
    on Mar 24, 2024
    Contributor

    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.)

  5. Eclips4 commented on Mar 24, 2024

    @Eclips4
    Eclips4
    on Mar 24, 2024
    Member

    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
  6. Eclips4
    added
    type-crashA hard crash of the interpreter, possibly with a core dump
    on Mar 24, 2024

  7. vitaldmit commented on Mar 24, 2024

    @vitaldmit
    vitaldmit
    on Mar 24, 2024
    Contributor
    ./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

  8. Eclips4 commented on Mar 24, 2024

    @Eclips4
    Eclips4
    on Mar 24, 2024
    Member
    ./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

  9. ronaldoussoren commented on Mar 24, 2024

    @ronaldoussoren
    ronaldoussoren
    on Mar 24, 2024
    Contributor

    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.

  10. Eclips4 commented on Mar 24, 2024

    @Eclips4
    Eclips4
    on Mar 24, 2024
    Member

    Perhaps @markshannon is the right person for this discussion.

  11. Eclips4
    added
    3.12only security fixes
    3.13only security fixes
    on Mar 24, 2024

  12. markshannon commented on Mar 25, 2024

    @markshannon
    markshannon
    on Mar 25, 2024
    Member

    The result of object.__sizeof__(1) is not meaningful, but it shouldn't crash.

  13. markshannon
    self-assigned this
    on Mar 25, 2024
  14. markshannon
    added a commit that references this issue on May 23, 2024

    GH-117195: Avoid assertion error in `object.__sizeof__` (GH-117220)

    406ffb5
  15. miss-islington
    added a commit that references this issue on May 23, 2024

    pythonGH-117195: Avoid assertion error in `object.__sizeof__` (python…

    465e366
  16. markshannon
    added a commit that references this issue on May 23, 2024

    [3.13] GH-117195: Avoid assertion error in `object.__sizeof__` (GH-11…

    251ef2e
  17. hugovk
    closed this as completedon Jun 15, 2024
  18. estyxx
    added a commit that references this issue on Jul 17, 2024

    pythonGH-117195: Avoid assertion error in `object.__sizeof__` (python…

    512e694
  19. miss-islington
    added a commit that references this issue on Dec 4, 2024

    pythonGH-117195: Avoid assertion error in `object.__sizeof__` (python…

    1ebe0e3
  20. vstinner
    added a commit that references this issue on Dec 11, 2024

    [3.12] GH-117195: Avoid assertion error in `object.__sizeof__` (GH-11…

    0964f9f
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

3.12only security fixes3.13only security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)type-bugAn unexpected behavior, bug, or errortype-crashA hard crash of the interpreter, possibly with a core dump

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions