-
Notifications
You must be signed in to change notification settings - Fork 407
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
[bug] memory pool. #786
Comments
if you pass a size to |
That is typo when I extract the pseudo code. As you mentioned, the current kokkos memory pool deallocation does not require the second argument so that it does not matter even if the bufsize does not match. The following code still generates the error.
FYI: the current version of memory pool::deallocate cannot ignore the second argument (it generates compiler error). |
Error message indicates that the pointer is not contained within the pool. |
What does this mean ?
|
This is my test code
|
so,
I suspect these are all related, in particular the MaxBlockSize thing... |
Still wrong.
|
These are definitely bug cases that we'll fix, but please try one more: |
That case does not work either.
Now if I set bufsize = 64 * sizeof(double) = 512, then
However, I still fail if I set bufsize = 65 * sizeof(double) = 520. You probably need to add another unit test that randomly allocate and deallocate within a constraint of max capacity. I saw the unit test with parallel reduce but apparently that test is not enough. |
Thanks @kyungjoo-kim . We'll get to the bottom of this and add a test to prevent it happening again. |
…ize, and superblock size resulted in erroneously "allocating" after the end of the pool.
… block size," Introduced to-be-resolved race condition This reverts commit 4e3c666.
Reverted due to introduction of a memory race condition to be resolved. |
…ize, and superblock size resulted in erroneously "allocating" after the end of the memory pool. Fix DynamicView resize_parallel to abort if the memory pool allocation fails. Fix memory pool race condition when more than one thread attempts to claim an empty superblock for the same block size then the losing thread could mistakenly report that no superblock was available.
there is a bug in memory pool. The following is the error message. The code requested 9480 and the pool clearly has enough space but it returns a NULL pointer.
|
Another bug... When it has 0 allocation, it aborts (it should return a NULL).
|
@kyungjoo-kim this is a closed issue, you need to open a new issue for each new bug. I've moved your comments to #939 and answered them there. |
This simple code
returns
The text was updated successfully, but these errors were encountered: