Odd handling of signal raised if an illegal syscall is attempted on Android #91028
Copy link
Copy link
Closed
Closed
Copy link
Labels
OS-androidtopic-C-APItype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
Description
| BPO | 46872 |
|---|---|
| Nosy | @mr-nfamous |
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 2022-02-27.11:26:00.251>
labels = ['expert-C-API', 'type-bug']
title = 'Odd handling of signal raised if an illegal syscall is attempted on Android'
updated_at = <Date 2022-02-27.11:26:00.251>
user = 'https://github.com/mr-nfamous'bugs.python.org fields:
activity = <Date 2022-02-27.11:26:00.251>
actor = 'bup'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['C API']
creation = <Date 2022-02-27.11:26:00.251>
creator = 'bup'
dependencies = []
files = []
hgrepos = []
issue_num = 46872
keywords = []
message_count = 1.0
messages = ['414148']
nosy_count = 1.0
nosy_names = ['bup']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue46872'
versions = []Metadata
Metadata
Assignees
Labels
OS-androidtopic-C-APItype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
Activity
mr-nfamous commentedon Feb 27, 2022
On Android, the following calls generate a SIGSYS signal that is neither blocked by pthread_sigmask(SIG_BLOCK, {SIGSYS}) nor ignored after its handler is set to SIG_IGN:
On the other hand, signal(SIGSYS, lambda s, p: None) will catch the signal, but based on frame it receives (None), I suspect this is a coincidence. Also, the functions with parenthesized names in that list raise the equivalent of OSError(0, "Error", "%s"%args[0]).
mhsmith commentedon Mar 6, 2024
Most of these functions have now been disabled at build time by #115955. The only missing one is
socket.sethostname, which I didn't notice because it isn't available until API level 23, and we're building against level 21. I'll fix that in #116426.