Crash on isect_ray_seg_v3 due to the v0 and v1 being the same vert #70386

New Issue

Daniel Santana · 2019-09-30T09:47:57+02:00

Daniel Santana commented

2019-09-30 09:47:57 +02:00

System Information
Operating system: Windows-10-10.0.18362 64 Bits
Graphics card: GeForce RTX 2080 SUPER/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 436.30

Blender Version
Broken: version: 2.81 (sub 12), branch: master, commit date: 2019-09-29 19:10, hash: 24be998b98
Worked: (optional)

Short description of error
When moving verts with snap on, sometimes a crash occurs in the isect_ray_seg_v3, due to the same vert address being used by v0 and v1.

Exact steps for others to reproduce the error
blender.exe!isect_ray_seg_v3(const float * ray_origin, const float * ray_direction, const float * v0, const float * v1, float * r_lambda) Line 2120 C
blender.exe!test_projected_edge_dist(const DistProjectedAABBPrecalc * precalc, const float- [x] * clip_plane, const int clip_plane_len, const bool is_persp, const float * va, const float * vb, float * dist_px_sq, float * r_co) Line 1057 C
blender.exe!cb_snap_edge(void * userdata, int index, const DistProjectedAABBPrecalc * precalc, const float- [x] * clip_plane, const int clip_plane_len, BVHTreeNearest * nearest) Line 1141 C

The origin of the pointer "error" starts here.

filee: transform_snap_object.c
function: cb_snap_edge
line 1137

const float *v_pair[2];
data->get_vert_co(vindex[0], &v_pair[0], data->userdata);
data->get_vert_co(vindex[1], &v_pair[1], data->userdata);

Both v_pairs get the same pointer address, which seems a result of some degenerated edge.

Attached production file (nothing critical inside), before any edits on our side, and the source fbx files. It's a SketchUp file imported to 3ds Max and prepared for offline rendering by a third-party, we are only handling the realtime part.
We exported as fbx (by layer) and imported in Blender.
The crash occurs with mix snapping on (vert and edge) when correcting mesh borders so they align perfectly (Object065 with Line002, :D great names), and also cleaning up the very messy mesh, since the target is to have it running as part of a bigger project in Unity ios project.

terreno_000.blend

Estradas.fbx
Edificios_Comuns.fbx
Lago.fbx
Passeios.fbx
Passeios_Comuns.fbx
Terra.fbx
Terra_Comum.fbx

**System Information** Operating system: Windows-10-10.0.18362 64 Bits Graphics card: GeForce RTX 2080 SUPER/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 436.30 **Blender Version** Broken: version: 2.81 (sub 12), branch: master, commit date: 2019-09-29 19:10, hash: `24be998b98` Worked: (optional) **Short description of error** When moving verts with snap on, sometimes a crash occurs in the isect_ray_seg_v3, due to the same vert address being used by v0 and v1. **Exact steps for others to reproduce the error** blender.exe!isect_ray_seg_v3(const float * ray_origin, const float * ray_direction, const float * v0, const float * v1, float * r_lambda) Line 2120 C blender.exe!test_projected_edge_dist(const DistProjectedAABBPrecalc * precalc, const float- [x] * clip_plane, const int clip_plane_len, const bool is_persp, const float * va, const float * vb, float * dist_px_sq, float * r_co) Line 1057 C blender.exe!cb_snap_edge(void * userdata, int index, const DistProjectedAABBPrecalc * precalc, const float- [x] * clip_plane, const int clip_plane_len, BVHTreeNearest * nearest) Line 1141 C The origin of the pointer "error" starts here. filee: transform_snap_object.c function: cb_snap_edge line 1137 ``` const float *v_pair[2]; data->get_vert_co(vindex[0], &v_pair[0], data->userdata); data->get_vert_co(vindex[1], &v_pair[1], data->userdata); ``` Both v_pairs get the same pointer address, which seems a result of some degenerated edge. Attached production file (nothing critical inside), before any edits on our side, and the source fbx files. It's a SketchUp file imported to 3ds Max and prepared for offline rendering by a third-party, we are only handling the realtime part. We exported as fbx (by layer) and imported in Blender. The crash occurs with mix snapping on (vert and edge) when correcting mesh borders so they align perfectly (Object065 with Line002, :D great names), and also cleaning up the very messy mesh, since the target is to have it running as part of a bigger project in Unity ios project. [terreno_000.blend](https://archive.blender.org/developer/F7781586/terreno_000.blend) [Estradas.fbx](https://archive.blender.org/developer/F7781597/Estradas.fbx) [Edificios_Comuns.fbx](https://archive.blender.org/developer/F7781599/Edificios_Comuns.fbx) [Lago.fbx](https://archive.blender.org/developer/F7781603/Lago.fbx) [Passeios.fbx](https://archive.blender.org/developer/F7781604/Passeios.fbx) [Passeios_Comuns.fbx](https://archive.blender.org/developer/F7781605/Passeios_Comuns.fbx) [Terra.fbx](https://archive.blender.org/developer/F7781606/Terra.fbx) [Terra_Comum.fbx](https://archive.blender.org/developer/F7781607/Terra_Comum.fbx)

Daniel Santana commented

2019-09-30 09:47:57 +02:00

Added subscriber: @dgsantana

Campbell Barton commented

2019-09-30 10:04:01 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2019-09-30 10:04:01 +02:00

Could you include a blend file with steps to redo the error?

Philipp Oeser commented

2019-09-30 12:42:31 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2019-09-30 12:42:31 +02:00

Canno really reproduce crashes, but indeed one of the meshes is invalid, you can check/correct with

import bpy
for ob in bpy.data.objects:
    if ob.data is None or ob.type != 'MESH':
        continue
    not_valid = ob.data.validate(verbose=True)
    if not_valid:
        print("not_valid ", ob.name)
    else:
        print("valid ", ob.name)

So it is the Group_2884 object, giving
BKE_mesh_validate_arrays: Mesh select element 0 type 2 index 1335 is larger than data array size 0, resetting selection stack.
(havent checked if this is only related to selection flags?)

Which importer was this imported with? (most of the importers do the mesh validation on import iirc)
Can you check if after running the script above everything works fine?
(generally I dont think we are considering anything a bug that involves degenerate geometry?)

Canno really reproduce crashes, but indeed one of the meshes is invalid, you can check/correct with ``` import bpy for ob in bpy.data.objects: if ob.data is None or ob.type != 'MESH': continue not_valid = ob.data.validate(verbose=True) if not_valid: print("not_valid ", ob.name) else: print("valid ", ob.name) ``` So it is the `Group_2884` object, giving `BKE_mesh_validate_arrays: Mesh select element 0 type 2 index 1335 is larger than data array size 0, resetting selection stack.` (havent checked if this is only related to selection flags?) - Which importer was this imported with? (most of the importers do the mesh validation on import iirc) - Can you check if after running the script above everything works fine? (generally I dont think we are considering anything a bug that involves degenerate geometry?)

Philipp Oeser commented

2019-09-30 12:44:54 +02:00

Ah OK, I see you updated with FBX files, (I tested with terreno_000.blend only) need to check again...

Ah OK, I see you updated with FBX files, (I tested with `terreno_000.blend` only) need to check again...

Daniel Santana commented

2019-09-30 12:52:35 +02:00

It was the standard fbx importer.
Ran the script and got more mesh errors, on other objects.
I believe the problem is with imported non-manifold meshes. Probably who handled the sketchup conversion in 3dsmax, just use "Convert To Poly" on every mesh, and this makes really bad non-manifold meshes that can cause crashes in 3dsMax (in certain conditions). I exported with "Triangulate" turn on, but in most cases, this isn't enough.
I also agreed that this isn't a "bug" since it's caused by bad geometry, but maybe it could be handled in a way to not crash blender :).

It was the standard fbx importer. Ran the script and got more mesh errors, on other objects. I believe the problem is with imported non-manifold meshes. Probably who handled the sketchup conversion in 3dsmax, just use "Convert To Poly" on every mesh, and this makes really bad non-manifold meshes that can cause crashes in 3dsMax (in certain conditions). I exported with "Triangulate" turn on, but in most cases, this isn't enough. I also agreed that this isn't a "bug" since it's caused by bad geometry, but maybe it could be handled in a way to not crash blender :).

Philipp Oeser commented

2019-09-30 13:03:26 +02:00

Marking as "Needs Info from User" until we know if validate fixes the problem (and we have exact instructions on which element to snap where -- because I still cannot reproduce a crash...)

Marking as "Needs Info from User" until we know if validate fixes the problem (and we have exact instructions on **which** element to snap **where** -- because I still cannot reproduce a crash...)

Bastien Montagne commented

2019-10-14 11:49:38 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2019-10-14 11:49:38 +02:00

Changed status from 'Open' to: 'Archived'

Bastien Montagne closed this issue

2019-10-14 11:49:38 +02:00

Bastien Montagne self-assigned this 2019-10-14 11:49:38 +02:00

Bastien Montagne commented

2019-10-14 11:49:38 +02:00

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

Daniel Santana commented

2019-10-15 11:40:58 +02:00

Sorry, but finally got the crash again. This was after leaving edit mode. Focus select, enter edit mode, select vertice, focus zoom, and 'g' to start moving. Attaching screenshot with the vertex that cause the crash and the file (its the same but with more edits).
Crash was again in line 2120 of math_geom.c in the isect_ray_seg_v3.

Vertex that cause the problem in object Object065

Area edit before the crash.

File just before the crash.
terreno_003.blend
Crash use to reproduce crash (I did some edits before the crash).
terreno_003.blend1

Sorry, but finally got the crash again. This was after leaving edit mode. Focus select, enter edit mode, select vertice, focus zoom, and 'g' to start moving. Attaching screenshot with the vertex that cause the crash and the file (its the same but with more edits). Crash was again in line 2120 of math_geom.c in the isect_ray_seg_v3. Vertex that cause the problem in object `Object065` ![image.png](https://archive.blender.org/developer/F7820089/image.png) Area edit before the crash. ![image.png](https://archive.blender.org/developer/F7820092/image.png) File just before the crash. [terreno_003.blend](https://archive.blender.org/developer/F7820085/terreno_003.blend) Crash use to reproduce crash (I did some edits before the crash). [terreno_003.blend1](https://archive.blender.org/developer/F7820088/terreno_003.blend1)

Philipp Oeser commented

2019-10-15 11:44:34 +02:00

Changed status from 'Archived' to: 'Open'

Philipp Oeser reopened this issue

2019-10-15 11:44:34 +02:00

Daniel Santana commented

2019-10-15 11:51:54 +02:00

So the edits I did, were, turn wireframe overlay on.
Video showing the crash ;).
QLoNVacGZF.mp4

