Blend crashes Blender on load. #32069

New Issue

Brian Szepatowski · 2012-07-11T05:50:46+02:00

Brian Szepatowski commented

2012-07-11 05:50:46 +02:00

%%%This object is from a much larger mesh that now crashes blender when trying to load. There is no warning, no crash log, nothing. I checked other parts of the mesh and it seems this is what is causing it from loading.

This blend will load on Blender v2.63a

System:

Blender 2.63 r48820
Win XP SP3
2GB Memory
Single core CPU AMD Athlon 2

Brian%%%

%%%This object is from a much larger mesh that now crashes blender when trying to load. There is no warning, no crash log, nothing. I checked other parts of the mesh and it seems this is what is causing it from loading. This blend will load on Blender v2.63a System: Blender 2.63 r48820 Win XP SP3 2GB Memory Single core CPU AMD Athlon 2 Brian%%%

Brian Szepatowski commented

2012-07-11 05:50:46 +02:00

Changed status to: 'Open'

Brian Szepatowski commented

2012-07-11 05:54:17 +02:00

%%%PS this model started life in Blender 2.48

Brian%%%

%%%PS this model started life in Blender 2.48 Brian%%%

Bastien Montagne commented

2012-07-11 08:26:00 +02:00

%%%Confirmed.

From a quick glance, it seems the problem is caused by a nodal material… But if someone can explain me how such a backtrace is possible, I would be happy!

Program received signal SIGSEGV, Segmentation fault.
0x00000000021e94a2 in dag_add_material_nodetree_driver_relations (dag=<error reading variable: Cannot access memory at address 0x7fffff7fefe8>,

  node=<error reading variable: Cannot access memory at address 0x7fffff7fefe0>, ntree=<error reading variable: Cannot access memory at address 0x7fffff7fefd8>, 
  rootma=<error reading variable: Cannot access memory at address 0x7fffff7fefd0>)
  at /home/i7deb64/blender-2.5-svn/__work__/blender_msgs/source/blender/blenkernel/intern/depsgraph.c:356

356 {
(gdb) up

1 0x00000000021e960c in dag_add_material_driver_relations (dag=0x6c4d7c8, node=0x86ad7b8, ma=0x877a9b8)

  at /home/i7deb64/blender-2.5-svn/__work__/blender_msgs/source/blender/blenkernel/intern/depsgraph.c:393

393 dag_add_material_nodetree_driver_relations(dag, node, ma->nodetree, ma);
(gdb) print dag
$1 = (DagForest *) 0x6c4d7c8
(gdb) print node
$2 = (DagNode *) 0x86ad7b8
(gdb) print ma
$3 = (Material *) 0x877a9b8
(gdb) print ma->nodetree
$4 = (struct bNodeTree *) 0x877b088

…How can a pointer be valid in the caller and invalid in the called func???
%%%

%%%Confirmed. From a quick glance, it seems the problem is caused by a nodal material… But if someone can explain me how such a backtrace is possible, I would be happy! Program received signal SIGSEGV, Segmentation fault. 0x00000000021e94a2 in dag_add_material_nodetree_driver_relations (dag=<error reading variable: Cannot access memory at address 0x7fffff7fefe8>, ``` node=<error reading variable: Cannot access memory at address 0x7fffff7fefe0>, ntree=<error reading variable: Cannot access memory at address 0x7fffff7fefd8>, rootma=<error reading variable: Cannot access memory at address 0x7fffff7fefd0>) at /home/i7deb64/blender-2.5-svn/__work__/blender_msgs/source/blender/blenkernel/intern/depsgraph.c:356 ``` 356 { (gdb) up # 1 0x00000000021e960c in dag_add_material_driver_relations (dag=0x6c4d7c8, node=0x86ad7b8, ma=0x877a9b8) ``` at /home/i7deb64/blender-2.5-svn/__work__/blender_msgs/source/blender/blenkernel/intern/depsgraph.c:393 ``` 393 dag_add_material_nodetree_driver_relations(dag, node, ma->nodetree, ma); (gdb) print dag $1 = (DagForest *) 0x6c4d7c8 (gdb) print node $2 = (DagNode *) 0x86ad7b8 (gdb) print ma $3 = (Material *) 0x877a9b8 (gdb) print ma->nodetree $4 = (struct bNodeTree *) 0x877b088 …How can a pointer be valid in the caller and invalid in the called func??? %%%

Sergey Sharybin commented

2012-07-11 17:40:13 +02:00

%%%Bastien, that's simply stack overflow issue -- no space left in the stack to store function parameters.

Joshua, that's a regression initially introduced in 48515 and later tried to be resolved in 48687. Afraid the only way would be to use LIB_DOIT flag for materials which have been already handled there.%%%

%%%Bastien, that's simply stack overflow issue -- no space left in the stack to store function parameters. Joshua, that's a regression initially introduced in 48515 and later tried to be resolved in 48687. Afraid the only way would be to use LIB_DOIT flag for materials which have been already handled there.%%%

Sergey Sharybin commented

2012-07-12 09:13:36 +02:00

%%%From a second look i could see issues in this area was already reported: http://projects.blender.org/tracker/index.php?func=detail&aid=32017&group_id=9&atid=498

Please move all the feedback there.%%%

%%%From a second look i could see issues in this area was already reported: http://projects.blender.org/tracker/index.php?func=detail&aid=32017&group_id=9&atid=498 Please move all the feedback there.%%%

Sergey Sharybin commented

2012-07-12 09:13:36 +02:00

Changed status from 'Open' to: 'Archived'

Sergey Sharybin closed this issue

2012-07-12 09:13:36 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Blend crashes Blender on load. #32069

1 0x00000000021e960c in dag_add_material_driver_relations (dag=0x6c4d7c8, node=0x86ad7b8, ma=0x877a9b8)