blender
/
blender
136
406
Fork 589
Code Issues 6.2k Pull Requests 751 Projects 19 Wiki Activity

readfile: Fix 'virtual' issue in memfile case. 

In many cases when reading undo memfile, n the 'restore id from old
main' part of the process, the 'id_old' is not set, which means that
the call to `BKE_main_idmap_insert_id` would try to dereference a `nullptr`.

In practice this is likely not an issue (see comment in code for details),
but at least explicitely check for a nullptr `id_old` pointer.

Would deffer actual cleanup of this area for after 3.5 is branched out.
This commit is contained in:
Bastien Montagne 2023-01-24 17:53:27 +01:00
parent 30b34735e3
commit e56f284843
1 changed files with 13 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
source/blender/blenloader/intern/readfile.cc
View File

@ -3289,11 +3289,23 @@ static BHead *read_libblock(FileData *fd,
* address and inherit recalc flags for the dependency graph. */
ID *id_old = nullptr;
if (fd->flags & FD_FLAGS_IS_MEMFILE) {
/* FIXME `read_libblock_undo_restore` currently often skips setting `id_old` even if there
* would be a valid matching old ID (libraries, linked data, and `IDTYPE_FLAGS_NO_MEMFILE_UNDO`
* id types, at least).
*
* It is unclear whether this is currently an issue:
* * `r_id` is currently only requested by linking code (both independent one, and as part of
* loading .blend file through `read_library_linked_ids`).
* * `main->id_map` seems to always be `nullptr` in undo case at this point.
*
* So undo case does not seem to be affected by this. A future cleanup should try to remove
* most of this related code in the future, and instead assert that both `r_id` and
* `main->id_map` are `nullptr`. */
if (read_libblock_undo_restore(fd, main, bhead, tag, &id_old)) {
if (r_id) {
*r_id = id_old;
}
if (main->id_map != nullptr) {
if (main->id_map != nullptr && id_old != nullptr) {
BKE_main_idmap_insert_id(main->id_map, id_old);
}