-
Notifications
You must be signed in to change notification settings - Fork 21
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
Segfaults after accumulating many tracks #167
Comments
Hey, Thanks for the report! I think the prefer fix is is to allow the LinearAllocator to grow. What could be done is just to bump the size and then add the ability to grow. I think this will be pretty rate to happen so it should be fine really (as the realloced LinearAllocator will always be alive the resizing may just happen a very few times) So to outline it: In Would you be willing to do a PR with the fix? (I'm currently in the middle of dealing with a flooded basement so I don't have a setup for it right now :( ) |
I'm a bit preoccupied at the moment, but wanted to at least document the issue upstream before completely forgetting about it, since I already bumped the malloc() here to stop the bleeding. I still want to get the multiclient changes merged upstream so maybe when I'm back on that side of things if this isn't already fixed I'll do that too... Good luck with the flooding! I've helped family with that in the past, sucks. |
Thanks! |
A problem with that simple approach is it would invalidate all the outstanding pointers already handed out via And since the existing API is for the caller to provide the space to It could all be changed to add a new chunk of space when exhausted, chaining to the previous for cleanup handling... but it'll require The only sane thing to do without changing the existing dead-simple API is simply enlarge the malloc(). |
Yeah, that makes sense. Lets just bump the the malloc. |
I'm working on something using Rocket for sequencing that tends to create a lot of tracks during the creative process.
Eventually RocketEditor crashes with a SIGSEGV because of this, despite my system having plenty of memory and a willingness to put up with the cluttered tracks.
Cursory investigation revealed this as the issue:
The LinearAllocator can't grow, and doesn't do a graceful ENOMEM equivalent:
https://github.com/emoon/rocket/blob/master/emgui/src/memory/LinearAllocator.c#L24
The LinearAllocator is created from a relatively small fixed-size heap allocation:
https://github.com/emoon/rocket/blob/master/emgui/src/Emgui.c#L344
Eventually I'd like to get the Rocket protocol to support telling the editor when tracks have been removed, that would reduce the number of tracks my use case accumulates during the iterative creative process. But really, even with stale tracks getting actively removed, I'll probably still hit this bug because I'm exposing more variables as tracks and more scenes in the productions which all have unique track groupings.
Anyways, what's the preferred fix upstream here? Should the LinearAllocator be able to realloc itself gracefully when its exhausted? Or just crank up the static size of the malloc and call it Good Enough?
The text was updated successfully, but these errors were encountered: