Page MenuHome

Blender 2.8: Crash shortly after using the "Offset edge loop cut" tool
Closed, ResolvedPublic


System Information
Win 10 nVidia Quadro 600

Blender Version
Broken: 2.8 664865680a6

Short description of error
I'm not able to provide a .blend because as soon as I save/re-load, the problem fixes itself.

There seems to be some badness around the "Offset edge loop cut" tool as the mesh becomes corrupted after use -- leading to crashes for some operators.

Exact steps for others to reproduce the error

  • Go into edit mode for the default cube
  • Make a CTRL-R loop cut down the middle and immediately confirm
  • With that loop still selected: hit CTRL-SHIFT-R, drag a little, then confirm
  • Select entire mesh with A (notice object looks corrupted at this point)
  • Hit SHIFT-N to recalc normals... crash
blender.exe!abort() Line 61	C++
blender.exe!recalc_face_normals_find_index(BMesh * bm, BMFace * * faces, const int faces_len, bool * r_is_flip) Line 115	C
blender.exe!bmo_recalc_face_normals_array(BMesh * bm, BMFace * * faces, const int faces_len, const short oflag) Line 209	C
blender.exe!bmo_recalc_face_normals_exec(BMesh * bm, BMOperator * op) Line 294	C
blender.exe!BMO_op_exec(BMesh * bm, BMOperator * op) Line 225	C
blender.exe!EDBM_op_callf(BMEditMesh * em, wmOperator * op, const unsigned char * fmt, ...) Line 219	C
blender.exe!edbm_normals_make_consistent_exec(bContext * C, wmOperator * op) Line 2103	C
blender.exe!wm_operator_invoke(bContext * C, wmOperatorType * ot, wmEvent * event, PointerRNA * properties, ReportList * reports, const bool poll_only, bool use_last_properties) Line 1331	C

Event Timeline

Bastien Montagne (mont29) triaged this task as Needs Information from User priority.

Cannot confirm that with current branch, might have already been fixed, can you please try again with latest build?

Ah, ok, this is a debug assert triggering which is perhaps why you didn't see the crash. Happens on latest git pull from the blender2.8 branch still.

The line in question is


in the recalc_face_normals_find_index function.

If I comment that line out, things will work. The mesh still looks broken as soon as you select-all before re-calc normals; so it seems like the assert has served a purpose I think.

Hmpf, release builds should not abort on assert… but anyway… we need to be able to reproduce that, please attach a corrupted .blend

This comment was removed by Roger B (rboxman).

Rebuilt from scratch after my previous comment to know for sure. But I can repro OP's issue when using a Debug build (compiled from source) which allows the assert to hit. I was also unsuccessful in creating a repro .blend; the act of saving and then re-loading the .blend seems to fix the issue. Perhaps the mesh loop/normal data is not being updated correctly after one of the operators but is being updated on .blend load?

I followed the same repro steps using today git. GIF here:

Still cannot reproduce with current 2.8 branch… Note that I fixed a case that could compute invalid normals for faces yesterday, so might be worth re-trying and see whether you still can reproduce now?

Yes, I can still reproduce here. My repro steps look just like the gif above from rboxman. Are you using a debug build? Is there anything I can do to help debug - like adding additional trace statements in the code path etc?

Yes am using a debug build. But you're on windows, and am on linux, since we are dealing with floats and epsilon values here, could just be a precision difference between compilers…

Here I tried reducing epsilon of BM_face_is_normal_valid() from 1e-4 to 1e-9, still could not trigger the assert…
I’d suggest you break into that function, and check values between f->no and computed no. If they are very similar, then maybe epsilon is not high enough on windows for some reason. If they are totally different, then issue is somewhere else.

Could be some threading stuff, starting blender from command line with -t 1 option could be worth testing then.

Alright, started with: --factory-startup -t 1
f->no == (0,0,0)
no == (0,0,1)

Many of the 18 faces of the resulting cube seem to have no face normals set:

faces[0]->no	0x000001bdc8a8788c {0.000000000, 0.000000000, 0.000000000}	float[3]
faces[1]->no	0x000001bdc8a8796c {0.000000000, 0.000000000, 0.000000000}	float[3]
faces[2]->no	0x000001bdc8a87934 {0.000000000, 0.000000000, 0.000000000}	float[3]
faces[3]->no	0x000001bdc8a87b64 {0.000000000, 0.000000000, -1.00000000}	float[3]
faces[4]->no	0x000001bdc8a87b9c {-1.00000000, -0.000000000, 0.000000000}	float[3]
faces[5]->no	0x000001bdc8a878c4 {0.000000000, -1.00000000, 0.000000000}	float[3]
faces[6]->no	0x000001bdc8a87a14 {0.000000000, 0.000000000, 0.000000000}	float[3]
faces[7]->no	0x000001bdc8a878fc {0.000000000, 0.000000000, 0.000000000}	float[3]
faces[8]->no	0x000001bdc8a87c0c {-1.00000000, -0.000000000, 0.000000000}	float[3]
faces[9]->no	0x000001bdc8a879a4 {0.000000000, 1.00000000, 0.000000000}	float[3]
faces[10]->no	0x000001bdc8a87b2c {1.00000000, -0.000000000, 0.000000000}	float[3]
faces[11]->no	0x000001bdc8a87abc {0.000000000, -0.000000000, 1.00000000}	float[3]
faces[12]->no	0x000001bdc8a87bd4 {0.000000000, 0.000000000, -1.00000000}	float[3]
faces[13]->no	0x000001bdc8a87af4 {1.00000000, -0.000000000, 0.000000000}	float[3]
faces[14]->no	0x000001bdc8a879dc {0.000000000, 0.000000000, 0.000000000}	float[3]
faces[15]->no	0x000001bdc8a87c44 {0.000000000, -0.000000000, 1.00000000}	float[3]
faces[16]->no	0x000001bdc8a87a4c {0.000000000, 0.000000000, 0.000000000}	float[3]
faces[17]->no	0x000001bdc8a87a84 {0.000000000, 0.000000000, 0.000000000}	float[3]
Bastien Montagne (mont29) raised the priority of this task from Needs Information from User to Normal.

Welllllll… am kind of speechless here, since I cannot reproduce that… maybe @Campbell Barton (campbellbarton) will have an idea?

Campbell Barton (campbellbarton) raised the priority of this task from Normal to Confirmed, Medium.Nov 27 2018, 12:24 AM

Can redo although this is mysterious since transform code ensures normals are updated.

Needs investigation.