So the edits I did, were, turn wireframe overlay on. Video showing the crash ;). [QLoNVacGZF.mp4](https://archive.blender.org/developer/F7820110/QLoNVacGZF.mp4)

Daniel Santana commented

2019-10-15 12:14:49 +02:00

Forgot to say that this was in master at this commit 3cdcd1fa9f0896632b05cc217649ac529f8e2e08 of 15 Oct 2019, 09:27 UTC

Forgot to say that this was in master at this commit `3cdcd1fa9f0896632b05cc217649ac529f8e2e08` of 15 Oct 2019, 09:27 UTC

Philipp Oeser commented

2019-10-15 15:39:07 +02:00

Can confirm now.

Seems like the edge is valid, their verts are somewhat valid [have proper coords], but something is wrong with their BMHeader index [gives -1].

Will check on this...

Can confirm now. Seems like the edge is valid, their verts are somewhat valid [have proper coords], but something is wrong with their BMHeader index [gives -1]. Will check on this...

Daniel Santana commented

2019-10-15 16:03:24 +02:00

Great. Let me know if you need anything.

Philipp Oeser commented

2019-10-15 16:49:34 +02:00

Opening terreno_003.blend1 [without doing edits] I can often repro if I select a vert, then do View > Frame Selected prior to moving, and I can never repro if I dont do this prior [and zoom in "by hand"]
(played with lowering the range of viewport clipping, but that didnt help)

So View > Frame Selected definitely has a role in this, checking further...

Opening `terreno_003.blend1` [without doing edits] I can often repro if I select a vert, then do `View` > `Frame Selected` prior to moving, and I can never repro if I dont do this prior [and zoom in "by hand"] (played with lowering the range of viewport clipping, but that didnt help) So `View` > `Frame Selected` definitely has a role in this, checking further...

Philipp Oeser commented

2019-10-15 17:24:23 +02:00

Added subscriber: @mano-wii

Philipp Oeser commented

2019-10-15 17:24:23 +02:00

Here is the backtrace btw.

running into assert because for the particular vert index is -1 (see above)
BLI_assert failed: /blender/source/blender/bmesh/intern/bmesh_mesh.h:97, BM_vert_at_index(), at '(index >= 0) && (index < bm->totvert)'

1  raise                                                                                    0x7ffff1ae6e35 
2  abort                                                                                    0x7ffff1ad1895 
3  BM_vert_at_index                                            bmesh_mesh.h            97   0x3e8984c      
4  cb_bvert_co_get                                             transform_snap_object.c 955  0x3e8984c      
5  cb_snap_edge                                                transform_snap_object.c 1139 0x3e8a127      
6  bvhtree_nearest_projected_with_clipplane_test_dfs_recursive BLI_kdopbvh.c           2115 0x30381fb      
7  bvhtree_nearest_projected_with_clipplane_test_dfs_recursive BLI_kdopbvh.c           2168 0x303852b      
8  bvhtree_nearest_projected_with_clipplane_test_dfs_recursive BLI_kdopbvh.c           2168 0x303852b      
9  bvhtree_nearest_projected_with_clipplane_test_dfs_recursive BLI_kdopbvh.c           2168 0x303852b      
10 bvhtree_nearest_projected_with_clipplane_test_dfs_recursive BLI_kdopbvh.c           2168 0x303852b      
11 bvhtree_nearest_projected_with_clipplane_test_dfs_recursive BLI_kdopbvh.c           2168 0x303852b      
12 bvhtree_nearest_projected_with_clipplane_test_dfs_recursive BLI_kdopbvh.c           2168 0x303852b      
13 bvhtree_nearest_projected_with_clipplane_test_dfs_recursive BLI_kdopbvh.c           2168 0x303852b      
14 bvhtree_nearest_projected_with_clipplane_test_dfs_recursive BLI_kdopbvh.c           2168 0x303852b      
15 bvhtree_nearest_projected_with_clipplane_test_dfs_recursive BLI_kdopbvh.c           2168 0x303852b      
16 bvhtree_nearest_projected_with_clipplane_test_dfs_recursive BLI_kdopbvh.c           2168 0x303852b      
17 BLI_bvhtree_find_nearest_projected                          BLI_kdopbvh.c           2226 0x30387c5      
18 snapEditMesh                                                transform_snap_object.c 2386 0x3e8dcbd      
19 snapObject                                                  transform_snap_object.c 2454 0x3e8de79      
20 sanp_obj_cb                                                 transform_snap_object.c 2525 0x3e8e127      
21 iter_snap_objects                                           transform_snap_object.c 258  0x3e8825b      
22 snapObjectsRay                                              transform_snap_object.c 2592 0x3e8e1c8      
23 transform_snap_context_project_view3d_mixed_impl            transform_snap_object.c 2896 0x3e8ec33      
24 ED_transform_snap_object_project_view3d_ex                  transform_snap_object.c 2945 0x3e8edca      
25 snapObjectsTransform                                        transform_snap.c        1330 0x3e859da      
26 CalcSnapGeometry                                            transform_snap.c        1057 0x3e84bf9      
27 applySnapping                                               transform_snap.c        505  0x3e836a3      
28 applyTranslation                                            transform.c             5314 0x3e127e3      
29 transformApply                                              transform.c             2757 0x3e0b1da      
30 transform_modal                                             transform_ops.c         429  0x3e799d6

@mano-wii: snapping is your playground: interested? (not sure we are running into precission issues if we zoom in too much?)

Here is the backtrace btw. running into assert because for the particular vert index is -1 (see above) BLI_assert failed: /blender/source/blender/bmesh/intern/bmesh_mesh.h:97, BM_vert_at_index(), at '(index >= 0) && (index < bm->totvert)' ``` 1 raise 0x7ffff1ae6e35 2 abort 0x7ffff1ad1895 3 BM_vert_at_index bmesh_mesh.h 97 0x3e8984c 4 cb_bvert_co_get transform_snap_object.c 955 0x3e8984c 5 cb_snap_edge transform_snap_object.c 1139 0x3e8a127 6 bvhtree_nearest_projected_with_clipplane_test_dfs_recursive BLI_kdopbvh.c 2115 0x30381fb 7 bvhtree_nearest_projected_with_clipplane_test_dfs_recursive BLI_kdopbvh.c 2168 0x303852b 8 bvhtree_nearest_projected_with_clipplane_test_dfs_recursive BLI_kdopbvh.c 2168 0x303852b 9 bvhtree_nearest_projected_with_clipplane_test_dfs_recursive BLI_kdopbvh.c 2168 0x303852b 10 bvhtree_nearest_projected_with_clipplane_test_dfs_recursive BLI_kdopbvh.c 2168 0x303852b 11 bvhtree_nearest_projected_with_clipplane_test_dfs_recursive BLI_kdopbvh.c 2168 0x303852b 12 bvhtree_nearest_projected_with_clipplane_test_dfs_recursive BLI_kdopbvh.c 2168 0x303852b 13 bvhtree_nearest_projected_with_clipplane_test_dfs_recursive BLI_kdopbvh.c 2168 0x303852b 14 bvhtree_nearest_projected_with_clipplane_test_dfs_recursive BLI_kdopbvh.c 2168 0x303852b 15 bvhtree_nearest_projected_with_clipplane_test_dfs_recursive BLI_kdopbvh.c 2168 0x303852b 16 bvhtree_nearest_projected_with_clipplane_test_dfs_recursive BLI_kdopbvh.c 2168 0x303852b 17 BLI_bvhtree_find_nearest_projected BLI_kdopbvh.c 2226 0x30387c5 18 snapEditMesh transform_snap_object.c 2386 0x3e8dcbd 19 snapObject transform_snap_object.c 2454 0x3e8de79 20 sanp_obj_cb transform_snap_object.c 2525 0x3e8e127 21 iter_snap_objects transform_snap_object.c 258 0x3e8825b 22 snapObjectsRay transform_snap_object.c 2592 0x3e8e1c8 23 transform_snap_context_project_view3d_mixed_impl transform_snap_object.c 2896 0x3e8ec33 24 ED_transform_snap_object_project_view3d_ex transform_snap_object.c 2945 0x3e8edca 25 snapObjectsTransform transform_snap.c 1330 0x3e859da 26 CalcSnapGeometry transform_snap.c 1057 0x3e84bf9 27 applySnapping transform_snap.c 505 0x3e836a3 28 applyTranslation transform.c 5314 0x3e127e3 29 transformApply transform.c 2757 0x3e0b1da 30 transform_modal transform_ops.c 429 0x3e799d6 ``` @mano-wii: snapping is your playground: interested? (not sure we are running into precission issues if we zoom in too much?)

Daniel Santana commented

2019-10-15 18:27:12 +02:00

I don't the fully know blender internals, but wouldn't an index -1 correspond to not found? Shouldn't this be handled, and just abort snapping?
From my experience with BVH trees and Octree, precision does indeed make a lot of difference.

I don't the fully know blender internals, but wouldn't an index -1 correspond to not found? Shouldn't this be handled, and just abort snapping? From my experience with BVH trees and Octree, precision does indeed make a lot of difference.

Bastien Montagne was unassigned by Philipp Oeser

2019-10-15 18:43:23 +02:00

Germano Cavalcante self-assigned this 2019-10-15 19:28:05 +02:00

Germano Cavalcante commented

2019-10-15 19:28:05 +02:00

@lichtwerk, I didn't quite understand the steps to reproduce the problem, but from backtrace, putting BM_mesh_elem_index_ensure (em->bm, BM_VERT); before BLI_bvhtree_find_nearest_projected should work.
But I will try a solution without reading the indexes.

@lichtwerk, I didn't quite understand the steps to reproduce the problem, but from backtrace, putting `BM_mesh_elem_index_ensure (em->bm, BM_VERT);` before `BLI_bvhtree_find_nearest_projected` should work. But I will try a solution without reading the indexes.

blender-admin commented

2019-10-15 19:59:16 +02:00

This issue was referenced by cfb6ffd48f

This issue was referenced by cfb6ffd48f77c338628c9546accbafd5c5b4175c

Germano Cavalcante commented

2019-10-15 20:00:03 +02:00

Changed status from 'Open' to: 'Resolved'

Germano Cavalcante closed this issue

2019-10-15 20:00:03 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Crash on isect_ray_seg_v3 due to the v0 and v1 being the same vert #70386