Page MenuHome

Debug build BM_mesh_triangulate() will hang forever if mesh face count is high.
Confirmed, NormalPublicKNOWN ISSUE


System Information
Operating system: Xubuntu 20.04
Graphics card: NVidia K5100M

Blender Version

Broken ONLY WITH Debug build: Blender 3.0.0 Alpha (It should have been broken way earlier)
Worked only with Release and 'RelWithDebInfo' build: Blender 3.0.0 Alpha

Short description of error

The call to BM_mesh_triangulate(bm, quad_method, ngon_method, 4, false, NULL, NULL, NULL) does not exit on some bigger meshes. Specifically, it seems to have been stuck inside BM_face_kill(bm, faces_double->link);.

(if you call it with bmesh op and slot_in/out arguments it will run properly)

Exact steps for others to reproduce the error

  1. Open 0_rougue_bucket.blend provided below.
  2. Add -> GPencil -> Scene Line Art OR go into sculpt mode and enable dynatopo (where it uses the same triangulation call).

On my machine the bucket runs fine with subdiv levels 1-2 and above 3 the bug shows. The subdiv value in that file is 3.

Note that the bug is only reproducible in Debug build. Seems that function doesn't like meshes that has face count higher than a certain amount...

My guess would be there's a lot of checks in debug code path in the function, somewhere it reaches a case where the memory pool gets corrupted. It never quits, in the task manager, memory doesn't show any changes at all. (It's way below my 32G system memory so it can't be there being not enough memory).

Since this triangulation call is related to sculpt as well so I'm gonna ask if this happens to @Pablo Dobarro (pablodp606) in debug build...

Event Timeline

It's not stuck as in a lock or a freeze. It's doing the work in the first #ifndef NDEBUG section of BLI_mempool_free.
That explains it being a problem in debug build.

@Sergey Sharybin (sergey) you added this (the NDEBUG code in BLI_mempool_free) 8 years ago. Care to comment on this?

After 20 minutes, Blender becomes functional again.

@Dalai Felinto (dfelinto), clearly that was a way to catch issues with misuse of memory pools, to ensure only addresses from the pool are freed.

You can move the check inside of if (UNLIKELY(mempool_debug_memset)) {(maybe call the flag more explicit). But you should also check that the pool is used properly. The fact that the code shows up in the profiles means that there are a lot of chunks, meaning, pool might not be really saving up on allocations. It might be all fine, but that's what you need to check.

Ankit Meel (ankitm) changed the task status from Needs Triage to Confirmed.Thu, Apr 22, 10:38 AM
Ankit Meel (ankitm) changed the subtype of this task from "Report" to "Known Issue".