forked from blender/blender
Bastien Montagne
6f625cedf1
Some left-over code from old refactoring/improvements of old addresses remapping in library reading code was causing some wrong remapping between different IDs. The code was actually not doing what its comment was describing, since it would cause a random remapping to a different new address than the expected one: Initial state, before removed buggy line: `old_addr_1 -> new_addr_1` `old_addr_2 -> new_addr_2` End state, if `old_addr_2` == `new_addr_1`: `old_addr_1 -> new_addr_2` `old_addr_2 -> new_addr_2` From the description of the removed line, that behavior was actually already covered by adding the remapping rule in the line above, since adding a remapping overwrite an existing one if needed, so the line above would do (in case a placeholder ID existed before the actual ID got read): Initial state, before adding new remapping rule: `old_addr_1 -> new_addr_placeholder_1` End state, after adding remapping to newly read ID: `old_addr_1 -> new_addr_1` NOTE: Noticed thanks to rare failures of the liboverride tests on buildbots. The issue was less than 1%-reproducible with a debug build and ASAN, but had about 2-4% repducibility with release builds. Pull Request: blender/blender#114784 |
||
|---|---|---|
| .. | ||
| intern | ||
| tests | ||
| BLO_blend_defs.hh | ||
| BLO_blend_validate.hh | ||
| BLO_read_write.hh | ||
| BLO_readfile.h | ||
| BLO_undofile.hh | ||
| BLO_writefile.hh | ||
| CMakeLists.txt | ||