Skip to content

test_sys_settrace leaked [6604, 6602, 6604] on main branch  #94979

Description

@kumaraditya303

Commit tested: a25a803

@kumaraditya303 ➜ /workspaces/cpython (main) $ ./python -m test -R 3:3 test_sys_settrace
0:00:00 load avg: 31.03 Run tests sequentially
0:00:00 load avg: 31.03 [1/1] test_sys_settrace
beginning 6 repetitions
123456
......
test_sys_settrace leaked [6604, 6602, 6604] references, sum=19810
test_sys_settrace leaked [1835, 1860, 1856] memory blocks, sum=5551
test_sys_settrace failed (reference leak)

== Tests result: FAILURE ==

1 test failed:
    test_sys_settrace

Total duration: 1.2 sec
Tests result: FAILURE

Activity

  1. kumaraditya303 commented on Jul 18, 2022

    @kumaraditya303
    ContributorAuthor
  2. kumaraditya303 commented on Jul 18, 2022

    @kumaraditya303
    ContributorAuthor

    Git bisect points to 2f8bff6 as first bad commit:

    commit 2f8bff6879c5d76d143068e8bc867196a7d28afc (HEAD)
    Author: Mark Shannon <mark@hotpy.org>
    Date:   Mon Jul 18 16:06:42 2022 +0100
    
        GH-94739: Mark stacks of exception handling blocks for setting frame.f_lineno in the debugger. (GH-94958)
    
  3. mdboom commented on Jul 18, 2022

    @mdboom
    Contributor

    frame.setlineno strikes again.

  4. brandtbucher commented on Jul 18, 2022

    @brandtbucher
    Member

    Checking this out now.

  5. brandtbucher commented on Jul 18, 2022

    @brandtbucher
    Member

    The following three tests are leaking:

    • test_jump_from_except_to_finally
    • test_jump_out_of_bare_except_block
    • test_jump_out_of_qualified_except_block

    The issue is when we jump out of an exception handler into non-exception-handling code. We skip over POP_EXCEPT, which is supposed to clear tstate->exc_info->exc_value, the currently active exception. This exception references thousands of objects through its traceback frames.

    I'm not sure what a good solution is. Perhaps clearing the thread's exception state if we can detect that we're jumping out of an exception handler? I'm not sure if that's always correct (or even easy to detect). Maybe we can flag every stack between an exception handler entry and a POP_EXCEPT?

    Or, just disallow jumping out of exception handlers like this?

  6. added 2 commits that reference this issue on Jul 19, 2022
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 fixestype-bugAn unexpected behavior, bug, or error

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions