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

Allow to set custom function attributes in BPS tree #11

Open
rtsisyk opened this issue Oct 25, 2016 · 0 comments
Open

Allow to set custom function attributes in BPS tree #11

rtsisyk opened this issue Oct 25, 2016 · 0 comments
Milestone

Comments

@rtsisyk
Copy link
Contributor

rtsisyk commented Oct 25, 2016

I want to add "static inline" to BPS tree declaration:

000000000044c50c T vy_mem_tree_approximate_count
000000000044b1a3 T vy_mem_tree_build
000000000044b0e9 T vy_mem_tree_create
00000000004537c8 T vy_mem_tree_delete
000000000044b81f T vy_mem_tree_destroy
000000000044ca02 T vy_mem_tree_find
00000000004536f6 T vy_mem_tree_insert
000000000044bcf0 T vy_mem_tree_invalid_iterator
000000000044bef9 T vy_mem_tree_iterator_are_equal
000000000044c9d4 T vy_mem_tree_iterator_destroy
000000000044c082 T vy_mem_tree_iterator_first
000000000044c979 T vy_mem_tree_iterator_freeze
000000000044c77d T vy_mem_tree_iterator_get_elem
000000000044bd4a T vy_mem_tree_iterator_is_invalid
000000000044c0e3 T vy_mem_tree_iterator_last
000000000044c7cf T vy_mem_tree_iterator_next
000000000044c8a8 T vy_mem_tree_iterator_prev
000000000044c144 T vy_mem_tree_lower_bound
000000000044b850 T vy_mem_tree_mem_used
000000000044b91e T vy_mem_tree_random
000000000044b83e T vy_mem_tree_size
000000000044c317 T vy_mem_tree_upper_bound
@kyukhin kyukhin added this to the wishlist milestone Oct 15, 2021
nshy added a commit to nshy/small that referenced this issue Jun 16, 2023
…troy

It currently breaks Tarantool debug runs. For example on running
'box/box/reconfigure.test':

    tarantool#5  0x00007fed360483d6 in __assert_fail (
        assertion=0x556b5a6c883d "lessor->leased == 0",
        file=0x556b5a6c87e8 "./src/lib/small/include/small/quota_lessor.h", line=104,
        function=0x556b5a6c99a0 <__PRETTY_FUNCTION__.15> "quota_lessor_destroy")
        at assert.c:101
    tarantool#6  0x0000556b5a1d46ca in quota_lessor_destroy (
        lessor=0x556b5a84a368 <main_cord+328>)
        at /home/shiny/dev/tarantool/src/lib/small/include/small/quota_lessor.h:104
    tarantool#7  0x0000556b5a1d4aee in slab_cache_destroy (cache=0x556b5a84a368 <main_cord+328>)
        at /home/shiny/dev/tarantool/src/lib/small/include/small/slab_cache_malloc.h:142
    tarantool#8  0x0000556b5a1db974 in cord_destroy (cord=0x556b5a84a220 <main_cord>)
        at /home/shiny/dev/tarantool/src/lib/core/fiber.c:1716
    tarantool#9  0x0000556b5a1dd793 in fiber_free ()
        at /home/shiny/dev/tarantool/src/lib/core/fiber.c:2052
    tarantool#10 0x0000556b59f3b2ac in tarantool_free ()
        at /home/shiny/dev/tarantool/src/main.cc:600
    tarantool#11 0x0000556b59f3c01f in main (argc=3, argv=0x556b5b35b0e8)
        at /home/shiny/dev/tarantool/src/main.cc:875

Looks like Tarantool has leaks of memory allocated thru mempool/small
allocators and misses destruction calls for these objects slab (it use
same quota as slab cache and cleanup quota on destruction).

Memory leak investigation is currently not easy task. We have a wide
range of suppressions that may hide positive cases like in this test.
Disabling suppresion is not possible as test-run stops to work due to
Tarantool breaks on FP leaks.

*TODO* add ticket reference.
nshy added a commit to nshy/small that referenced this issue Jun 21, 2023
…troy

