Page MenuHome

Blender crashes immediately after loading attached file in ~80% of my attempts
Closed, ResolvedPublic

Description

System Information
Operating system: Ubuntu 17.10
Graphics card: Nvidia GeForce GTX 1050

Blender Version
Broken: 2.80, 81ea815dcb6, 2018-12-12
Worked: -

Short description of error
Blender crashes immediately after loading the second file (machin3_2_decals_crash_after_loading.blend)

I have observed the following:

  • Only happens when there are at least 2 mesh decals(textured planes) in the scene. Works fine where there is only one!
  • Mesh decals have material with a parallax node tree. This plays a role, in its absence everything works fine.
  • Mesh decals have a data transfer modifier (custom normals). The viewport visibility prop plays a role. Decals are imported via bpy.data.libarries.load(). When mod visibility is turned off, everything is fine. Also, If I manually toggle the viewport visibility and save, everything will work fine.

Exact steps for others to reproduce the error

  • load machin3_1_decal_loads_fine.blend
    • contains 1 mesh decal + sphere, try loading it multiple times. Should work fine.
  • duplicate selected mesh decal and move it to the side a bit
  • save blend, this is what machin3_2_decals_crash_after_loading.blend is
  • try loading it multiple times, it should crash a lot

I can replicate this with a factory reset Blender too.

Event Timeline

MACHIN3 (MACHIN3) updated the task description. (Show Details)
MACHIN3 (MACHIN3) updated the task description. (Show Details)
MACHIN3 (MACHIN3) renamed this task from Blender crashes immedeately after loading attached file in ~80% of my attempts to Blender crashes immediately after loading attached file in ~80% of my attempts.Dec 13 2018, 10:55 PM

Confirmed on be0c8ed734b on windows. It's intermittent for me too: sometimes it will crash immediately, sometimes I have to revert the file a couple of times, always with an EXCEPTION_ACCESS_VIOLATION error.

Sebastian Parborg (zeddb) lowered the priority of this task from Needs Triage by Developer to Confirmed, Medium.Dec 14 2018, 2:55 PM

I can reproduce this issue too.

This is the backtrace I get:

Thread 1 "blender" received signal SIGSEGV, Segmentation fault.
BKE_mesh_calc_poly_normal (mpoly=0x7fffd8476008, loopstart=0x0, mvarray=0x7fffd843d008, r_no=0x7fffd343c008)
    at /home/zed/programmering/blender_master/blender/source/blender/blenkernel/intern/mesh_evaluate.c:1950
1950			        mvarray[loopstart[3].v].co);
(gdb) bt
#0  BKE_mesh_calc_poly_normal (mpoly=0x7fffd8476008, loopstart=0x0, mvarray=0x7fffd843d008, r_no=0x7fffd343c008)
    at /home/zed/programmering/blender_master/blender/source/blender/blenkernel/intern/mesh_evaluate.c:1950
#1  0x0000555557f6495e in mesh_calc_normals_poly_cb (userdata=0x7fffffffc3f0, pidx=0, UNUSED_tls=0x7fffffffc270)
    at /home/zed/programmering/blender_master/blender/source/blender/blenkernel/intern/mesh_evaluate.c:202
#2  0x00005555583dc495 in parallel_range_single_thread (start=0, stop=726, userdata=0x7fffffffc3f0, func=0x555557f648d9 <mesh_calc_normals_poly_cb>, 
    settings=0x7fffffffc3c0) at /home/zed/programmering/blender_master/blender/source/blender/blenlib/intern/task.c:1064
#3  0x00005555583dc791 in BLI_task_parallel_range (start=0, stop=726, userdata=0x7fffffffc3f0, func=0x555557f648d9 <mesh_calc_normals_poly_cb>, 
    settings=0x7fffffffc3c0) at /home/zed/programmering/blender_master/blender/source/blender/blenlib/intern/task.c:1143
#4  0x0000555557f64f80 in BKE_mesh_calc_normals_poly (mverts=0x7fffd843d008, r_vertnors=0x0, numVerts=728, mloop=0x0, mpolys=0x7fffd8476008, numLoops=2904, 
    numPolys=726, r_polynors=0x7fffd343c008, only_face_normals=true)
    at /home/zed/programmering/blender_master/blender/source/blender/blenkernel/intern/mesh_evaluate.c:308
#5  0x0000555557c44abd in mesh_render_data_ensure_poly_normals_pack (rdata=0x7fffd5274708)
    at /home/zed/programmering/blender_master/blender/source/blender/draw/intern/draw_cache_impl_mesh.c:1176
#6  0x0000555557c4ea42 in mesh_create_pos_and_nor_tess (rdata=0x7fffd5274708, vbo=0x7fffd5139c08, use_hide=false)
    at /home/zed/programmering/blender_master/blender/source/blender/draw/intern/draw_cache_impl_mesh.c:2937
#7  0x0000555557c4f7a3 in mesh_batch_cache_get_tri_pos_and_normals_ex (rdata=0x7fffd5274708, use_hide=false, r_vbo=0x7fffd5385ce8)
    at /home/zed/programmering/blender_master/blender/source/blender/draw/intern/draw_cache_impl_mesh.c:3063
#8  0x0000555557c4f836 in mesh_batch_cache_get_tri_pos_and_normals_final (rdata=0x7fffd5274708, cache=0x7fffd5385c08, use_hide=false)
    at /home/zed/programmering/blender_master/blender/source/blender/draw/intern/draw_cache_impl_mesh.c:3079
#9  0x0000555557c6053e in DRW_mesh_batch_cache_get_surface_shaded (me=0x7fffd8036d08, gpumat_array=0x7fffffffd050, gpumat_array_len=1, use_hide=false, 
    auto_layer_names=0x7fffffffd0d8, auto_layer_is_srgb=0x7fffffffd0e0, auto_layer_count=0x7fffffffd0bc)
    at /home/zed/programmering/blender_master/blender/source/blender/draw/intern/draw_cache_impl_mesh.c:5125
#10 0x0000555557cd9d9a in DRW_cache_mesh_surface_shaded_get (ob=0x7fffeffea608, gpumat_array=0x7fffffffd050, gpumat_array_len=1, use_hide=false, 
    auto_layer_names=0x7fffffffd0d8, auto_layer_is_srgb=0x7fffffffd0e0, auto_layer_count=0x7fffffffd0bc)
    at /home/zed/programmering/blender_master/blender/source/blender/draw/intern/draw_cache.c:3109
#11 0x0000555557cd1dc0 in DRW_cache_object_surface_material_get (ob=0x7fffeffea608, gpumat_array=0x7fffffffd050, gpumat_array_len=1, use_hide=false, 
    auto_layer_names=0x7fffffffd0d8, auto_layer_is_srgb=0x7fffffffd0e0, auto_layer_count=0x7fffffffd0bc)
    at /home/zed/programmering/blender_master/blender/source/blender/draw/intern/draw_cache.c:763
#12 0x0000555557cac48b in EEVEE_materials_cache_populate (vedata=0x7fffea1e7608, sldata=0x7fffd4e06d08, ob=0x7fffeffea608, cast_shadow=0x7fffffffd1a7)
    at /home/zed/programmering/blender_master/blender/source/blender/draw/engines/eevee/eevee_materials.c:1529
#13 0x0000555557c9722b in EEVEE_cache_populate (vedata=0x7fffea1e7608, ob=0x7fffeffea608)
    at /home/zed/programmering/blender_master/blender/source/blender/draw/engines/eevee/eevee_engine.c:143
#14 0x0000555557c6b253 in drw_engines_cache_populate (ob=0x7fffeffea608)
    at /home/zed/programmering/blender_master/blender/source/blender/draw/intern/draw_manager.c:1017
#15 0x0000555557c6c4b3 in DRW_draw_render_loop_ex (depsgraph=0x7fffeaee2008, engine_type=0x55555d0c4b20 <DRW_engine_viewport_eevee_type>, ar=0x7fffd501ea48, 
    v3d=0x7fffd5102808, viewport=0x7fffea3f70c8, evil_C=0x7ffff0030288)
    at /home/zed/programmering/blender_master/blender/source/blender/draw/intern/draw_manager.c:1483
#16 0x0000555557c6c0bf in DRW_draw_view (C=0x7ffff0030288) at /home/zed/programmering/blender_master/blender/source/blender/draw/intern/draw_manager.c:1409
#17 0x0000555557190364 in view3d_draw_view (C=0x7ffff0030288, ar=0x7fffd501ea48)
    at /home/zed/programmering/blender_master/blender/source/blender/editors/space_view3d/view3d_draw.c:1334
