frequent repeatable crashes when rendering some files #40033

New Issue

bassam kurdali · 2014-05-05T18:18:36+02:00

bassam kurdali commented

2014-05-05 18:18:36 +02:00

System Information
LInux 64bit (fedora 20) Intel CPU, nvidia GPU

Blender Version
Broken: 2.70.? f93bc76,
Worked: 2.70a

Short description of error
Specific Files crash on render

Exact steps for others to reproduce the error
Download the file
Load it (even with factory settings and no autorun python scripts)
press F12
crash!

**System Information** LInux 64bit (fedora 20) Intel CPU, nvidia GPU **Blender Version** Broken: 2.70.? f93bc76, Worked: 2.70a **Short description of error** Specific Files crash on render **Exact steps for others to reproduce the error** Download the [file ](http://urchn.org/tube/a1s48light_packed.blend) Load it (even with factory settings and no autorun python scripts) press F12 crash!

bassam kurdali commented

2014-05-05 18:18:36 +02:00

Changed status to: 'Open'

bassam kurdali commented

2014-05-05 18:18:36 +02:00

Added subscriber: @BassamKurdali

Brecht Van Lommel commented

2014-05-06 13:54:30 +02:00

Added subscribers: @LukasTonne, @brecht

Brecht Van Lommel commented

2014-05-06 13:54:30 +02:00

I can confirm the problem, this file contains an invalid UV Map node in STunnelConcrete_local_fake, and that node type did not exist yet in 2.70a.

What I suspect happened is that this file was saved in a recent git version, and then saved with 2.70a or some other earlier version that did not support the UV Map node. When you do that it seems to crash.

@LukasTonne: node->storage is NULL after this, not sure how best to handle this. Here is a trick to make such nodes with invalid storage undefined, but I'm not sure it's a valid assumption that any node that defines a storage name also needs to have the storage pointer actually set.

P56: (An Untitled Masterwork)

diff --git a/source/blender/blenkernel/intern/node.c b/source/blender/blenkernel/intern/node.c
index 38dd36b..97bcdc0 100644
--- a/source/blender/blenkernel/intern/node.c
+++ b/source/blender/blenkernel/intern/node.c
@@ -172,6 +172,11 @@ static void ntree_set_typeinfo(bNodeTree *ntree, bNodeTreeType *typeinfo)
 
 static void node_set_typeinfo(const struct bContext *C, bNodeTree *ntree, bNode *node, bNodeType *typeinfo)
 {
+	/* for nodes saved in older versions storage can get lost, make undefined then */
+	if (node->flag & NODE_INIT)
+		if (typeinfo && typeinfo->storagename- [x] && !node->storage)
+			typeinfo = NULL;
+
 	if (typeinfo) {
 		node->typeinfo = typeinfo;

I can confirm the problem, this file contains an invalid UV Map node in STunnelConcrete_local_fake, and that node type did not exist yet in 2.70a. What I suspect happened is that this file was saved in a recent git version, and then saved with 2.70a or some other earlier version that did not support the UV Map node. When you do that it seems to crash. @LukasTonne: `node->storage` is `NULL` after this, not sure how best to handle this. Here is a trick to make such nodes with invalid storage undefined, but I'm not sure it's a valid assumption that any node that defines a storage name also needs to have the storage pointer actually set. [P56: (An Untitled Masterwork)](https://archive.blender.org/developer/P56.txt) ``` diff --git a/source/blender/blenkernel/intern/node.c b/source/blender/blenkernel/intern/node.c index 38dd36b..97bcdc0 100644 --- a/source/blender/blenkernel/intern/node.c +++ b/source/blender/blenkernel/intern/node.c @@ -172,6 +172,11 @@ static void ntree_set_typeinfo(bNodeTree *ntree, bNodeTreeType *typeinfo) static void node_set_typeinfo(const struct bContext *C, bNodeTree *ntree, bNode *node, bNodeType *typeinfo) { + /* for nodes saved in older versions storage can get lost, make undefined then */ + if (node->flag & NODE_INIT) + if (typeinfo && typeinfo->storagename- [x] && !node->storage) + typeinfo = NULL; + if (typeinfo) { node->typeinfo = typeinfo; ```

Lukas Tönne commented

2014-05-06 18:46:20 +02:00

Hrrrm, this is nasty. @brecht's observation is correct: This happens when re-saving undefined node types, which are then expected to have full data after loading in more recent versions.

I added some code to prevent loss of undefined nodes when loading files. This happened before pynodes too, but in those days it always meant a version regression, so was fairly safe to simply remove such nodes.

With pynodes an undefined node type can also mean that you defined that node in a script which hasn't been run yet or had some error. In that case you wouldn't want to blatantly remove all the nodes and links, but rather keep a dummy around until the problem is fixed and the types become known.

The difference between the two is the use of bNode->storage data, which only works for classic DNA hardcoded nodes, it cannot be restored for undefined nodes (in principle we could keep a single memory block around, but that would only work in the simplest cases and easily cause trouble with potential future do_versions).

I agree with @brecht's solution, make such nodes undefined so the user can recover from mistakes manually and fix node setups at least. The only other option i think would be deleting such nodes as we did before pynodes, but that is more destructive for no real reason.

Hrrrm, this is nasty. @brecht's observation is correct: This happens when re-saving undefined node types, which are then expected to have full data after loading in more recent versions. I added some code to prevent loss of undefined nodes when loading files. This happened before pynodes too, but in those days it __always__ meant a version regression, so was fairly safe to simply remove such nodes. With pynodes an undefined node type can also mean that you defined that node in a script which hasn't been run yet or had some error. In that case you wouldn't want to blatantly remove all the nodes and links, but rather keep a dummy around until the problem is fixed and the types become known. The difference between the two is the use of bNode->storage data, which only works for classic DNA hardcoded nodes, it cannot be restored for undefined nodes (in principle we could keep a single memory block around, but that would only work in the simplest cases and easily cause trouble with potential future do_versions). I agree with @brecht's solution, make such nodes undefined so the user can recover from mistakes manually and fix node setups at least. The only other option i think would be deleting such nodes as we did before pynodes, but that is more destructive for no real reason.

bassam kurdali commented

2014-05-06 19:24:07 +02:00

thanks both of you! at least this helps me fix the file and go forward.
not sure why the file was opened in an old version - was probably me hoping between computers.

thanks both of you! at least this helps me fix the file and go forward. not sure why the file was opened in an old version - was probably me hoping between computers.

bassam kurdali commented

2014-05-06 19:43:52 +02:00

Cool! removed/fixed: for the record, here were my steps:
1- open the file in 2.70a, remove the node, save out a second version (just in case other compatibility changes would be affected)
2- open the file in master, create a cube with a blank material, link material from cube to the original object with the bad node
3- save and reload the file: now the zero user dangerous material doesn't get saved, so the material browser won't crash blender
4- append the fixed material from step 1 and apply it to the object.

Cool! removed/fixed: for the record, here were my steps: 1- open the file in 2.70a, remove the node, save out a second version (just in case other compatibility changes would be affected) 2- open the file in master, create a cube with a blank material, link material from cube to the original object with the bad node 3- save and reload the file: now the zero user dangerous material doesn't get saved, so the material browser won't crash blender 4- append the fixed material from step 1 and apply it to the object.

blender-admin commented

2014-05-07 11:46:30 +02:00

This issue was referenced by blender/blender-addons-contrib@79c345acc2

This issue was referenced by blender/blender-addons-contrib@79c345acc21b2b82dfdfe6cf4c8606a07c90e434

blender-admin commented

2014-05-07 11:46:30 +02:00

This issue was referenced by 79c345acc2

This issue was referenced by 79c345acc21b2b82dfdfe6cf4c8606a07c90e434

Lukas Tönne commented

2014-05-07 11:53:35 +02:00

Changed status from 'Open' to: 'Resolved'

Lukas Tönne closed this issue

2014-05-07 11:53:35 +02:00

Lukas Tönne commented

2014-05-07 11:53:35 +02:00

Closed by commit 79c345acc2.

Closed by commit 79c345acc2.

bassam kurdali commented

2014-05-07 18:49:38 +02:00

Hey Brecht, Lukas,
Can you reopen the bug?
the same file crashes again, since the following commit:
https://developer.blender.org/rB8b8d5a441f5815e83f83bacf8023e2cc3fbb2a04
somehow Image use alpha causes the file to crash. (with no changes in the file)
reverting to a commit or two earlier (I think it is a freestyle commit) causes the file not to crash again.
cheers,
Bassam

Hey Brecht, Lukas, Can you reopen the bug? the same file crashes again, since the following commit: https://developer.blender.org/rB8b8d5a441f5815e83f83bacf8023e2cc3fbb2a04 somehow Image use alpha causes the file to crash. (with no changes in the file) reverting to a commit or two earlier (I think it is a freestyle commit) causes the file not to crash again. cheers, Bassam

Brecht Van Lommel commented

2014-05-07 19:06:37 +02:00

@BassamKurdali: that crash should be fixed now in {edd78fb3085e}.

bassam kurdali commented

2014-05-07 19:14:27 +02:00

In addition, a bunch of math nodes
are now showing up as undefined
in the material local_tunnel_emit
there are a bunch of simple math nodes
they are all undefined{F87610}

In addition, a bunch of math nodes are now showing up as undefined in the material local_tunnel_emit there are a bunch of simple math nodes they are all undefined{[F87610](https://archive.blender.org/developer/F87610/old_nodes.png)} ![undefined.png](https://archive.blender.org/developer/F87611/undefined.png)

Brecht Van Lommel commented

2014-05-07 19:43:56 +02:00

Changed status from 'Resolved' to: 'Open'

Brecht Van Lommel reopened this issue

2014-05-07 19:43:56 +02:00

Lukas Tönne was assigned by Brecht Van Lommel

2014-05-07 19:43:56 +02:00

blender-admin commented

2014-05-07 20:28:46 +02:00

This issue was referenced by blender/blender-addons-contrib@3a8f1d5d8b

This issue was referenced by blender/blender-addons-contrib@3a8f1d5d8b8a95e9b3750d941fda1f8fcb549518

blender-admin commented