Page MenuHome

Sculpt mode drawing leaks memory
Closed, ResolvedPublicBUG

Description

  • Run Blender with -d debug flag.
  • Open this file , exit Blender
  • Error: Not freed memory blocks: 26, total unfreed memory 0.002777 MB
  • Loading the file multiple times increase the number of leaks on exit.

Event Timeline

Campbell Barton (campbellbarton) renamed this task from Sculpt mode leaks memory to Sculpt mode drawing leaks memory.May 8 2020, 1:15 PM

Cant reproduce the leak, but do have some heap use after free: P1376
The leak might be different indication of the same root issue.

This is using blender rB18f833be298 on Linux.

I have similar behavior on Windows 10, but only when addons are enabled:

If addons folder are renamed to something different, no errors appear.

File shouldn't be required.. In sculpting workspace, enable Dyntopo, make a stroke, close file.

Brecht Van Lommel (brecht) changed the task status from Needs Triage to Confirmed.May 9 2020, 10:58 AM
Brecht Van Lommel (brecht) changed the subtype of this task from "Report" to "Bug".

I tried to debug this for quite some time today, but I could not track down the root issue yet... I made some observations along the way though.
It's almost certainly a threading issue. I got many different outputs from asan. Furthermore, it's probably not only one issue, but multiple.

Reproduction steps:

  1. Open file.
  2. Start making brush strokes. Usually, it only takes one or two brush strokes to crash when ASAN is enabled.

SCULPT_pbvh_calc_area_normal causes a warning: member call on address 0x613000adefc0 which does not point to an object of type 'task'. It does not seem to have a big impact, but it still feels like there is something wrong with the way parallel_reduce is used in BKE_pbvh_parallel_range.

Applying P1394 seems to fix all the issues for me. It disables threading in various locations. The patch also disables an unrelated assert, that should not be harmful. Enabling threading only on a single one of those, causes crashes. Depending on which one you enable, the crash looks is different. When more are enabled, it seems to be mostly a matter of luck which function fails first.

I tried to find some shared data that is not properly locked, but could not find any yet. I managed to get it working when I locked smaller code segments in the callbacks, but did not really win any significant insights from that.

This sounds like multiple bugs in a single report? There's many different steps to redo and symptoms here.

The first issue is, does any of this happen in Blender in 2.83? If so, this should probably be a high priority bug. If not, it may be TBB related.

Further, git bisect might help pin down the cause?

Brecht Van Lommel (brecht) claimed this task.

Regarding the various issues reported here: