-
-
Notifications
You must be signed in to change notification settings - Fork 16
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
hello_sdl demo minor fixes #13
base: master
Are you sure you want to change the base?
Conversation
…execution to a specific scheduler is not needed anymore (anyway it could cause scheduler blocking).
Sorry, I think i mixed this pull request with my previous ones... dummy here!. Trying to see how can I do it correctly. |
It's OK, it will be fine once I merge the other ones. Worst case I can cherry-pick I'm sure. |
After applied all the commits inside this PR, a new segfault issue could appears randomly when destroying renderer. To replicate it, it's enough modify hello_sdl source demo in the following way: loop(State) -> In OSX it segfaults in dtor_Renderer function most of the times it's executed, when invoking enif_release_resource(...); in Windows it's more difficult to replicate, although it happens if you retry it enough times. With some printf debugging it seems that resource pointer to Renderer gets corrupted randomly, usually after SDL_DestroyRenderer call, but less frequently call to NIF_RES_DEP before SDL_DestroyRenderer already shows an invalid pointer. In any case, dtor_Windows never is invoked before the segfault. Funny thing, is that if we avoid invoking loop(#{XXXX}) inside init() function in hello_sdl, this doesn't happens, but really I don't know why. I'll open a new issue if commits are finally merged due to the differences how dtor_XXX works in current master brach (although i'll bet it should be suffering the same issue). EDIT: It seems this is a quite exceptional seg fault, I can only replicate it with the previous example. In usual conditions when something is rendered to the screen I'm not able to replicate it at the moment. it could be some timing issue with SDL2 or with running sdl_events:poll inside a loop when renderer is destroyed just after being initialized. |
…execution to a specific scheduler is not needed anymore (anyway it could cause scheduler blocking). This is from ninenines#13
This is from ninenines#13
…execution to a specific scheduler is not needed anymore (anyway it could cause scheduler blocking). This is from ninenines#13
This is from ninenines#13
…execution to a specific scheduler is not needed anymore (anyway it could cause scheduler blocking). This is from ninenines#13
This is from ninenines#13
Minor fixes around hello_sdl demo.