Fix unreported Eisenbug leading to a crash when reading a blend file.
This took more than a day to fully investigate and understand, one of the reasons being that the probability of the issue to show up was extremely low, and subjected to very specific random factors. Root of the issue is that, in some very rare cases, a newly read ID might get the exact same memory address as the one it had when the blend file was saved. In that case, `BKE_workspace_active_set` would return immediately, since the pointer to the active workspace would remain unchanged. But that lead to having an unset NULL active layout pointer, which would crash when attempting to get e.g. the active screen. For the record, I ran into this when running a specific build (master with one flag added to the `LIB_ID_CREATE` ones, with value `1 << 3`), using a specific set of options (`--background --factory-startup -noaudio`), and passing the .blend file from T80090 as argument.
This commit is contained in:
parent
84b3f6e049
commit
ebf752625e
|
@ -429,9 +429,13 @@ WorkSpace *BKE_workspace_active_get(WorkSpaceInstanceHook *hook)
|
|||
}
|
||||
void BKE_workspace_active_set(WorkSpaceInstanceHook *hook, WorkSpace *workspace)
|
||||
{
|
||||
if (hook->active == workspace) {
|
||||
return;
|
||||
}
|
||||
/* DO NOT check for `hook->active == workspace` here. Caller code is supposed to do it if
|
||||
* that optimization is possible and needed.
|
||||
* This code can be called from places where we might have this equality, but still want to
|
||||
* ensure/update the active layout below.
|
||||
* Known case where this is buggy and will crash later due to NULL active layout: reading
|
||||
* a blend file, when the new read workspace ID happens to have the exact same memory address
|
||||
* as when it was saved in the blend file (extremely unlikely, but possible). */
|
||||
|
||||
hook->active = workspace;
|
||||
if (workspace) {
|
||||
|
|
Loading…
Reference in New Issue