#18 0x0000555557190414 in view3d_main_region_draw (C=0x7ffff0030288, ar=0x7fffd501ea48)
    at /home/zed/programmering/blender_master/blender/source/blender/editors/space_view3d/view3d_draw.c:1355
#19 0x00005555576442ac in ED_region_do_draw (C=0x7ffff0030288, ar=0x7fffd501ea48)
    at /home/zed/programmering/blender_master/blender/source/blender/editors/screen/area.c:529
#20 0x0000555557049130 in wm_draw_window_offscreen (C=0x7ffff0030288, win=0x7fffd53c8388, stereo=false)
    at /home/zed/programmering/blender_master/blender/source/blender/windowmanager/intern/wm_draw.c:580
#21 0x00005555570496ae in wm_draw_window (C=0x7ffff0030288, win=0x7fffd53c8388)
--Type <RET> for more, q to quit, c to continue without paging--c
    at /home/zed/programmering/blender_master/blender/source/blender/windowmanager/intern/wm_draw.c:712
#22 0x0000555557049bba in wm_draw_update (C=0x7ffff0030288) at /home/zed/programmering/blender_master/blender/source/blender/windowmanager/intern/wm_draw.c:866
#23 0x0000555557046871 in WM_main (C=0x7ffff0030288) at /home/zed/programmering/blender_master/blender/source/blender/windowmanager/intern/wm.c:433
#24 0x00005555570411be in main (argc=1, argv=0x7fffffffdcf8) at /home/zed/programmering/blender_master/blender/source/creator/creator.c:521

@Bastien Montagne (mont29) do you want to take a crack at this?

Hmpf… draw code gets a mesh without MLoop CD layer (among others)… hmrrrrpff…

Just checking to see if there is any update on this. Not expecting a fix before the stable release, just curious.

For my needs, I just keep the Data Transfer mods turned off for now, but I've observed that it's not just loading of files(with the mods enabled) that tends to crash often, but also generally working with the files(with the mods enabled) becomes quite unstable.

Thanks!

Well, looks like this is a threading issue between (presumably) draw code and scene evaluation (aka depsgraph eval), so would like to summon @Sergey Sharybin (sergey) and @Clément Foucault (fclem) here.

If you run Blender with a single thread (-t 1 option in commandline), everything is fine.

Otherwise, draw code (mesh_render_data_create_ex()) is using a mesh which has a valid mloop pointer, but no CD_MLOOP corresponding layer in its ldata cddata container. While in mesh_calc_modifiers(), both orig mesh (at the beginning) and r_final evaluated one (at the end) have both “loop data” properly set, as expected…

Note that code is failing on drawing MECube here (i.e. the main 'ball', not the smaller 'decals').

I can keep digging in the dark here to try to understand the why of that situation, but wouldn’t mind some enlightenment from devs knowing that code better. E.g., isn’t depsgraph evaluation supposed to happen fully outside of the draw loop? In other words, how can draw code have access to partially updated evaluated data (which seems to be happening here)?

@Bastien Montagne (mont29), scene evaluation is done before the drawing happens. Drawing code shouldn't be calling mesh_calc_modifiers, it should draw what is already evaluated. Same should be true for normals, tangents and so on..

If there is something what draw manager is expecting to have evaluated, this is to be coming from customdata mask on dependency graph nodes (similar to curve paths and DEG_add_customdata_mask).

@Sergey Sharybin (sergey) drawing code is not calling mesh_calc_modifier (afaik). Drawing code is getting an evaluated mesh which, somehow, is missing CD_MLOOP data. This should not happen, ever, and seems to only happen in case of threaded evaluation with several mesh objects…

This data layer is part of 'core' mesh data (the CD_MASK_BAREMESH mask), like polygons etc., those should never have to be cared about in DEG_add_customdata_mask & others, they are assumed to *always* be there, since a surface mesh without them is completely invalid. We have a function (BKE_mesh_update_customdata_pointers) to ensure that both the CD layer and the matching pointer in Mesh struct are kept in sync. In other words, no code should ever generate a mesh without those CDLayers (CD_MVERT, CD_MLOOP, etc.).

Will keep digging tomorrow to try to understand what's happening here…

Note that commit above fixes the crash by preventing forbidden behavior in data transfer modifier, however that one will now be 'broken' regarding normals in some cases (basically, when Mesh's autosmooth of target/source object is not enabled). Proper fix for that is a bit involved, working on it still.