Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bpo-41993: Fix possible issues in remove_module() #22631

Merged
merged 3 commits into from
Oct 11, 2020

Conversation

serhiy-storchaka
Copy link
Member

@serhiy-storchaka serhiy-storchaka commented Oct 10, 2020

Copy link
Member

@vstinner vstinner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@miss-islington
Copy link
Contributor

Thanks @serhiy-storchaka for the PR 🌮🎉.. I'm working now to backport this PR to: 3.8, 3.9.
🐍🍒⛏🤖

@serhiy-storchaka serhiy-storchaka deleted the import-remove_module branch October 11, 2020 13:51
@bedevere-bot bedevere-bot removed the needs backport to 3.9 only security fixes label Oct 11, 2020
@bedevere-bot
Copy link

GH-22647 is a backport of this pull request to the 3.9 branch.

@miss-islington
Copy link
Contributor

Sorry, @serhiy-storchaka, I could not cleanly backport this to 3.8 due to a conflict.
Please backport using cherry_picker on command line.
cherry_picker 8287aadb75f6bd0154996424819334cd3839707c 3.8

miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Oct 11, 2020
* PyMapping_HasKey() is not safe because it silences all exceptions and can return incorrect result.
* Informative exceptions from PyMapping_DelItem() are overridden with RuntimeError and
  the original exception raised before calling remove_module() is lost.
* There is a race condition between PyMapping_HasKey() and PyMapping_DelItem().
(cherry picked from commit 8287aad)

Co-authored-by: Serhiy Storchaka <[email protected]>
@serhiy-storchaka serhiy-storchaka added needs backport to 3.8 only security fixes and removed needs backport to 3.8 only security fixes labels Oct 11, 2020
@miss-islington
Copy link
Contributor

Thanks @serhiy-storchaka for the PR 🌮🎉.. I'm working now to backport this PR to: 3.8.
🐍🍒⛏🤖

@miss-islington
Copy link
Contributor

Sorry @serhiy-storchaka, I had trouble checking out the 3.8 backport branch.
Please backport using cherry_picker on command line.
cherry_picker 8287aadb75f6bd0154996424819334cd3839707c 3.8

serhiy-storchaka added a commit to serhiy-storchaka/cpython that referenced this pull request Oct 11, 2020
* PyMapping_HasKey() is not safe because it silences all exceptions and can return incorrect result.
* Informative exceptions from PyMapping_DelItem() are overridden with RuntimeError and
  the original exception raised before calling remove_module() is lost.
* There is a race condition between PyMapping_HasKey() and PyMapping_DelItem()..
(cherry picked from commit 8287aad)

Co-authored-by: Serhiy Storchaka <[email protected]>
@bedevere-bot bedevere-bot removed the needs backport to 3.8 only security fixes label Oct 11, 2020
@bedevere-bot
Copy link

GH-22649 is a backport of this pull request to the 3.8 branch.

serhiy-storchaka added a commit that referenced this pull request Oct 14, 2020
* PyMapping_HasKey() is not safe because it silences all exceptions and can return incorrect result.
* Informative exceptions from PyMapping_DelItem() are overridden with RuntimeError and
  the original exception raised before calling remove_module() is lost.
* There is a race condition between PyMapping_HasKey() and PyMapping_DelItem().
(cherry picked from commit 8287aad)

Co-authored-by: Serhiy Storchaka <[email protected]>
@bedevere-bot
Copy link

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot s390x RHEL8 3.9 has failed when building commit 391a544.

What do you need to do:

  1. Don't panic.
  2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
  3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/490/builds/77) and take a look at the build logs.
  4. Check if the failure is related to this commit (391a544) or if it is a false positive.
  5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/490/builds/77

Failed tests:

  • test_multiprocessing_spawn

Failed subtests:

  • test_put - test.test_multiprocessing_spawn.WithProcessesTestQueue

Summary of the results of the build (if available):

== Tests result: FAILURE then ENV CHANGED ==

410 tests OK.