It currently breaks Tarantool debug runs. For example on running
'box/box/reconfigure.test':

    tarantool#5  0x00007fed360483d6 in __assert_fail (
        assertion=0x556b5a6c883d "lessor->leased == 0",
        file=0x556b5a6c87e8 "./src/lib/small/include/small/quota_lessor.h", line=104,
        function=0x556b5a6c99a0 <__PRETTY_FUNCTION__.15> "quota_lessor_destroy")
        at assert.c:101
    tarantool#6  0x0000556b5a1d46ca in quota_lessor_destroy (
        lessor=0x556b5a84a368 <main_cord+328>)
        at /home/shiny/dev/tarantool/src/lib/small/include/small/quota_lessor.h:104
    tarantool#7  0x0000556b5a1d4aee in slab_cache_destroy (cache=0x556b5a84a368 <main_cord+328>)
        at /home/shiny/dev/tarantool/src/lib/small/include/small/slab_cache_malloc.h:142
    tarantool#8  0x0000556b5a1db974 in cord_destroy (cord=0x556b5a84a220 <main_cord>)
        at /home/shiny/dev/tarantool/src/lib/core/fiber.c:1716
    tarantool#9  0x0000556b5a1dd793 in fiber_free ()
        at /home/shiny/dev/tarantool/src/lib/core/fiber.c:2052
    tarantool#10 0x0000556b59f3b2ac in tarantool_free ()
        at /home/shiny/dev/tarantool/src/main.cc:600
    tarantool#11 0x0000556b59f3c01f in main (argc=3, argv=0x556b5b35b0e8)
        at /home/shiny/dev/tarantool/src/main.cc:875

Looks like Tarantool has leaks of memory allocated thru mempool/small
allocators and misses destruction calls for these objects slab (it use
same quota as slab cache and cleanup quota on destruction).

Memory leak investigation is currently not easy task. We have a wide
range of suppressions that may hide positive cases like in this test.
Disabling suppresion is not possible as test-run stops to work due to
Tarantool breaks on FP leaks.

*TODO* add ticket reference.
nshy added a commit to nshy/small that referenced this issue Jun 29, 2023
…troy

It currently breaks Tarantool debug runs. For example on running
'box/box/reconfigure.test':

    tarantool#5  0x00007fed360483d6 in __assert_fail (
        assertion=0x556b5a6c883d "lessor->leased == 0",
        file=0x556b5a6c87e8 "./src/lib/small/include/small/quota_lessor.h", line=104,
        function=0x556b5a6c99a0 <__PRETTY_FUNCTION__.15> "quota_lessor_destroy")
        at assert.c:101
    tarantool#6  0x0000556b5a1d46ca in quota_lessor_destroy (
        lessor=0x556b5a84a368 <main_cord+328>)
        at /home/shiny/dev/tarantool/src/lib/small/include/small/quota_lessor.h:104
    tarantool#7  0x0000556b5a1d4aee in slab_cache_destroy (cache=0x556b5a84a368 <main_cord+328>)
        at /home/shiny/dev/tarantool/src/lib/small/include/small/slab_cache_malloc.h:142
    tarantool#8  0x0000556b5a1db974 in cord_destroy (cord=0x556b5a84a220 <main_cord>)
        at /home/shiny/dev/tarantool/src/lib/core/fiber.c:1716
    tarantool#9  0x0000556b5a1dd793 in fiber_free ()
        at /home/shiny/dev/tarantool/src/lib/core/fiber.c:2052
    tarantool#10 0x0000556b59f3b2ac in tarantool_free ()
        at /home/shiny/dev/tarantool/src/main.cc:600
    tarantool#11 0x0000556b59f3c01f in main (argc=3, argv=0x556b5b35b0e8)
        at /home/shiny/dev/tarantool/src/main.cc:875

Looks like Tarantool has leaks of memory allocated thru mempool/small
allocators and misses destruction calls for these objects slab (it use
same quota as slab cache and cleanup quota on destruction).

Memory leak investigation is currently not easy task. We have a wide
range of suppressions that may hide positive cases like in this test.
Disabling suppresion is not possible as test-run stops to work due to
Tarantool breaks on FP leaks.

*TODO* add ticket reference.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants