-
Notifications
You must be signed in to change notification settings - Fork 35
Unify global umf_ba_pool_t initialization #229
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
Conversation
Initializing the global pool in libumf and in each pool separately led to problems with double initialization when multiple pools were used in a single application (and static libumf). To avoid this problem, use util_init_once inside umf_ba_get_pool instead of having explicit constructor/destructor
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.
LGTM
remove unnecessary &
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.
@igchor There is an issue here. I run ubench with proxy library in LD_PRELOAD:
$ LD_PRELOAD=./lib/libumf_proxy.so ./benchmark/ubench
- The constructor of libumf_proxy.so is called.
- The constructor runs
umfMemoryProviderCreate(umfOsMemoryProviderOps())
that creates the global base allocator no. 1 - The constructor runs
umfPoolCreate(umfJemallocPoolOps())
that creates the global base allocator no. 2 and allocates je_malloc pool inside it. - The benchmark runs and ends.
atexit(umf_ba_destroy_global);
is called and the global base allocator no. 2 is destroyed.- The destructor of libumf_proxy.so is called.
- The destructor of libumf_proxy.so runs
umfPoolDestroy(pool)
and it blows up, because the memory it uses has already been freed in 5)
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.
However I think it should be merged as is, because it fixes the failure of #227 and refined later.
Initializing the global pool in libumf and in each pool separately led to problems with double initialization when multiple pools were used in a single application (and static libumf).
To avoid this problem, use util_init_once inside umf_ba_get_pool instead of having explicit constructor/destructor.
This fixes an issue exposed by: 0c55d8f