You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The issue was reported multiple times in fb devel list, I will mention here Damyan Ivanov and Stephan Bergmann.
The reason of a bug is related with a method of worker thread shutdown based on semaphore. At the very end of thread code shutdown semaphore is released. Code that initiated worker thread shutdown waits for that semaphore and continues execution when shutdown semaphore is released. That's almost always OK but sometimes thread may get frozen after releasing shutdown semaphore (to make bug reproducible I've emulated this with long cycle after semaphore release) and when it tries to resume dynamic library is already unloaded from RAM causing attempt to execute code at wrong address. That's why we always get blind stacks for a thread which caused segfault.
An obvious way to solve the problem is to wait for thread completion instead of using artificial method with semaphore. Unfortunately it may cause deadlocks on windows due to specifics of runtime libraries - see https://msdn.microsoft.com/ru-ru/library/windows/desktop/dn633971%28v=vs.85%29.aspx for details. Luckily on windows this bug seems to be not reproduced, at least I'm not aware about related bug reports. Therefore I fix posix builds and leave windows case 'as is'.
> Deadlock will happen if wait function is called in library cleanup code.
To be precise - in .exe cleanup code too. Unfortunately, when embedded process exits it's cleanup code which unloads engine.
I agree that something like
if (!weAreInCleanup) WaitForSingleObject(workerThread);
should be useful, just can't experiment with windows builds (therefore word 'posix' in env.field).
Submitted by: @AlexPeshkoff
The issue was reported multiple times in fb devel list, I will mention here Damyan Ivanov and Stephan Bergmann.
The reason of a bug is related with a method of worker thread shutdown based on semaphore. At the very end of thread code shutdown semaphore is released. Code that initiated worker thread shutdown waits for that semaphore and continues execution when shutdown semaphore is released. That's almost always OK but sometimes thread may get frozen after releasing shutdown semaphore (to make bug reproducible I've emulated this with long cycle after semaphore release) and when it tries to resume dynamic library is already unloaded from RAM causing attempt to execute code at wrong address. That's why we always get blind stacks for a thread which caused segfault.
Commits: 40f782a d88c5ac
The text was updated successfully, but these errors were encountered: