PS this model started life in Blender 2.48

Brian

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???

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.

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.