[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

STINNER Victor added the comment: 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

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Serhiy Storchaka added the comment: 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. -- ___ Python tracker

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Serhiy Storchaka added the comment: New changeset cb970730e3ca2522e9b1700dcaf0a06b7e898db6 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) https://github.com/python/cpython/commit/cb970730e3ca2

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Martin Panter added the comment: 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

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Pablo Galindo Salgado added the comment: I have updated PR7685 to use the temporary list as per Serhiy comments. -- ___ Python tracker ___

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Pablo Galindo Salgado added the comment: 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 t

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

STINNER Victor added the comment: "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 an

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Serhiy Storchaka added the comment: 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

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Serhiy Storchaka added the comment: Yes, as I wrote on GitHub. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscr

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Pablo Galindo Salgado added the comment: 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?

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Change by Pablo Galindo Salgado : -- pull_requests: +7298 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Pablo Galindo Salgado added the comment: I have updated the PR with a workaround. -- ___ Python tracker ___ ___ Python-bugs-list ma

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

STINNER Victor added the comment: > 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 tradeof

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Pablo Galindo Salgado added the comment: 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`. -- ___

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Charalampos Stratakis added the comment: The latest stable Fedora's have glibc >= 2.26 Maybe the buildbot needs to be updated? -- nosy: +cstratak ___ Python tracker ___ _

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Serhiy Storchaka added the comment: Thank you Xiang! Thus this is a bug in old glibc. It was fixed in glibc 2.20: https://sourceware.org/bugzilla/show_bug.cgi?id=17048 . What should we do with this? Add a workaround for the bug (this will complicate the code)? Or skip the test on glibc <2.20

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Xiang Zhang added the comment: Serhiy, you need to check an early version, for example 2.17: https://github.com/bminor/glibc/blob/glibc-2.17/posix/spawn_faction_addopen.c -- ___ Python tracker _

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Serhiy Storchaka added the comment: I'm puzzled. It is not just documented that posix_spawn_file_actions_addopen() should make a copy, but the glibc implementation actually makes it: see for example https://github.com/bminor/glibc/blob/09533208febe923479261a27b7691abef297d604/posix/spawn_fac

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Xiang Zhang added the comment: I checked glibc changelog and the copy behaviour is not implemented until 2014, glic 2.20. There is a CVE-2014-4043. My environment has glic 2.17 which seems still suffer the problem. -- ___ Python tracker

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Xiang Zhang added the comment: I encounter the same failure when running test_posix suite with a debug build Python. [root@SZX1000328166 cpython]# ./python -m test test_posix Run tests sequentially 0:00:00 load avg: 0.91 [1/1] test_posix Warning -- files was modified by test_posix Before:

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Pablo Galindo Salgado added the comment: Serhiy, I am checking and the only temporary Python object (the result of encoding/decoding) that is passed to C library function that I can find is in: if (!PyArg_ParseTuple(file_action, "OiO&ik" ";A open file

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Serhiy Storchaka added the comment: For reference: posix_spawn() was implemented in issue20104. -- ___ Python tracker ___ ___ Pytho

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Pablo Galindo Salgado added the comment: Should we merge PR6693 and PR6725 before fixing the memory problem? -- ___ Python tracker ___

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Pablo Galindo Salgado added the comment: A separate PR is needed for the apparent reusing of freed memory in the implementation of posix_spawn. I am currently looking into it. -- ___ Python tracker

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Pablo Galindo Salgado added the comment: In PR 7663 I am only fixing the race condition. -- ___ Python tracker ___ ___ Python-bugs-

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Serhiy Storchaka added the comment: 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. -- ___ Python tracker _

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

STINNER Victor added the comment: I'm not sure that the attached PR fixes all race conditions. -- ___ Python tracker ___ ___ Python

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Change by Pablo Galindo Salgado : -- pull_requests: +7278 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Serhiy Storchaka added the comment: 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

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Pablo Galindo Salgado added the comment: @serhiy.storchaka Is the race condition/freed memory reusage in the test suite or in the posix module? -- nosy: +pablogsal ___ Python tracker

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Change by STINNER Victor : -- pull_requests: -6734 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Change by twisteroid ambassador : -- keywords: +patch pull_requests: +6734 stage: -> patch review ___ Python tracker ___ ___ Python-

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Serhiy Storchaka added the comment: Seems there are 2 or 3 different bugs here. Race condition, using freed memory, and maybe something other. I take this. -- assignee: -> serhiy.storchaka type: -> behavior ___ Python tracker

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

Serhiy Storchaka added the comment: What is \udcdb\udcdb\udcdb...? Looks like a corrupted memory. -- nosy: +serhiy.storchaka ___ Python tracker ___

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

New submission from STINNER Victor : 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