Skip to content

try/except leads to infinite loop with growing memory usage #1

Closed

Description

@pfalcon

Running a following script (./py exc.py) leads to an infinite loop with a growing memory usage (i.e. uPy keeps allocating something in an infinite loop):

a = {}
try:
    a[1]
except KeyError:
    print("caught")

Running on x64.

Activity

  1. dpgeorge commented on Dec 29, 2013

    @dpgeorge
    Member

    There is currently no memory manager (no garbage collection) for the unix version, so that's why it eats memory. But it's certainly a bug that it runs an infinite loop.

  2. dpgeorge commented on Dec 29, 2013

    @dpgeorge
    Member

    Added proper nested exception handling, and basic exception type matching. Above code should now work.

  3. pfalcon commented on Dec 29, 2013

    @pfalcon
    ContributorAuthor

    Thanks for quick response, hope it doesn't steal cycles from hardware hacking ;-). (Though this particular issue is important enough, so I really appreciate looking into it).

    Well, exception-throwing path now works (including on x86/32bit, will submit patch once cleaned up), but exception-free path leads to:

    a = {1:2}
    try:
        a[1]
    except KeyError:
        print("caught")
    
    ./py exc.py 
    py: ../py/vm.c:308: mp_execute_byte_code_2: Assertion `0' failed.
    Aborted
    

    Corresponding opcode doesn't appear to be implemented.

  4. dpgeorge commented on Dec 29, 2013

    @dpgeorge
    Member

    Yep, it's not fully implemented. Micro Python doesn't use reference counting (like CPython) so the action of push/pop blocks in the interpreter is a bit simpler for Micro Python. Thus, the byte code POP_BLOCK is probably only needed when exiting an exception handling block.

  5. dpgeorge commented on Dec 29, 2013

    @dpgeorge
    Member

    Okay, it should now work. There will still be issues with "finally" and "with" blocks.

  6. pfalcon commented on Dec 29, 2013

    @pfalcon
    ContributorAuthor

    Yes, confirmed working. Let's close and track finally/with somewhere else then. (Note that I didn't try to find which Python features don't work, just read that "It works only for 64-bit machines due to a small piece of x86-64 assembler for
    the exception handling.", so after building for x86, I proceeded to test exactly exception handling ;-) ).

  7. dpgeorge commented on Dec 29, 2013

    @dpgeorge
    Member

    By "exception handling" I actually meant the underlying C exception handling that I'm using (nlr_jump). You don't see it, but it's working when you get a Python error, eg at the command line just type "foo" and it'll give you a NameError. That's using nlr_jump, written in assembler.

  8. added a commit that references this issue on Aug 28, 2016
  9. added a commit that references this issue on Oct 16, 2016
    7fd84e9
  10. added a commit that references this issue on Oct 6, 2017
  11. added a commit that references this issue on Aug 21, 2018
  12. added a commit that references this issue on Oct 25, 2018
  13. added a commit that references this issue on Dec 4, 2018
  14. 19 remaining items

  15. added a commit that references this issue on May 6, 2023
  16. added a commit that references this issue on Jul 6, 2023
  17. added a commit that references this issue on Oct 24, 2023
  18. added a commit that references this issue on Mar 8, 2024
  19. added a commit that references this issue on Jul 26, 2024
  20. added a commit that references this issue on Feb 25, 2025
  21. added a commit that references this issue on Nov 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions