Debug build BM_mesh_triangulate() will hang forever if mesh face count is high. #87625

New Issue

YimingWu · 2021-04-19T13:34:54+02:00

YimingWu commented

2021-04-19 13:34:54 +02:00

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

Open 0_rougue_bucket.blend provided below.
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 @PabloDobarro in debug build...

0_rouge_bucket.blend

**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 @PabloDobarro in debug build... [0_rouge_bucket.blend](https://archive.blender.org/developer/F9988596/0_rouge_bucket.blend)

YimingWu commented

2021-04-19 13:34:54 +02:00

Added subscribers: @PabloDobarro, @ChengduLittleA

Ankit Meel commented

2021-04-19 14:00:04 +02:00

Added subscriber: @ankitm

Ankit Meel commented

2021-04-19 14:00:04 +02:00

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.

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.

Dalai Felinto commented

2021-04-19 14:30:39 +02:00

Added subscribers: @Sergey, @dfelinto

Dalai Felinto commented

2021-04-19 14:30:39 +02:00

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

Ankit Meel commented

2021-04-19 14:43:41 +02:00

After 20 minutes, Blender becomes functional again.

Sergey Sharybin commented

2021-04-20 10:10:11 +02:00

@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.

@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 commented

2021-04-22 10:38:40 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Debug build BM_mesh_triangulate() will hang forever if mesh face count is high. #87625