Crash when modifying strength of world environment texture #94736

New Issue

Leonard Göttert · 2022-01-08T10:59:23+01:00

Leonard Göttert commented

2022-01-08 10:59:23 +01:00

System Information
Operating system: macOS-12.1-arm64-arm-64bit 64 Bits
Graphics card: Apple M1 Pro Apple 4.1 Metal - 76.3

Blender Version
Broken: version: 3.1.0 Alpha, branch: master, commit date: 2022-01-07 23:28, hash: 741ed5fcd2

Short description of error
When viewing a scene using Viewport Shading with Cycles on Metal, Blender crashes when playing with the Strength value of the World Background Surface.

Exact steps for others to reproduce the error

Open attached .blend file. It just contains a cube and an environment texture on the world background surface.
blender crash.blend
Go into viewport shading mode.
Modify the strength value. The crash happens both using click-dragging as well as repeatedly entering values numerically. It does not always crash immediately, but for me it always crashes within a couple of seconds.

**System Information** Operating system: macOS-12.1-arm64-arm-64bit 64 Bits Graphics card: Apple M1 Pro Apple 4.1 Metal - 76.3 **Blender Version** Broken: version: 3.1.0 Alpha, branch: master, commit date: 2022-01-07 23:28, hash: `741ed5fcd2` **Short description of error** When viewing a scene using Viewport Shading with Cycles on Metal, Blender crashes when playing with the Strength value of the World Background Surface. ![Bildschirmfoto 2022-01-08 um 10.48.28.png](https://archive.blender.org/developer/F12795414/Bildschirmfoto_2022-01-08_um_10.48.28.png) **Exact steps for others to reproduce the error** * Open attached .blend file. It just contains a cube and an environment texture on the world background surface. [blender crash.blend](https://archive.blender.org/developer/F12795845/blender_crash.blend) * Go into viewport shading mode. * Modify the strength value. The crash happens both using click-dragging as well as repeatedly entering values numerically. It does not always crash immediately, but for me it always crashes within a couple of seconds.

Leonard Göttert commented

2022-01-08 10:59:23 +01:00

Added subscriber: @Leonard-Gottert

blender-admin commented

2022-01-08 10:59:23 +01:00

#94912 was marked as duplicate of this issue

Wouter Stomp commented

2022-01-08 12:45:13 +01:00

Added subscriber: @blenderrocket

Wouter Stomp commented

2022-01-08 12:45:13 +01:00

For others to replicate this, you should probably add the exr or pack it in the blend file.

Wouter Stomp commented

2022-01-08 12:51:15 +01:00

I get the same result as you in rendered view.

System Information
Operating system: macOS-12.1-arm64-arm-64bit 64 Bits
Graphics card: Apple M1 Max Apple 4.1 Metal - 76.3

Blender Version
Broken: version: 3.1.0 Alpha, branch: master, commit date: 2022-01-07 23:28, hash: 741ed5fcd2

Crash report:
Crash blender.txt

I get the same result as you in rendered view. **System Information** Operating system: macOS-12.1-arm64-arm-64bit 64 Bits Graphics card: Apple M1 Max Apple 4.1 Metal - 76.3 **Blender Version** Broken: version: 3.1.0 Alpha, branch: master, commit date: 2022-01-07 23:28, hash: `741ed5fcd2` Crash report: [Crash blender.txt](https://archive.blender.org/developer/F12795851/Crash_blender.txt)

Leonard Göttert commented

2022-01-08 12:51:24 +01:00

I packed the exr file into the .blend file and edited the original post.

Michael commented

2022-01-08 17:55:35 +01:00

Added subscribers: @Michael-Jones, @michael64

Michael commented

2022-01-08 17:55:35 +01:00

This is a case of use-after-free error.
One could apply P2707, then build and run Blender with this scene as described
and see the following log messages when reducing the surface strength from 1.000 to 0.900:

reached useful breakpoint site at intern/cycles/device/metal/device_impl.mm:535
generic_free at intern/cycles/device/metal/device_impl.mm:558 generic_free mmem: 0x2c04fe780  mmem.mtlBuffer: 0x17f153cc0  size: 67125248
enqueue in intern/cycles/device/metal/queue.mm:217 accessing mmem: 0x2c04fe780  mmem->mtlBuffer: 0x2  mmem->size: 0  pointer_index: 36
The mmem->mtlBuffer was deleted in another MetalDevice::MetalMem struct and -[MTLArgumentEncoder setBuffer:offset:atIndex:] would have crashed here

So first a MetalDevice::MetalMem struct is freed by way of LightManager::device_free which seems correct.
The memory of this struct is now free and undefined and will be reused immediately that is why we get a mmem->mtlBuffer of 0x2 and a mmem->size of 0 later.
In MetalDeviceQueue::enqueue the memory address of this freed region is pulled in via &metal_device->launch_params + offset
and -[MTLArgumentEncoder setBuffer:offset:atIndex:] is called with invalid parameter values.
Because accidentally mmem->size is 0 at this point this can be used to set a nice breakpoint for debugging but we should not even have this memory reference any more.
Maybe @Michael-Jones can have a look at this?

This is a case of use-after-free error. One could apply [P2707](https://archive.blender.org/developer/P2707.txt), then build and run Blender with this scene as described and see the following log messages when reducing the surface strength from 1.000 to 0.900: ``` reached useful breakpoint site at intern/cycles/device/metal/device_impl.mm:535 generic_free at intern/cycles/device/metal/device_impl.mm:558 generic_free mmem: 0x2c04fe780 mmem.mtlBuffer: 0x17f153cc0 size: 67125248 enqueue in intern/cycles/device/metal/queue.mm:217 accessing mmem: 0x2c04fe780 mmem->mtlBuffer: 0x2 mmem->size: 0 pointer_index: 36 The mmem->mtlBuffer was deleted in another MetalDevice::MetalMem struct and -[MTLArgumentEncoder setBuffer:offset:atIndex:] would have crashed here ``` So first a MetalDevice::MetalMem struct is freed by way of LightManager::device_free which seems correct. The memory of this struct is now free and undefined and will be reused immediately that is why we get a mmem->mtlBuffer of 0x2 and a mmem->size of 0 later. In MetalDeviceQueue::enqueue the memory address of this freed region is pulled in via `&metal_device->launch_params + offset` and -[MTLArgumentEncoder setBuffer:offset:atIndex:] is called with invalid parameter values. Because accidentally `mmem->size` is 0 at this point this can be used to set a nice breakpoint for debugging but we should not even have this memory reference any more. Maybe @Michael-Jones can have a look at this?

Jesse Yurkovich commented

2022-01-14 20:06:04 +01:00

Added subscriber: @AledBrown