Skip to content
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

Clarification on free() and operator delete() without length information #52

Open
LnnrtS opened this issue Sep 29, 2020 · 2 comments
Open
Assignees
Labels

Comments

@LnnrtS
Copy link
Contributor

LnnrtS commented Sep 29, 2020

When using first-fit-top as the default allocator I am seeing memory leaks when using allocating stl objects (like std::vector). The reason is that those objects are calling operator delete without length information. The call basically gets discarded in

estd::pmr::get_default_resource ()->deallocate (ptr, 0);

How is this supposed to work? The only option I see is using a default allocator that can deallocate without being given the size information. But that would rule out using any of the three memory resources provided with micro os.

Or should I always have to specify an allocator when using stl objects, like std::vector<T,allocator_stateless_polymorphic_synchronized<T, scheduler::lockable, get_default_resource>> But what is the use of the definitions of operator delete then?

free() does the same btw

estd::pmr::get_default_resource ()->deallocate (ptr, 0);

@ilg-ul
Copy link
Contributor

ilg-ul commented Sep 29, 2020

Hi @LnnrtS, thank you for raising this issue. It looks like I overlooked some of the details.

The memory allocators will be reworked in the next release of µOS++, to match the new standard definitions. Work is scheduled to start in a few weeks time, after all build tools will be ready.

For now, please feel free to use any workaround that works for you. At first sight I would make a shorter alias of the allocator, and pass it to stl objects.

Please leave this issue open, and let me know your workaround.

Any other comments and suggestions for improving µOS++ are welcomed, here or in the project forum.

@ilg-ul ilg-ul self-assigned this Sep 29, 2020
@LnnrtS
Copy link
Contributor Author

LnnrtS commented Oct 2, 2020

Thank you for your quick response.

I ended up defining my custom container types as the std ones allocator type set to the one provided by µOS++.

Just for curiosity: Could you elaborate a bit more on how the standard definitions changed? I see that std::allocator<T> is still calling operator delete(ptr). So the memory resources need to be changed to remember the size to deallocate for a specific pointer?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants