Repository navigation
signal module wrongly relies on small int singletons #90566
Description
| BPO | 46408 |
|---|---|
| Nosy | @tiran, @serhiy-storchaka |
| Superseder |
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 = <Date 2022-01-17.09:13:13.899>
created_at = <Date 2022-01-17.09:01:28.784>
labels = ['extension-modules', 'type-bug', '3.9', '3.10', '3.11']
title = 'signal module wrongly relies on small int singletons'
updated_at = <Date 2022-01-17.09:13:40.107>
user = 'https://github.com/tiran'bugs.python.org fields:
activity = <Date 2022-01-17.09:13:40.107>
actor = 'christian.heimes'
assignee = 'none'
closed = True
closed_date = <Date 2022-01-17.09:13:13.899>
closer = 'christian.heimes'
components = ['Extension Modules']
creation = <Date 2022-01-17.09:01:28.784>
creator = 'christian.heimes'
dependencies = []
files = []
hgrepos = []
issue_num = 46408
keywords = []
message_count = 3.0
messages = ['410747', '410748', '410750']
nosy_count = 2.0
nosy_names = ['christian.heimes', 'serhiy.storchaka']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = 'resolved'
status = 'closed'
superseder = '23325'
type = 'behavior'
url = 'https://bugs.python.org/issue46408'
versions = ['Python 3.9', 'Python 3.10', 'Python 3.11']
Activity
tiran commentedon Jan 17, 2022
The signal.signal() function directly compares PyObject *handler with PyObject *modstate->ignore_handler. This works on most platforms because they are both small ints and Python uses singletons for cached small ints.
The assumption breaks when Python is built without small int cache or a platform has SIG_IGN / SIG_DFL that is outside the range of small int cache. The wasm32-emscripten platform uses "((void (*)(int))-2)" (4294967294) for SIG_IGN. The wrong comparison breaks several tests on WASM32. The function should use PyObject_RichCompareBool(handler, modstate->ignore_handler, Py_EQ) instead.
cpython/Modules/signalmodule.c
Lines 530 to 534 in 7f4b69b
serhiy-storchaka commentedon Jan 17, 2022
See msg234768 and bpo-23325. I propose to close this as a duplicate of bpo-23325.
tiran commentedon Jan 17, 2022
Yes, it's a duplicate.