-
-
Notifications
You must be signed in to change notification settings - Fork 441
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
Segmentation fault in flecs_get_flattened_target #965
Comments
You can try using the Other than that, my approach is to strip down the application (remove systems / modules / ..) until the issue no longer reproduces. It can take a while, but is useful, as it helps to prove the issue is in Flecs, as opposed to (for example) random memory corruption. |
Thanks, I will try that. The issue happens after using the flatten function, if I skip that then it works fine. Will divide and conquer until it I can provide more info. |
Thank you Sander, the journal feature helped me understand a timing problem with our initialization, and revealed that we are getting callbacks to a system where the query isn't matched, so there shouldn't have been any callback and even though the data provided is full of null pointers, those are correct. The root problem wasn't that flecs provided bad data, it was that a callback was triggered even though it shouldn't. I have not been able to write a test for the issue, but I have been able to resolve this issue by handling our initialization in a better way so it doesn't happen. But that issue which I fixed wasn't the crash in the internals. I'm currently thinking that the crash might be come from that we are adding and removing tags and components on entities which have been flattened, and that this might cause issues? I'm not getting any asserts on it, I'm just getting
Here:
Callstack
The In No entities have been added or removed in the flattened subtree, only tags and components, so if the documentation at https://www.flecs.dev/flecs/group__entity__info.html#gaa15f32a7016cfe84291207e209ba7a1a is true then we are not doing anything which is forbidden. I will continue to debug a bit more. |
I switched to debug instead which enabled asserts in flecs and now got this assert:
Full callstack
|
Edit2: The api tests in debug with journal active finished in 40 minutes with Edit3: Sending stdout to a file meant I only got stderr and that says |
Looks like there are some issues with the journaling addon. I could look into those but it's not high on my priority list since journaling is only used for debugging. I would like to get to the bottom of the crash in the flattening code. All of the flattening tests are running in CI with address sanitizer enabled and they're passing, so the scenario under which this occurs might be hard to find without more context. I'll run a couple of tests with valgrind and see if I can find anything. |
Closing this issue as I don't know the scenario to reproduce and valgrind/sanitizer logs didn't show anything for the tests. Feel free to reopen this issue if you find a reproducer! |
Describe the problem you are trying to solve.
I have a crash in flecs' internals which is deterministic and would like to provide a repro for it without sending a whole game engine and the whole game data. This problem is with stripping down the data into only the things which matters for flecs, like the registered component ids and their sizes, the queries provided by each system, and the created entities and their components and relationships.
I've seen that there is "shapshots" which capture some of this, but I wouldn't get the registered components and the queries for the systems.
Describe the solution you'd like
Advice on how to best gather the data for a reproduction case. Something which makes it easy to create tests which use data which is more involved than what a small unit test normally consist of.
The text was updated successfully, but these errors were encountered: