Blender 2.80 - Removing second Particle System cache causes crash #59958

New Issue

artem ivanov · 2018-12-29T16:41:12+01:00

artem ivanov commented

2018-12-29 16:41:12 +01:00

System Information
Operating system: Windows 10
Graphics card: GTX 1070

Blender Version
Broken: 2.80, 7c438e5366, 2018-12-28 23:19, as found on the splash screen (from buildbot)

Short description of error
Changing particle system settings after removing second particle system cache causes crash

Exact steps to reproduce the error

Open Blender
Load Factory Settings
On the default cube: Particle System -> New
Particles tab -> Cache -> click on the "+" sign
Single left click on the added (and therefore selected) cache entry (see screenshot)
Cache -> click on the "-" sign
Change Particles tab -> Emission -> Frame Start to any value (or basically change any current particle system setting)
Crash with EXCEPTION_ACCESS_VIOLATION.

Alternative steps

Open Blender
Load Factory Settings
On the default cube: Particle System -> New
Particles tab -> Cache -> click on the "+" sign
Select the first cache entry
Cache -> click on the "-" sign
Change Particles tab -> Emission -> Frame Start to any value (or basically change any current particle system setting)
Crash with access violation.

Saving file before adding the second cache doesn't affect the crash.

**System Information** Operating system: Windows 10 Graphics card: GTX 1070 **Blender Version** Broken: 2.80, 7c438e5366b2, 2018-12-28 23:19, as found on the splash screen *(from buildbot)* **Short description of error** Changing particle system settings after removing second particle system cache causes crash **Exact steps to reproduce the error** - Open Blender - Load Factory Settings - On the default cube: **Particle System** -> **New** - **Particles** tab -> **Cache** -> click on the "**+**" sign - Single left click on the added (and therefore selected) cache entry (see screenshot) - **Cache** -> click on the "**-**" sign - Change **Particles** tab -> **Emission** -> **Frame Start** to any value (or basically change any current particle system setting) - Crash with `EXCEPTION_ACCESS_VIOLATION`. ![particle_cache.png](https://archive.blender.org/developer/F6107875/particle_cache.png) **Alternative steps** - Open Blender - Load Factory Settings - On the default cube: **Particle System** -> **New** - **Particles** tab -> **Cache** -> click on the "**+**" sign - Select the first cache entry - **Cache** -> click on the "**-**" sign - Change **Particles** tab -> **Emission** -> **Frame Start** to any value (or basically change any current particle system setting) - Crash with access violation. Saving file before adding the second cache doesn't affect the crash.

artem ivanov commented

2018-12-29 16:41:12 +01:00

Added subscriber: @ixd

Sebastian Parborg commented

2019-01-24 13:50:40 +01:00

Added subscriber: @ZedDB

Sebastian Parborg commented

2019-01-24 13:50:40 +01:00

I can't seem to reproduce this on my end. Is this still a problem with the latest blender beta?

artem ivanov commented

2019-01-25 03:02:23 +01:00

@ZedDB Yep. It still crashes for me. Also tested on a different machine running Ubuntu 18.10 x64 - it crashes. More info:

Win 10 (1d908bffdd)
When running blender.exe --debug-all it crashes more rarily (like in 1 of 3 test runs) but here some useful console output (when blender doesn't crash immediately):
Right after 7. Change Particles tab -> Emission -> Frame Start to any value:

Memoryblock cached frames array: double free

and after closing blender:

Error: Not freed memory blocks: 5, total unfreed memory 0.054276 MB
cached frames array len: 252 0000016A1292E308
Pointcache mem len: 176 0000016A133DF0C8
PTCache Data len: 4004 0000016A12FEEAF8
PTCache Data len: 12012 0000016A12E9DDB8
PTCache Data len: 12012 0000016A25CEA718

Blender quit

Ubuntu 18.10 (7f77961f1c)
It doesn't crash after the aforementioned steps, but it does when running with --debug-memory switch.

Output from blender --debug-memory:

Writing: /tmp/blender.crash.txt
Segmentation fault (core dumped)

Content of blender.crash.txt:

# Blender 2.80 (sub 41), Commit date: 2019-01-23 23:36, Hash 7f77961f1c38
bpy.context.space_data.context = 'PARTICLES'  # Property
bpy.ops.object.particle_system_add()  # Operator
bpy.ops.ptcache.add()  # Operator
bpy.context.object.active_index = 1  # Property
bpy.ops.ptcache.remove()  # Operator
bpy.data.particles["ParticleSettings"].count = 1001  # Property
 
# backtrace
./blender(BLI_system_backtrace+0x1d) [0x1ba3afd]
./blender() [0x1156f99]
/lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7f67fa1b3f20]
./blender(BKE_ptcache_free_mem+0x28) [0x197c328]
./blender() [0x196c1f5]
./blender(particle_system_update+0x47e) [0x196d6be]
./blender() [0x163884c]
./blender() [0x184ac92]
./blender() [0x184ba01]
./blender(makeDerivedMesh+0x7b) [0x184db2b]
./blender(BKE_object_handle_data_update+0x128) [0x1947568]
./blender(BKE_object_eval_uber_data+0x2e) [0x1947aee]
./blender() [0x1bc1bbc]
./blender() [0x1ba3ea1]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76db) [0x7f67fb75e6db]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f67fa29688f]

Output from blender --debug-all:

# <click to increase particles count>
Memoryblock PTCacheID: double free
...
# <closing blender>
Error: Not freed memory blocks: 1, total unfreed memory 0.000008 MB
cached frames array len: 4 0x7f4abbb288a8
 
Blender quit

Also clicking on the freshly added cache item increases reported memory consumption:

(e.g.) zero clicks = 18.7 MB
1 click = 18.8 MB
2 = 19.0 MB
3 = 19.1 MB
4 = 19.3 MB

How to reproduce (click to view gif):

@ZedDB Yep. It still crashes for me. Also tested on a different machine running Ubuntu 18.10 x64 - it crashes. More info: **Win 10 (1d908bffddb4)** When running `blender.exe --debug-all` it crashes more rarily (like in 1 of 3 test runs) but here some useful console output (when blender doesn't crash immediately): Right after ***7. Change Particles tab -> Emission -> Frame Start to any value***: ``` Memoryblock cached frames array: double free ``` and after closing blender: ``` Error: Not freed memory blocks: 5, total unfreed memory 0.054276 MB cached frames array len: 252 0000016A1292E308 Pointcache mem len: 176 0000016A133DF0C8 PTCache Data len: 4004 0000016A12FEEAF8 PTCache Data len: 12012 0000016A12E9DDB8 PTCache Data len: 12012 0000016A25CEA718 Blender quit ``` **Ubuntu 18.10 (7f77961f1c38)** It doesn't crash after the aforementioned steps, but it does when running with `--debug-memory` switch. Output from `blender --debug-memory`: ``` Writing: /tmp/blender.crash.txt Segmentation fault (core dumped) ``` Content of `blender.crash.txt`: ``` # Blender 2.80 (sub 41), Commit date: 2019-01-23 23:36, Hash 7f77961f1c38 bpy.context.space_data.context = 'PARTICLES' # Property bpy.ops.object.particle_system_add() # Operator bpy.ops.ptcache.add() # Operator bpy.context.object.active_index = 1 # Property bpy.ops.ptcache.remove() # Operator bpy.data.particles["ParticleSettings"].count = 1001 # Property # backtrace ./blender(BLI_system_backtrace+0x1d) [0x1ba3afd] ./blender() [0x1156f99] /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7f67fa1b3f20] ./blender(BKE_ptcache_free_mem+0x28) [0x197c328] ./blender() [0x196c1f5] ./blender(particle_system_update+0x47e) [0x196d6be] ./blender() [0x163884c] ./blender() [0x184ac92] ./blender() [0x184ba01] ./blender(makeDerivedMesh+0x7b) [0x184db2b] ./blender(BKE_object_handle_data_update+0x128) [0x1947568] ./blender(BKE_object_eval_uber_data+0x2e) [0x1947aee] ./blender() [0x1bc1bbc] ./blender() [0x1ba3ea1] /lib/x86_64-linux-gnu/libpthread.so.0(+0x76db) [0x7f67fb75e6db] /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f67fa29688f] ``` --- Output from `blender --debug-all`: ``` # <click to increase particles count> Memoryblock PTCacheID: double free ... # <closing blender> Error: Not freed memory blocks: 1, total unfreed memory 0.000008 MB cached frames array len: 4 0x7f4abbb288a8 Blender quit ``` --- Also clicking on the freshly added cache item increases reported memory consumption: ``` (e.g.) zero clicks = 18.7 MB 1 click = 18.8 MB 2 = 19.0 MB 3 = 19.1 MB 4 = 19.3 MB ``` --- How to reproduce (click to view gif): ![ptcache.gif](https://archive.blender.org/developer/F6395412/ptcache.gif)

Sebastian Parborg commented

2019-01-25 10:57:21 +01:00

I can reproduce this on 7f77961f1c.

However, I couldn't yesterday and not today either with the latest commit. So I'm guessing this was fixed sometime yesterday (and my build that I tested with was new enough to have this fix in).

Could you see if you can reproduce this again (on both linux and windows) with the current builds from the build bot?

I can reproduce this on 7f77961f1c38. However, I couldn't yesterday and not today either with the latest commit. So I'm guessing this was fixed sometime yesterday (and my build that I tested with was new enough to have this fix in). Could you see if you can reproduce this again (on both linux and windows) with the current builds from the build bot?

Sebastian Parborg commented

2019-01-25 11:30:08 +01:00

Wait, now I'm getting this still on the latest commit :S
Why couldn't I trigger this before I rolled back to the commit you listed...

Ugh, anyways. I can reproduce this on my side with the latest commit.

Wait, now I'm getting this still on the latest commit :S Why couldn't I trigger this before I rolled back to the commit you listed... Ugh, anyways. I can reproduce this on my side with the latest commit.

Bastien Montagne was assigned by Sebastian Parborg

2019-01-25 11:59:02 +01:00

Sebastian Parborg commented

2019-01-25 11:59:02 +01:00

Added subscriber: @mont29