Page MenuHome

Crash on opening file
Closed, ResolvedPublic

Description

System Information
Linux Ubuntu 14
nVidia GTX 560 ti

Blender Version
Broken: 2.70b 9e963ae
Worked: 2.71

Short description of error
With the supplied file I get an immediate crash once opening.

Exact steps for others to reproduce the error
Open the attached file in blender (It has been created with version 2.71).

Related Objects

Event Timeline

Hilbert Jonker (hilbert) raised the priority of this task from to 90.
Hilbert Jonker (hilbert) updated the task description. (Show Details)
Hilbert Jonker (hilbert) edited a custom field.

File which crashes blender:

Julian Eisel (Severin) lowered the priority of this task from 90 to 50.Nov 3 2014, 10:50 PM

Hi @Hilbert Jonker (hilbert),
I can confirm the issue. You used an array and a mirror modifier with merging enabled in the file, right? The issue seems to lay somewhere there, but maybe the file is just corrupt.
@Campbell Barton (campbellbarton), maybe you could have a look on this? I tried to provoke a crash like this, by playing with arrays and mirrors, without any "luck".

The file crashes with an invalid read report from adress sanitizer:

=================================================================
==7427== ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fffcf7157f8 at pc 0x229a8ba bp 0x7fffd2185140 sp 0x7fffd2185138
READ of size 8 at 0x7fffcf7157f8 thread T14
    #0 0x229a8b9 in CDDM_merge_verts /home/guest/src/bf-blender/blender/source/blender/blenkernel/intern/cdderivedmesh.c:2970
    #1 0x1caa5b0 in arrayModifier_doArray /home/guest/src/bf-blender/blender/source/blender/modifiers/intern/MOD_array.c:724
    #2 0x1caa6e0 in applyModifier /home/guest/src/bf-blender/blender/source/blender/modifiers/intern/MOD_array.c:745
    #3 0x251ae9b in modwrap_applyModifier /home/guest/src/bf-blender/blender/source/blender/blenkernel/intern/modifier.c:744
    #4 0x22139db in mesh_calc_modifiers /home/guest/src/bf-blender/blender/source/blender/blenkernel/intern/DerivedMesh.c:1777
    #5 0x22174fb in mesh_build_data /home/guest/src/bf-blender/blender/source/blender/blenkernel/intern/DerivedMesh.c:2277
    #6 0x2217d02 in makeDerivedMesh /home/guest/src/bf-blender/blender/source/blender/blenkernel/intern/DerivedMesh.c:2350
    #7 0x257e7ec in BKE_object_handle_update_ex /home/guest/src/bf-blender/blender/source/blender/blenkernel/intern/object.c:3037
    #8 0x266ba03 in scene_update_object_func /home/guest/src/bf-blender/blender/source/blender/blenkernel/intern/scene.c:1369
    #9 0x2e828e2 in task_scheduler_thread_run /home/guest/src/bf-blender/blender/source/blender/blenlib/intern/task.c:138
    #10 0x7ffff4e63b97 in __asan_describe_address ??:?
    #11 0x7ffff257d181 in start_thread /build/buildd/eglibc-2.19/nptl/pthread_create.c:312 (discriminator 2)
    #12 0x7ffff0a4efbc in clone /build/buildd/eglibc-2.19/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:111
0x7fffcf7157f8 is located 8 bytes to the left of 462280-byte region [0x7fffcf715800,0x7fffcf7865c8)
allocated by thread T14 here:
    #0 0x7ffff4e604e5 in calloc ??:?
    #1 0x2f0fe0e in MEM_lockfree_callocN /home/guest/src/bf-blender/blender/intern/guardedalloc/intern/mallocn_lockfree_impl.c:278
    #2 0x2508fd4 in BKE_mesh_vert_poly_map_create /home/guest/src/bf-blender/blender/source/blender/blenkernel/intern/mesh_mapping.c:166
    #3 0x229a06b in CDDM_merge_verts /home/guest/src/bf-blender/blender/source/blender/blenkernel/intern/cdderivedmesh.c:2900
    #4 0x1caa5b0 in arrayModifier_doArray /home/guest/src/bf-blender/blender/source/blender/modifiers/intern/MOD_array.c:724
    #5 0x1caa6e0 in applyModifier /home/guest/src/bf-blender/blender/source/blender/modifiers/intern/MOD_array.c:745
    #6 0x251ae9b in modwrap_applyModifier /home/guest/src/bf-blender/blender/source/blender/blenkernel/intern/modifier.c:744
    #7 0x22139db in mesh_calc_modifiers /home/guest/src/bf-blender/blender/source/blender/blenkernel/intern/DerivedMesh.c:1777
    #8 0x22174fb in mesh_build_data /home/guest/src/bf-blender/blender/source/blender/blenkernel/intern/DerivedMesh.c:2277
    #9 0x2217d02 in makeDerivedMesh /home/guest/src/bf-blender/blender/source/blender/blenkernel/intern/DerivedMesh.c:2350
    #10 0x257e7ec in BKE_object_handle_update_ex /home/guest/src/bf-blender/blender/source/blender/blenkernel/intern/object.c:3037
    #11 0x266ba03 in scene_update_object_func /home/guest/src/bf-blender/blender/source/blender/blenkernel/intern/scene.c:1369
    #12 0x2e828e2 in task_scheduler_thread_run /home/guest/src/bf-blender/blender/source/blender/blenlib/intern/task.c:138
    #13 0x7ffff4e63b97 in __asan_describe_address ??:?
Thread T14 created by T0 here:
    #0 0x7ffff4e55b5b in __interceptor_pthread_create ??:?
    #1 0x2e82cb8 in BLI_task_scheduler_create /home/guest/src/bf-blender/blender/source/blender/blenlib/intern/task.c:185
    #2 0x2e84500 in BLI_task_scheduler_get /home/guest/src/bf-blender/blender/source/blender/blenlib/intern/threads.c:173
    #3 0x266bfa2 in scene_update_objects /home/guest/src/bf-blender/blender/source/blender/blenkernel/intern/scene.c:1481
    #4 0x266c48c in scene_update_tagged_recursive /home/guest/src/bf-blender/blender/source/blender/blenkernel/intern/scene.c:1556
    #5 0x266ca23 in BKE_scene_update_tagged /home/guest/src/bf-blender/blender/source/blender/blenkernel/intern/scene.c:1643
    #6 0xc5c945 in wm_event_do_notifiers /home/guest/src/bf-blender/blender/source/blender/windowmanager/intern/wm_event_system.c:378
    #7 0xc4af1c in WM_main /home/guest/src/bf-blender/blender/source/blender/windowmanager/intern/wm.c:495 (discriminator 1)
    #8 0xc49203 in main /home/guest/src/bf-blender/blender/source/creator/creator.c:1784
    #9 0x7ffff0975ec4 in __libc_start_main /build/buildd/eglibc-2.19/csu/libc-start.c:287
Shadow bytes around the buggy address:
  0x100079edaaa0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x100079edaab0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x100079edaac0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x100079edaad0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x100079edaae0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x100079edaaf0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa[fa]
  0x100079edab00:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100079edab10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100079edab20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100079edab30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100079edab40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:     fa
  Heap righ redzone:     fb
  Freed Heap region:     fd
  Stack left redzone:    f1
  Stack mid redzone:     f2
  Stack right redzone:   f3
  Stack partial redzone: f4
  Stack after return:    f5
  Stack use after scope: f8
  Global redzone:        f9
  Global init order:     f6
  Poisoned by user:      f7
  ASan internal:         fe
==7427== ABORTING

https://developer.blender.org/diffusion/B/browse/master/source/blender/blenkernel/intern/cdderivedmesh.c$2970

The issue seems to be that v_target index is -1, which is generally allowed for the vtargetmap entries, but is not checked in this loop. DM_is_valid does not complain, so i assume the mesh itself is not corrupted.

@Patrice Bertrand (PatB): Could you have a look at this? Thanks!

I will look at it.

The report says:
Broken: 2.70b 9e963ae
Worked: 2.71

Since modified array modifier was introduced in 2.72, I would assume this is not related to new implementation, right ?

I think this is a typo, the commit link says 2.72b instead 2.70

The issue relates to array caps with merge option, caps having a subdivision surface active.

Easy to reproduce: start with default cube, duplicate cube as cube.001, define array modifier on Cube, set merge option, set Cube.001 as start cap / end cap.

Then add a subdivision surface on Cube.001 ==> crash.

For some - unknown at this point - reason, this condition causes the addition of a poly with totloops=0, which thus passes through the all_vertices_merged test:

			bool all_vertices_merged = true;

			for (j = 0; j < mp->totloop; j++, ml++) {
				if (vtargetmap[ml->v] == -1) {
					all_vertices_merged = false;
					break;
				}

A few lines further down, we are using the vertex of the first loop of the poly, while not handling the fact that mp->totloop can be null. A test could easily be added there, but that is not the correct solution.

I need to investigate further.

After further investigations, here's where I am:

The cap object's derived mesh is obtained by

end_cap_dm = get_dm_for_modifier(amd->end_cap, flag);

Which returns a dm where, in the case of subsurf, polys are wrong. For example, the following snippet:

	cap_polys = CDDM_get_polys(cap_dm);
	for (ip = 0; ip < cap_npolys; ip++, cap_polys++) {
		printf("%s: %i, loopstart: %i, totloop: %i\n", __FUNCTION__, ip, cap_polys->loopstart, cap_polys->totloop);
	}

Will show inconsistent polys.

In my original patch, the cap object's dm was obtained by

start_cap_dm = mesh_get_derived_deform(scene, amd->start_cap, CD_MASK_MESH);

Which, does not crash with the crash file, BUT does not apply the cap object's subsurf.

@Campbell Barton (campbellbarton), maybe you know what is the appropriate way of getting the derived mesh with modifiers applied ?

Actually, even though previous versions of Blender did apply the cap object's subsurf if present, it is in most cases not what one would want. For example in the telephone.blend file, there is really no point in having a subsurf on the phone cord's caps BEFORE adding them to the cord. Not only does it give wrong results, but it actually prevents the merge from taking place, because after subsurf, the vertices do are not near enough to be merged. It would be better to add the caps THEN apply the cord's own subsurf.

This makes me think that applying subsurf to caps could be dropped altogether. But I suppose not everyone will agree.

Got it !

At

	/* needed for subsurf so arrays are allocated */
	cap_dm->getVertArray(cap_dm);
	cap_dm->getEdgeArray(cap_dm);
	cap_dm->getNumLoops(cap_dm);
	cap_dm->getNumPolys(cap_dm);

Should be :

	/* needed for subsurf so arrays are allocated */
	cap_dm->getVertArray(cap_dm);
	cap_dm->getEdgeArray(cap_dm);
	cap_dm->getLoopArray(cap_dm);
	cap_dm->getPolyArray(cap_dm);

Probably a typo.