10 slowest tests:

  • test_concurrent_futures: 3 min
  • test_capi: 2 min 34 sec
  • test_multiprocessing_spawn: 2 min 22 sec
  • test_peg_generator: 2 min 10 sec
  • test_unparse: 1 min 37 sec
  • test_tokenize: 1 min 36 sec
  • test_gdb: 1 min 32 sec
  • test_subprocess: 1 min 22 sec
  • test_multiprocessing_forkserver: 1 min 17 sec
  • test_lib2to3: 1 min 17 sec

1 test altered the execution environment:
test_asyncio

14 tests skipped:
test_devpoll test_ioctl test_kqueue test_msilib test_nis
test_ossaudiodev test_startfile test_tix test_tk test_ttk_guionly
test_winconsoleio test_winreg test_winsound test_zipfile64

1 re-run test:
test_multiprocessing_spawn

Total duration: 10 min 55 sec

Click to see traceback logs
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/dje/cpython-buildarea/3.9.edelsohn-rhel8-z/build/Lib/multiprocessing/spawn.py", line 116, in spawn_main
    exitcode = _main(fd, parent_sentinel)
  File "/home/dje/cpython-buildarea/3.9.edelsohn-rhel8-z/build/Lib/multiprocessing/spawn.py", line 126, in _main
    self = reduction.pickle.load(from_parent)
  File "/home/dje/cpython-buildarea/3.9.edelsohn-rhel8-z/build/Lib/multiprocessing/synchronize.py", line 110, in __setstate__
    self._semlock = _multiprocessing.SemLock._rebuild(*state)
FileNotFoundError: [Errno 2] No such file or directory


Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.9.edelsohn-rhel8-z/build/Lib/test/_test_multiprocessing.py", line 938, in test_put
    self.assertEqual(queue_empty(queue), False)
AssertionError: True != False


Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.9.edelsohn-rhel8-z/build/Lib/asyncio/sslproto.py", line 321, in __del__
    self.close()
  File "/home/dje/cpython-buildarea/3.9.edelsohn-rhel8-z/build/Lib/asyncio/sslproto.py", line 316, in close
    self._ssl_protocol._start_shutdown()
  File "/home/dje/cpython-buildarea/3.9.edelsohn-rhel8-z/build/Lib/asyncio/sslproto.py", line 590, in _start_shutdown
    self._abort()
  File "/home/dje/cpython-buildarea/3.9.edelsohn-rhel8-z/build/Lib/asyncio/sslproto.py", line 731, in _abort
    self._transport.abort()
  File "/home/dje/cpython-buildarea/3.9.edelsohn-rhel8-z/build/Lib/asyncio/selector_events.py", line 680, in abort
    self._force_close(None)
  File "/home/dje/cpython-buildarea/3.9.edelsohn-rhel8-z/build/Lib/asyncio/selector_events.py", line 731, in _force_close
    self._loop.call_soon(self._call_connection_lost, exc)
  File "/home/dje/cpython-buildarea/3.9.edelsohn-rhel8-z/build/Lib/asyncio/base_events.py", line 746, in call_soon
    self._check_closed()
  File "/home/dje/cpython-buildarea/3.9.edelsohn-rhel8-z/build/Lib/asyncio/base_events.py", line 510, in _check_closed
    raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed

xzy3 pushed a commit to xzy3/cpython that referenced this pull request Oct 18, 2020
* PyMapping_HasKey() is not safe because it silences all exceptions and can return incorrect result.
* Informative exceptions from PyMapping_DelItem() are overridden with RuntimeError and
  the original exception raised before calling remove_module() is lost.
* There is a race condition between PyMapping_HasKey() and PyMapping_DelItem().
@serhiy-storchaka serhiy-storchaka removed their assignment Dec 29, 2020
adorilson pushed a commit to adorilson/cpython that referenced this pull request Mar 13, 2021
* PyMapping_HasKey() is not safe because it silences all exceptions and can return incorrect result.
* Informative exceptions from PyMapping_DelItem() are overridden with RuntimeError and
  the original exception raised before calling remove_module() is lost.
* There is a race condition between PyMapping_HasKey() and PyMapping_DelItem().
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants