So we no longer get a deadlock. But the application still crashes when it tries to display the error using DisplayError().
The error is GL_INVALID_FRAMEBUFFER_OPERATION. Wiki states this is: “Given when doing anything that would attempt to read from or write/render to a framebuffer that is not complete.” They have a whole section on what “not complete” means, but it’s all Greek to me. What sort of things might we do when updating the GAL display settings on two GAL canvasses that would leave an incomplete framebuffer? Any ideas on what else to check? Thanks, Jeff. > On 12 Oct 2018, at 22:21, Seth Hillbrand <[email protected]> wrote: > > Hi Jeff- > > Am Fr., 12. Okt. 2018 um 13:46 Uhr schrieb Jeff Young <[email protected] > <mailto:[email protected]>>: > That doesn’t work because the lock/unlock calls are in separate routines > (BeginDrawing() and EndDrawing()). > > Sorry, I was unclear. There are catches for OpenGL failures that do not > unlock the context if the error thrown is not std::runtime_error. I believe > that the locking conflict is triggered here where an error is thrown all the > way up to GAL, bypassing the unlock and leading to deadlock. Adding a > default catch that unlocks the context before re-throwing would fix that > > That’s fundamentally unsafe, so I’m adding lockContext() and unlockContext() > protected methods to the GAL API and a GAL_CONTEXT_LOCKER friend class that > can be created on the stack. BeginDrawing() will ASSERT that the context has > indeed been locked. > > RAII locking is definitely the safest way to go. Lose the stack->lose the > lock. > > -S
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
