-
-
Notifications
You must be signed in to change notification settings - Fork 11.1k
ENH: Configurable allocator #17582
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
ENH: Configurable allocator #17582
Changes from 1 commit
55f2f6c
23da73e
94b9f25
81b45fd
fc32c2f
de22327
38274a4
59b520a
5264019
7c396d7
de9001c
9e7c3ed
953cc88
ad9329b
6d10fdb
18bea05
4368023
d243313
c9b6854
a8fd378
a17565b
2ec5912
227c4b8
fb8135d
7291484
c7a9c22
99f8250
b43c1fe
a7a5435
e3723df
144acc6
8539f5f
6ab00d0
e7e8754
5f08532
7266029
5d547ff
4617c50
8f739c4
90205b6
5c0d3f9
3b385d9
e6e12a3
048552d
ad6f8ad
50f8b93
c7438f5
f823ba4
ad13161
0a08acd
1f0301d
3d56aa0
8ea
8000
6818
fb2af4d
f05a1c6
660e0a4
a4f8d71
d7b1a1d
ab1a0eb
b92e36c
76cda3a
3eadf2f
dbe9d73
1bfb870
0511820
23c4bc0
ed8649b
9aacefa
79712fa
a2ae4c0
09b9c0d
efb3c77
2945c64
3a97d9a
1df805c
ef607bd
8bdc9a1
a3256e5
4d6ea65
5941d7c
522c368
442b0e1
8ca8b54
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2039,7 +2039,8 @@ array_setstate(PyArrayObject *self, PyObject *args) | |
} | ||
|
||
if ((PyArray_FLAGS(self) & NPY_ARRAY_OWNDATA)) { | ||
PyDataMem_FREE(PyArray_DATA(self)); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The memory handling in this file ignored There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Eh, github showed my comment twice, but it was only there once... After lots of debugging (first with valgrind, but that only showed me that size 1 (or 0) allocations were added on the cache as larger ones... And annoying, slow and careful stepping through with gdb: At this point the size of the array is already modified, so freeing (and adding to cache) just doesn't work unless you calculate the size earlier (and maybe move the free to an earlier point). This function is a bit weird, maybe it makes sense to NULL data right away? Its likely still buggy, but at least we can't run into a double-free then. |
||
PyDataMem_UserFREE(PyArray_DATA(self), PyArray_NBYTES(self), | ||
PyArray_HANDLER(self)->free); | ||
PyArray_CLEARFLAGS(self, NPY_ARRAY_OWNDATA); | ||
} | ||
Py_XDECREF(PyArray_BASE(self)); | ||
|
@@ -2084,7 +2085,7 @@ array_setstate(PyArrayObject *self, PyObject *args) | |
Py_DECREF(rawdata); | ||
Py_RETURN_NONE; | ||
} | ||
fa->data = PyDataMem_NEW(num); | ||
fa->data = PyDataMem_UserNEW(num, PyArray_HANDLER(fa)->alloc); | ||
if (PyArray_DATA(self) == NULL) { | ||
Py_DECREF(rawdata); | ||
return PyErr_NoMemory(); | ||
|
@@ -2132,7 +2133,7 @@ array_setstate(PyArrayObject *self, PyObject *args) | |
if (num == 0 || elsize == 0) { | ||
Py_RETURN_NONE; | ||
} | ||
fa->data = PyDataMem_NEW(num); | ||
fa->data = PyDataMem_UserNEW(num, PyArray_HANDLER(fa)->alloc); | ||
if (PyArray_DATA(self) == NULL) { | ||
return PyErr_NoMemory(); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should have been
npy_free_cache
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this raises a possible risk in these changes - as I understand it, it didn't matter if the
npy_*_cache
functions were used for the allocation and not the free or vice versa; everything would behave correctly, it would just affect the cache capacity.With the changes in this PR, either:
I suppose as long as our default allocator is happy to accept raw mallocs and frees, this won't actually result in a regression.