Blender 2.8: Crash shortly after using the "Offset edge loop cut" tool #56872

New Issue

Jesse Yurkovich · 2018-09-22T00:16:59+02:00

Jesse Yurkovich commented

2018-09-22 00:16:59 +02:00

System Information
Win 10 nVidia Quadro 600

Blender Version
Broken: 2.8 664865680a
Worked:

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

**System Information** Win 10 nVidia Quadro 600 **Blender Version** Broken: 2.8 664865680a6 Worked: **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 ```

Jesse Yurkovich commented

2018-09-22 00:16:59 +02:00

Added subscriber: @deadpin

unblockedgamess commented

2018-09-22 19:10:03 +02:00

(Migrated from localhost:3001)

Added subscriber: @unblockedgamess

unblockedgamess commented

2018-09-22 19:10:03 +02:00

(Migrated from localhost:3001)

This comment was removed by @unblockedgamess

*This comment was removed by @unblockedgamess*

Brecht Van Lommel commented

2018-09-22 22:17:30 +02:00

Added subscriber: @brecht

Bastien Montagne commented

2018-09-23 10:30:42 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2018-09-23 10:30:42 +02:00

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

Jesse Yurkovich commented

2018-09-24 09:04:00 +02:00

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

BLI_assert(BM_face_is_normal_valid(faces[i]));

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.

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 ``` BLI_assert(BM_face_is_normal_valid(faces[i])); ``` 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.

Bastien Montagne commented

2018-10-14 20:54:32 +02:00

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

Roger B commented

2018-10-15 21:37:08 +02:00

Added subscriber: @rboxman

Roger B commented

2018-10-15 21:37:08 +02:00

This comment was removed by @rboxman

*This comment was removed by @rboxman*

Roger B commented

2018-10-15 23:08:41 +02:00

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:

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: ![crash.gif](https://archive.blender.org/developer/F5082344/crash.gif)

Bastien Montagne commented

2018-11-21 18:25:50 +01:00

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?

Jesse Yurkovich commented

2018-11-25 01:42:40 +01:00

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?

Bastien Montagne commented

2018-11-26 10:57:01 +01:00

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.

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.

Jesse Yurkovich commented

2018-11-26 11:42:53 +01:00

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]

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 commented

2018-11-26 16:30:51 +01:00

Added subscriber: @ideasman42