René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"`_interpchannels.create()` debug aborts if channel lock allocation fails","articleBody":"# Crash report\n\n### What happened?\n\n```python\nimport _interpchannels as c\n\nx = []\nwhile True:\n    x.append(c.create())\n```\n\nFor me on a linux aarch64 VM with 2gb RAM, this reliably reproduces either an abort, or an 'Exception ignored' message.\n\n```text\nModules/_interpchannelsmodule.c:443:\nint handle_channel_error(int, PyObject *, int64_t):\nAssertion `PyErr_Occurred()' failed.\nAborted\n```\n\n## LLDB\n\nThe failing assertion occurs in `handle_channel_error()` with `err=-1`, while the channel id argument contains `-7`:\n\n```text\nframe #5: handle_channel_error(err=-1, mod=..., cid=-7)\nframe #6: channelsmod_create(...)\n```\n\n`-7` corresponds to `ERR_CHANNEL_MUTEX_INIT`.\n\nSo the low-level create path correctly identifies the failure, but `channelsmod_create()` passes the wrong value as the error code.\n\n## Root Cause\n\n`channel_create()` returns a a negative error code on failure, but does not always set an exception. The caller, `channelsmod_create` converts the error code to -1 which enters a path that asserts an exception has been raised.\n\nhttps://github.com/python/cpython/blob/0a29d8408cfdd9a66f2b65745a3ae1cda022775c/Modules/_interpchannelsmodule.c#L1745-L1748\n\nIf `PyThread_allocate_lock()` fails, it returns `NULL` but does not set a Python exception:\n\nhttps://github.com/python/cpython/blob/0a29d8408cfdd9a66f2b65745a3ae1cda022775c/Python/thread.c#L86-L91\n\nThen channel_create correctly returns ERR_CHANNEL_MUTEX_INIT:\n\nhttps://github.com/python/cpython/blob/0a29d8408cfdd9a66f2b65745a3ae1cda022775c/Modules/_interpchannelsmodule.c#L1745-L1748\n\n`channelsmod_create()` sees the error code, but passes `-1` to `handle_channel_error`:\n\nhttps://github.com/python/cpython/blob/0a29d8408cfdd9a66f2b65745a3ae1cda022775c/Modules/_interpchannelsmodule.c#L2939-L2943\n\n`handle_channel_error()` then falls through the switch statement because -1 isn't a known error code, resulting in:\n\nhttps://github.com/python/cpython/blob/0a29d8408cfdd9a66f2b65745a3ae1cda022775c/Modules/_interpchannelsmodule.c#L442-L444\n\nThere is a branch for the `-7: ERR_CHANNEL_MUTEX_INIT` error code, but this is not hit because of the `-1`:\n\nhttps://github.com/python/cpython/blob/0a29d8408cfdd9a66f2b65745a3ae1cda022775c/Modules/_interpchannelsmodule.c#L430-L433\n\n## Fix\n\nI'm not an expert in this code, but it seems to me that a reasonable fix here might be to pass cid twice to `handle_channel_error()`, once as the error code and once as the channel id. This would allow `handle_channel_error()` to see the actual error code and handle it appropriately:\n\n```c\nif (cid \u003c 0) {\n    (void)handle_channel_error(cid, self, cid);\n    return NULL;\n}\n```\n\nThis way, `handle_channel_error` picks up the -7 error code from `cid` (already confirmed as \u003c 0) and the switch calls `PyErr_SetString`, rather than `assert(PyErr_Occurred())`.\n\n### CPython versions tested on:\n\nCPython main branch\n\n### Operating systems tested on:\n\nLinux\n\n### Output from running 'python -VV' on the command line:\n\nPython 3.16.0a0 (heads/main-dirty:9751e1d, Jun 29 2026, 14:39:58) [Clang 22.1.6 ]\n\n\u003c!-- gh-linked-prs --\u003e\n### Linked PRs\n* gh-152642\n* gh-152671\n* gh-152672\n* gh-152673\n\u003c!-- /gh-linked-prs --\u003e\n","author":{"url":"https://github.com/stestagg","@type":"Person","name":"stestagg"},"datePublished":"2026-06-29T20:50:49.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":3},"url":"https://github.com/152635/cpython/issues/152635"}