Why Vec::push giving memory allocation failed, out of memory error?

Question

For example: I have a struct named Item

#[derive(AnchorSerialize, AnchorDeserialize, Clone)]
pub struct Item {
  ...fields
}

and I am storing those items inside a PDA account named UserAccount

#[account]
pub struct UserAccount {
    pub owner: Pubkey,              
    pub items: Vec<Item>,
}

At the account initialization i am setting the account size to MAX_PERMITTED_DATA_INCREASE that means 10240 bytes.At this stage i am able store almost 115 items into the vector without any issue.

I have some logic in place that reallocates another 10240 bytes when there is not enough space to store another item. This part also works fine. At this stage account size is 20480 bytes.

After allocating the space second time,and when try to push new item, i get Program log: Error: memory allocation failed, out of memory. This error doesn't happen after immediate allocation. From my testing it looks like it throws this error randomly, sometimes i am able to push abother 10 items (125 total), some times 20(145 toal) items and after that it gives me this error. This happends after adding few items.

From few other threads i came to know push method allocates the entire account's state, I am not sure what does that mean. If i am within the limit why that would be an issue.

So my question is why this error actually happening , even i have enough space for vector to grow and I think i am within the boundary of heap limit. What actually going on under the hood ?

Edit: Here is the repository demonstrating the issue: https://github.com/Imran-S-heikh/solana-memory-issue

Any Kind of help is really appreciated.

Answer 1

You are running out of memory (heap space) not account space.

After you run the test, check the account (userInfoAddress in your test) with this command solana account %account_pubkey% (local validator must be running) and you will see that the account bytes returned have a lot of unused space (the padding 0s at the end). So there is still space left in the account.

        ...

77c0:   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00   ................
77d0:   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00   ................
77e0:   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00   ................
77f0:   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00   ................

I have run your test and consistently get 496 friends added, I cannot reproduce the situation where "it throws this error randomly", so my answer is based on my results where the behavior is consistent. Although it still runs out of memory faster than you would expect.

Why it's running out of memory is because when you use Vec<T>.push(), it will reallocate memory in a way that is best suited and performant for most use-cases, and since memory reallocation is expensive it often just doubles the memory needed by the Vec<T> just so that it will not have to do a new reallocation too soon. So often your Vec<T> that by your calculations is, say, 100 bytes, will actually take up up to 200 bytes of memory.

So given that Vec<Friend> is 33 bytes * number of friends, the program in my case consistently fails after it added 496 friends. At 496 friends it represents 16368 bytes. At the next .push() it will try to double the Vec size which would now be 32kb+ bytes.

Given that Solana programs are limited to heap size of max 32kb, our Vec<Friends> + other variables in memory easily go over this limit and an error is thrown.

You can see these changes in memory allocation if you add this code to pub fn add_friend() after the .push()

let capacity = ctx.accounts.user_info.friends.capacity();
let size_of_friend = std::mem::size_of::<Friend>();
msg!("Capacity: {}, Size Of Friend: {}, Size: {}", capacity, size_of_friend, capacity * size_of_friend);

Notice how capacity of the Vec changes, with doubling often when it reallocates memory. These are the logs from my local machine.

There are different ways of manually allocating memory for a Vec in Rust, such as Vec::reserve().

PS: I appreciate you adding the git link to reproduce this error.