Page MenuHome

Crash with new Datablock ID Properties
Closed, ResolvedPublic


Short description of error
Blender crashes when an object with the new Datablock ID Properties a7b3047cefcb references itself or when two objects reference each other.

Exact steps for others to reproduce the error

  • Open default scene (Camera, Cube, Lamp) or use the attached .blend
  • Run this script:
import bpy

bpy.types.Object.prop = bpy.props.PointerProperty(type=bpy.types.Object)

cube =['Cube']
lamp =['Lamp']
camera =['Camera']

# init the props so we can edit them in the Custom Properties panel
cube.prop = camera
lamp.prop = camera
  • Now this scene can lead to two crashes I discovered so far:
    • Crash 1:
      • select cube, choose Lamp from prop dropdown in Custom Properties
      • select lamp, choose Cube from prop dropdown in Custom Properties
      • crash
    • Crash 2:
      • select cube, choose Cube from prop dropdown in Custom Properties
      • crash

Edit: Important detail I forgot:
It only happens when setting the prop value by hand, not when it is done in Python.
The Python script can't trigger the crash, for example this line works (while it crashes when done by hand):

cube.prop = cube

System Information
Linux 64 bit (Ubuntu 14.04)

Blender Version
Broken: 2.78 575d641 (says the splashscreen, I built from Blender master, so it's 2.79dev)

Event Timeline

Aaron Carlisle (Blendify) lowered the priority of this task from 90 to 50.Apr 13 2017, 9:38 PM

I've found the reason for this crash, and also found forward compatibility issue. I'm working on it.

The reason of crash is infinite recursion, which happens in RNA_pointer_as_string.
I've also found python crash if you will try to remove the custom property pressing "-" button.
This is my solution for these two issues: P464

And one issue with forward compatibility, which I couldn't solve yet:
crash inside

PropertyType RNA_property_type(PropertyRNA *prop)
	return rna_ensure_property(prop)->type;

rna_ensure_property always returns NULL for IDP_ID for Blender builds before D113. This crash happens for me only when I'm opening "Custom Properties" panel.
@Bastien Montagne (mont29), could you help please?

Possible solution for forward compatibility issue: P465

@Alexander Romanov (a.romanov) mostly fine with P464 (rna part of it at least, not convinced by python changes there).

But P465 is a no-go for me, imho it is totally unacceptable to twist that way our .blend file just to ensure forward compat (not to mention how evil it is to change actual data, even if only for a few micro seconds, in writefile!). I’m tempted to consider this a bug in previous blender (if a function can return NULL and is not checked, then bug is in code using it). Can only think about protecting against this for future (e.g. by nuking IDProps of unknown type at read time, keeping them around is call for issues anyway at some point)… Would not mind @Sergey Sharybin (sergey) or @Campbell Barton (campbellbarton) input here though.

@Alexander Romanov (a.romanov) aaaah oki, see the issue now. But this -remove property' button makes absolutely no sense for API-defined IDProps! Nuked it in rB42c8d93c5f433e980c3. ;)

So you can commit the RNA part of P464.

For the forward compat issue, we need advice from other devs. ;)

@Bastien Montagne (mont29), we indeed should not modify anything from the main database during file save. This was known for giving issues in the past. What i remember happening at some point is that we were constructing temp copy of the objects and made modifications on those. Need to be careful tho, because that will modify pointers of the struct itself.

@Sergey Sharybin (sergey) yes, temp structs is the way to go here - while keeping orig pointer one as 'uuid' (pointer value in file), to ensure re-allocating temp memory later in write process does not re-use same mem pointer…

But that’s not the main issue here, main issue is that P465 horribly tweaks IDProps to save them in a way that new pointer IDProps do not make older blender crash when loading a file saved with those new properties. Imho this is not really acceptable, especially since the root of the issue remains - should we introduce a new IDProp type in the future, it will again make older Blender crash. So to me this is a bug in current code, that is trivial to fix (e.g. by removing any unknown IDProp type at read time), but we should not try to fix this for previous versions… As ugly as it is :(