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

Infinite loop in osmium::memory::Buffer::reserve_space #202

Closed
botanegg opened this issue Mar 29, 2017 · 3 comments
Closed

Infinite loop in osmium::memory::Buffer::reserve_space #202

botanegg opened this issue Mar 29, 2017 · 3 comments

Comments

@botanegg
Copy link

I catch an inf loop by simple code using Buffer(size_t capacity, auto_grow auto_grow = auto_grow::yes) ctor

    // reproducing code
    osmium::memory::Buffer node_buffer{0, osmium::memory::Buffer::auto_grow::yes};
    osmium::builder::NodeBuilder builder{node_buffer};

Buffer(size_t capacity, auto_grow auto_grow = auto_grow::yes) uses new unsigned char[capacity] and set m_memory to non-null (that is "valid buffer"), however m_capacity is 0;
Because m_capacity is 0 reserve_space is infinite:

                        size_t new_capacity = m_capacity * 2;
                        while (m_written + size > new_capacity) {
                            new_capacity *= 2;
                        }

Simple fixing m_memory(capacity ? new unsigned char[capacity] : nullptr) leads to assertion

joto added a commit that referenced this issue Mar 31, 2017
This avoids an infinite loop in reserve_space(). See #202.
@joto
Copy link
Member

joto commented Mar 31, 2017

Looks like I didn't expect anybody to choose a zero capacity. This is fixed in 7685449 by using a minimum capacity for the buffer. If you don't want to switch, you can use a non-zero capacity yourself.

@botanegg
Copy link
Author

botanegg commented Apr 4, 2017

Were there any reason to use a growth factor = 2 rather than 1.5 as an example here FBVector.md?

@joto
Copy link
Member

joto commented Apr 4, 2017

@botanegg I didn't think too much about it. The reasoning in FBVector.md is interesting, but I don't think it is particularly important. You don't just allocate one vector/buffer and keep it around a long time, but a typical program will have many of them being allocated and deallocated, etc. So memory can just be reused for something else. Maybe somebody wants to benchmark this?

@joto joto closed this as completed Apr 7, 2017
joto added a commit that referenced this issue Apr 10, 2017
This avoids an infinite loop in reserve_space(). See #202.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants