← Back to team overview

kicad-developers team mailing list archive

Re: GAL canvas deadlock

 

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 <seth@xxxxxxxxxxxxx> wrote:
> 
> Hi Jeff-
> 
> Am Fr., 12. Okt. 2018 um 13:46 Uhr schrieb Jeff Young <jeff@xxxxxxxxx <mailto:jeff@xxxxxxxxx>>:
> 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


Follow ups

References