Skip to content

test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x #77811

Closed

Description

@vstinner
BPO 33630
Nosy @vstinner, @alex, @vadmium, @serhiy-storchaka, @zhangyangyu, @stratakis, @pablogsal
PRs
  • bpo-33630: Fix race condition in TestPosixSpawn.test_open #7663
  • bpo-33630: Fix memory leak in old versions of glicb for posix_spawn. #7685
  • 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 = 'https://github.com/serhiy-storchaka'
    closed_at = <Date 2018-06-19.09:10:16.986>
    created_at = <Date 2018-05-24.02:18:53.880>
    labels = ['3.8', 'type-bug', 'tests']
    title = 'test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x'
    updated_at = <Date 2018-06-19.09:10:16.985>
    user = 'https://github.com/vstinner'

    bugs.python.org fields:

    activity = <Date 2018-06-19.09:10:16.985>
    actor = 'vstinner'
    assignee = 'serhiy.storchaka'
    closed = True
    closed_date = <Date 2018-06-19.09:10:16.986>
    closer = 'vstinner'
    components = ['Tests']
    creation = <Date 2018-05-24.02:18:53.880>
    creator = 'vstinner'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 33630
    keywords = ['patch']
    message_count = 31.0
    messages = ['317509', '317524', '317527', '317797', '317827', '319385', '319386', '319387', '319388', '319389', '319390', '319394', '319427', '319429', '319431', '319432', '319434', '319454', '319457', '319458', '319463', '319481', '319485', '319594', '319598', '319605', '319606', '319736', '319936', '319937', '319946']
    nosy_count = 7.0
    nosy_names = ['vstinner', 'alex', 'martin.panter', 'serhiy.storchaka', 'xiang.zhang', 'cstratak', 'pablogsal']
    pr_nums = ['7663', '7685']
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue33630'
    versions = ['Python 3.8']

    Activity

    1. vstinner commented on May 24, 2018

      @vstinner
      MemberAuthor

      http://buildbot.python.org/all/#/builders/53/builds/1062

      (...)
      test_close_file (test.test_posix.TestPosixSpawn) ... ok
      test_dup2 (test.test_posix.TestPosixSpawn) ... ok
      test_empty_file_actions (test.test_posix.TestPosixSpawn) ... ok
      test_multiple_file_actions (test.test_posix.TestPosixSpawn) ... FAIL
      test_no_such_executable (test.test_posix.TestPosixSpawn) ... ok
      test_open_file (test.test_posix.TestPosixSpawn) ... ERROR
      test_returns_pid (test.test_posix.TestPosixSpawn) ... ok
      Warning -- files was modified by test_posix
      Before: []
      After: ['\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb\udcdb']
      test test_posix failed
      test_specify_environment (test.test_posix.TestPosixSpawn) ... ok

      ======================================================================
      ERROR: test_open_file (test.test_posix.TestPosixSpawn)
      ----------------------------------------------------------------------

      Traceback (most recent call last):
        File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/test/test_posix.py", line 1542, in test_open_file
          with open(outfile) as f:
      FileNotFoundError: [Errno 2] No such file or directory: '@test_42482_tmp'

      ======================================================================
      FAIL: test_multiple_file_actions (test.test_posix.TestPosixSpawn)
      ----------------------------------------------------------------------

      Traceback (most recent call last):
        File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/test/test_posix.py", line 1488, in test_multiple_file_actions
          self.assertEqual(os.waitpid(pid, 0), (pid, 0))
      AssertionError: Tuples differ: (31319, 32512) != (31319, 0)

      First differing element 1:
      32512
      0

      • (31319, 32512)
        ? ^^^^^

      + (31319, 0)
      ? ^

      ----------------------------------------------------------------------
      Ran 101 tests in 2.175s

      FAILED (failures=1, errors=1, skipped=9)
      1 test failed again:
      test_posix

    2. serhiy-storchaka commented on May 24, 2018

      @serhiy-storchaka
      Member

      What is \udcdb\udcdb\udcdb...? Looks like a corrupted memory.

    3. serhiy-storchaka commented on May 24, 2018

      @serhiy-storchaka
      Member

      Seems there are 2 or 3 different bugs here. Race condition, using freed memory, and maybe something other. I take this.

    4. pablogsal commented on May 27, 2018

      @pablogsal
      Member

      @serhiy.storchaka Is the race condition/freed memory reusage in the test suite or in the posix module?

    5. serhiy-storchaka commented on May 28, 2018

      @serhiy-storchaka
      Member

      The race condition is in tests (we can open a file before it be written in a child). The reed memory reusage is in the posix module. Didn't look at it close, but seems the content of a temporary Python object (the result of encoding/decoding) is passed to C library function, and this object is freed before the content be used.

    6. vstinner commented on Jun 12, 2018

      @vstinner
      MemberAuthor

      I'm not sure that the attached PR fixes all race conditions.

    7. serhiy-storchaka commented on Jun 12, 2018

      @serhiy-storchaka
      Member

      The part that is related to \udcdb\udcdb\udcdb... is a problem in posix_spawn() implementation, not in tests. It can't be fixed by changing tests.

    8. pablogsal commented on Jun 12, 2018

      @pablogsal
      Member

      In PR 7663 I am only fixing the race condition.

    9. pablogsal commented on Jun 12, 2018

      @pablogsal
      Member

      A separate PR is needed for the apparent reusing of freed memory in the implementation of posix_spawn. I am currently looking into it.

    10. serhiy-storchaka commented on Jun 12, 2018

      @serhiy-storchaka
      Member

      For reference: posix_spawn() was implemented in bpo-20104.

    11. pablogsal commented on Jun 12, 2018

      @pablogsal
      Member

      Should we merge PR6693 and PR6725 before fixing the memory problem?

    12. 7 remaining items

    13. pablogsal commented on Jun 13, 2018

      @pablogsal
      Member

      If we want to support older versions of glibc a temporary (and somewhat inelegant) workaround is storing the temporaries in a list that the caller passes and destroy the list after calling posix_spawn.

    14. vstinner commented on Jun 13, 2018

      @vstinner
      MemberAuthor

      If we want to support older versions of glibc a temporary (and somewhat inelegant) workaround is storing the temporaries in a list that the caller passes and destroy the list after calling posix_spawn.

      Creating a copy seems to be a reasonable tradeoff.

      Another option is to detect the bug at runtime and raise an exception if the bug is detected. But I dislike this option: I hate when a function is available in the os module but calling it raises a NotImplementedError :-( Moreover, posix_spawn() seems to be a lot of benefit, so I would like to be able to use it on "old" glibc versions.

    15. pablogsal commented on Jun 13, 2018

      @pablogsal
      Member

      I have updated the PR with a workaround.

    16. pablogsal commented on Jun 13, 2018

      @pablogsal
      Member

      Serhiy commented in the PR:

      GLIBC and __GLIBC_MINOR__ give you the version of glibc used at >compile time. But can not the different version be dynamically linked at >run time?

      Should we use the list approach always to avoid problems with this?

    17. serhiy-storchaka commented on Jun 13, 2018

      @serhiy-storchaka
      Member

      Yes, as I wrote on GitHub.

    18. serhiy-storchaka commented on Jun 15, 2018

      @serhiy-storchaka
      Member

      As I wrote on GitHub, I think that it is better to use the list approach always for two reasons:

      1. Additional #if's and duplications clutter the code.

      2. It is hard to test the alternate branch if the other branch is used on most developer computers.

      It is better to have a single branch and add a comment that explains a workaround. It can be removed after platforms with buggy glibc versions will grow out of use.

    19. vstinner commented on Jun 15, 2018

      @vstinner
      MemberAuthor

      "It is better to have a single branch and add a comment that explains
      a workaround. It can be removed after platforms with buggy glibc
      versions will grow out of use."

      Recently, I proposed to drop support for old Linux kernels, but some
      people still use them and the code to support these kernels don't need
      a lot of maintenance. So we keep the code :-)
      https://mail.python.org/pipermail/python-dev/2018-January/151821.html

    20. pablogsal commented on Jun 15, 2018

      @pablogsal
      Member

      I have updated PR7685 to use the temporary list as per Serhiy comments.

    21. pablogsal commented on Jun 15, 2018

      @pablogsal
      Member

      As I commented on GitHub, it seems that the race in the test (problem covered in PR7663) disappears once the memory problem is fixed (PR33630). As is a race condition I am not sure that this affirmation is true, but running 3 test suites in parallel that executes test_posix 200 times does not raise any problem on the buildbot after applying the patch in PR33630

    22. vadmium commented on Jun 16, 2018

      @vadmium
      Member

      I doubt it is a race condition. “Waitpid” only returns after the child has terminated, and the file should be created as the child starts, before it terminates. Surely it is just the buggy glibc opening the DBDBDB file, when the test case expects it to create outfile.

    23. serhiy-storchaka commented on Jun 19, 2018

      @serhiy-storchaka
      Member

      New changeset cb97073 by Serhiy Storchaka (Pablo Galindo) in branch 'master':
      bpo-33630: Fix using of freed memory in old versions of glicb for posix_spawn(). (GH-7685)
      cb97073

    24. serhiy-storchaka commented on Jun 19, 2018

      @serhiy-storchaka
      Member

      Thank you Pablo! Seems failures in other tests that look like a race condition actually are caused by the glibc bug. I think that after passing tests on builtbots this issue can be closed.

    25. vstinner commented on Jun 19, 2018

      @vstinner
      MemberAuthor

      PPC64 Fedora 3.x, PPC64LE Fedora 3.x, s390x Debian 3.x and s390x RHEL 3.x buildbots are back to green thanks to this fix.

      Oh wow, so it was a glibc bug: that was unexpected :-( Hopefully, the workaround is tiny and cheap!

      I think that after passing tests on builtbots this issue can be closed.

      Right. I closed the PR 7663 and I close this issue.

      Thank you all for investigating this issue, thanks Serhiy and Xiang for the review, and thanks Pablo for the fix!

    26. transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Labels

    3.8 (EOL)end of lifetestsTests in the Lib/test dirtype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions