Skip to content

Running the test suite with --junit-xml and -R incorrectly reports refleaks #83434

Closed

Description

@pablogsal
BPO 39253
Nosy @vstinner, @zooba, @pablogsal

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2020-01-07.23:54:53.841>
labels = ['tests', '3.9']
title = 'Running the test suite with --junit-xml and -R incorrectly reports refleaks'
updated_at = <Date 2020-01-08.17:31:56.794>
user = 'https://github.com/pablogsal'

bugs.python.org fields:

activity = <Date 2020-01-08.17:31:56.794>
actor = 'pablogsal'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Tests']
creation = <Date 2020-01-07.23:54:53.841>
creator = 'pablogsal'
dependencies = []
files = []
hgrepos = []
issue_num = 39253
keywords = []
message_count = 9.0
messages = ['359561', '359562', '359563', '359606', '359608', '359610', '359611', '359612', '359615']
nosy_count = 3.0
nosy_names = ['vstinner', 'steve.dower', 'pablogsal']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue39253'
versions = ['Python 3.9']

Linked PRs

Activity

  1. pablogsal commented on Jan 7, 2020

    @pablogsal
    MemberAuthor

    ./python -m test test_list -R : --junit-xml something
    0:00:00 load avg: 0.52 Run tests sequentially
    0:00:00 load avg: 0.52 [1/1] test_list
    beginning 9 repetitions
    123456789
    .........
    test_list leaked [798, 798, 798, 798] references, sum=3192
    test_list leaked [345, 345, 345, 345] memory blocks, sum=1380
    test_list failed

    == Tests result: FAILURE ==

    1 test failed:
    test_list

    Total duration: 3.4 sec
    Tests result: FAILURE

  2. pablogsal commented on Jan 7, 2020

    @pablogsal
    MemberAuthor

    This is going to be very noisy now that we are using --junit-xml in the buildbots...

  3. vstinner commented on Jan 8, 2020

    @vstinner
    Member

    Oh. That explains these strange results on AMD64 RHEL7 Refleaks 3.8:

    https://buildbot.python.org/all/#/builders/219/builds/41

    argv: [b'make', b'buildbottest', b'TESTOPTS=-R 3:3 -u-cpu --junit-xml test-results.xml -j10 ${BUILDBOT_TESTOPTS}', b'TESTPYTHONOPTS=', b'TESTTIMEOUT=11700']

    ...
    test_quopri leaked [168, 168, 168] references, sum=504
    test_quopri leaked [75, 75, 75] memory blocks, sum=225
    1:50:20 load avg: 1.06 Re-running test_future5 in verbose mode
    test_future5 leaked [42, 42, 42] references, sum=126
    test_future5 leaked [20, 20, 20] memory blocks, sum=60
    ...

    The previous build is successful and it didn't use --junit-xml option:

    https://buildbot.python.org/all/#/builders/219/builds/40

  4. zooba commented on Jan 8, 2020

    @zooba
    Member

    We can stop using --junit-xml if we want. GitHub Actions doesn't support displaying test results anyway, so once Azure Pipelines is switched off we'll just be reading the console all the time anyway (unless Buildbot has a way of rendering test results that I haven't noticed?)

  5. zooba commented on Jan 8, 2020

    @zooba
    Member

    My guess would be that the reference tracking needs some kind of awareness for logging results. The results are collected as regular Python objects and formatted later, as we need to calculate totals before writing the XML file.

    I guess keeping those objects around looks like a leak?

  6. pablogsal commented on Jan 8, 2020

    @pablogsal
    MemberAuthor

    We can stop using --junit-xml if we want. GitHub Actions doesn't support displaying test results anyway, so once Azure Pipelines is switched off we'll just be reading the console all the time anyway (unless Buildbot has a way of rendering test results that I haven't noticed?)

    We are using --junit-xml on the buildbots to analyze failures and in the future we can use it to better display the summary, as is more reliable than parsing the longs.

    I guess keeping those objects around looks like a leak?

    Yeah, because it seems that we collect those objects in the innermost runner, while the refleak runner runs the whole "test suite" (the test file, like test_list.py) as one unit.

    To be honest, the easiest fix here maybe is just deactivating the --junit and make a warning as in bpo-27103

  7. pablogsal commented on Jan 8, 2020

    @pablogsal
    MemberAuthor

    deactivating the --junit

    I mean deactivating the --junit *if* is used together with -R

  8. vstinner commented on Jan 8, 2020

    @vstinner
    Member

    FYI test_io is skipped in Python 2.7 when using -R, because test_io is not reliable. Extract of Lib/test/test_io.py:

        if huntrleaks:
            # FIXME: bpo-31731: test_io hangs with --huntrleaks
            print("Warning: bpo-31731: test_io hangs with --huntrleaks: "
                  "exclude the test")
            nottests.add('test_io')

    I'm not shocked by disabling JUnit feature when using -R. But I suggest to raise an error and tune the buildbot configuration to not use it, rather than silently ignore the option.

  9. pablogsal commented on Jan 8, 2020

    @pablogsal
    MemberAuthor

    But I suggest to raise an error and tune the buildbot configuration to not use it, rather than silently ignore the option.

    I already configured the buildbots to not use --junit when running with =R

  10. transferred this issue fromon Apr 10, 2022
  11. 5 remaining items

  12. vstinner commented on Mar 25, 2024

    @vstinner
    Member

    The problem is that writing XML is done outside the code checking for refleaks, and creating the XML stores objects in memory. Pseudo-code:

    xml = XML()
    for i in range(6):
        run_test(xml)  # add data to xml
        check_for_refleaks()
    write_xml(xml)

    Maybe a solution would be to write partial XML in run_test() and then cumulate results in a final XML. Pseudo-code:

    for i in range(6):
        run_test(temp_xml_filename=f"partial{i}.xml")  # write data to disk, not to memory
        check_for_refleaks()
    create_xml([f"partial{i}.xml" for i in range(6)])

    Or partial results can be Python objects written with pickle.

  13. zooba commented on Mar 25, 2024

    @zooba
    Member

    Disabling result collection during leak tests is probably best. I don't think we collect the number of leaked objects in the results, so why would you turn it on? By mistake.

  14. added a commit that references this issue on Mar 25, 2024
  15. vstinner commented on Mar 25, 2024

    @vstinner
    Member

    @zooba:

    Disabling result collection during leak tests is probably best.

    Ok, I wrote PR gh-117232 for that.

  16. added 3 commits that reference this issue on Mar 26, 2024
  17. vstinner commented on Mar 26, 2024

    @vstinner
    Member

    Fixed by change d52bdfb.

  18. added a commit that references this issue on Mar 26, 2024
  19. added a commit that references this issue on Mar 26, 2024
  20. added a commit that references this issue on Mar 26, 2024
  21. added a commit that references this issue on Apr 17, 2024
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

    3.11only security fixes3.12only security fixes3.13only security fixestestsTests in the Lib/test dir

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions