Repository navigation
Bug in PyObject_CopyData leads to incorrect data copying order #143737
Description
Bug report
Bug description:
version: python 3.14.2
/* Objects/abstract.c, function PyObject_CopyData, lines 727~732 */
while (elements--) {
_Py_add_one_to_index_C(view_src.ndim, indices, view_src.shape); /* WRONG: increment before copy */
dptr = PyBuffer_GetPointer(&view_dest, indices);
sptr = PyBuffer_GetPointer(&view_src, indices);
memcpy(dptr, sptr, view_src.itemsize);
}maybe can change to
while (elements--) {
dptr = PyBuffer_GetPointer(&view_dest, indices);
sptr = PyBuffer_GetPointer(&view_src, indices);
memcpy(dptr, sptr, view_src.itemsize);
_Py_add_one_to_index_C(view_src.ndim, indices, view_src.shape);
}I don't know which other versions, besides version 3.14.2, are involved with this code.
CPython versions tested on:
3.14
Operating systems tested on:
Windows
Activity
picnixz commentedon Jan 12, 2026
Please show us a reproducible issue with clear expectations.
a12k commentedon Jan 12, 2026
Guessing this is an off by one error given
_Py_add_one_to_index_Cis called before the firstmemcpy. Would love to see a repro, which should be straightforward to produce @buxingtan.buxingtan commentedon Jan 13, 2026
Sorry, after further debugging and analysis, I've realized that the _Py_add_one_to_index_C function eventually cycles the index back to the start position, ensuring that all data is copied completely. So this is not actually a bug - it's just an unconventional copy order.
buxingtan commentedon Jan 13, 2026
copy order is 1->2->...->N->0, so it can ensure copy completely.
picnixz commentedon Jan 13, 2026
Closing as
not a bugthen. One reason why we cycle back is perhaps because of overlapped or other intricate stuff. Or because of some internal pointer arithmetic.