EXCEPTION_ACCESS_VIOLATION crash when removing modifiers or rendering #47715

New Issue

Ray Mairlot · 2016-03-07T17:39:42+01:00

Ray Mairlot commented

2016-03-07 17:39:42 +01:00

System Information
Windows 10 64-bit, Nvidia GTX 570

Blender Version
Broken: 2.76b, 7499fcf (latest 2.77 64-bit build)
Worked: -

Short description of error

I have a specific file that immediately crashes (blender closes without warning) when rendering or when removing any modifiers (apart from the first 2) on a specific object. I have simplified the file as much as I can.

If I remove any of the objects in the second scene (they are targets of the shrinkwrap modifiers on the problematic object), the file successfully renders.
If I remove either of the first two modifiers on the problematic object, the file will render.
If I delete any more than a few faces in the object 'Shrinkwrap 1' (the target of the first shrinkwrap modifier on the problematic object), the file will render.

All crashes result in 'EXCEPTION_ACCESS_VIOLATION' being displayed (when running blender from the command line). 99% of the time that's the error, I did once see a 'divide by zero' error.

Just in case it is important, the object 'Shrinkwrap 2' (the target of the second shrinkwrap modifier) also uses 'Shrinkwrap one' (the target of the first shrinkwrap modifier) as the target on its own shrinkwrap modifier.

Exact steps for others to reproduce the error

Using this file: Shrinkwrap Crash.blend

Open the file.
Press 'Render' or 'F12'.

File instantly crashes.

Alternatively:

Open the file.
Remove any modifier below the first two on the object called 'Main object'.
File instantly crashes.

**System Information** Windows 10 64-bit, Nvidia GTX 570 **Blender Version** Broken: 2.76b, 7499fcf (latest 2.77 64-bit build) Worked: - **Short description of error** I have a specific file that immediately crashes (blender closes without warning) when rendering or when removing any modifiers (apart from the first 2) on a specific object. I have simplified the file as much as I can. - If I remove any of the objects in the second scene (they are targets of the shrinkwrap modifiers on the problematic object), the file successfully renders. - If I remove either of the first two modifiers on the problematic object, the file will render. - If I delete any more than a few faces in the object 'Shrinkwrap 1' (the target of the first shrinkwrap modifier on the problematic object), the file will render. All crashes result in 'EXCEPTION_ACCESS_VIOLATION' being displayed (when running blender from the command line). 99% of the time that's the error, I did once see a 'divide by zero' error. Just in case it is important, the object 'Shrinkwrap 2' (the target of the second shrinkwrap modifier) also uses 'Shrinkwrap one' (the target of the first shrinkwrap modifier) as the target on its own shrinkwrap modifier. **Exact steps for others to reproduce the error** Using this file: [Shrinkwrap Crash.blend](https://archive.blender.org/developer/F288957/Shrinkwrap_Crash.blend) - Open the file. - Press 'Render' or 'F12'. # File instantly crashes. Alternatively: - Open the file. - Remove any modifier below the first two on the object called 'Main object'. - File instantly crashes.

Ray Mairlot commented

2016-03-07 17:39:42 +01:00

Changed status to: 'Open'

Ray Mairlot commented

2016-03-07 17:39:42 +01:00

Added subscriber: @RayMairlot

perfection cat commented

2016-03-08 03:43:58 +01:00

Added subscriber: @sindra1961

perfection cat commented

2016-03-08 03:43:58 +01:00

If you run blender with --enable-new-depsgraph, this will not occur.

Sergey Sharybin commented

2016-03-08 10:29:33 +01:00

Added subscriber: @Sergey

Sergey Sharybin commented

2016-03-08 10:29:33 +01:00

This is a threading conflict. New depsgraph perhaps has different timing which avoids the crash, root of the issue is outside of the depsgraph.

Bastien Montagne commented

2016-03-12 15:16:58 +01:00

Added subscribers: @mont29, @ideasman42

Bastien Montagne commented

2016-03-12 15:16:58 +01:00

Yeah… Same old issue again, modifiers using a DM from another object are a real problem (here, ShrinkwrapCalcData.target DM), we hit that issue several times in the past already.

Manage to fix part of the issues here by making a local copy (CDDM_copy) of it in shrinkwrapModifier_deform, but even then, manage to get a crash (likely because the target->derived_final was being freed while being fetched/copied in other thread).

We could:

Have a global modifiers lock (like the ones we have for nodes, fftw, etc.).
Use that lock when freeing the derivedFinal.
Add a modifiers-dedicated helper to get a DM, which would always return a copy of the derivedFinal (and be threadsafe too of course).

Or also, use a (thread-safe, trivial with atomic ops) refcount for DMs maybe? This would also avoid the need to copy other-objects DM in modifiers…

Yeah… Same old issue again, modifiers using a DM from another object are a real problem (here, `ShrinkwrapCalcData.target` DM), we hit that issue several times in the past already. Manage to fix part of the issues here by making a local copy (`CDDM_copy`) of it in `shrinkwrapModifier_deform`, but even then, manage to get a crash (likely because the target->derived_final was being freed while being fetched/copied in other thread). We could: * Have a global modifiers lock (like the ones we have for nodes, fftw, etc.). * Use that lock when freeing the `derivedFinal`. * Add a modifiers-dedicated helper to get a DM, which would always return a copy of the `derivedFinal` (and be threadsafe too of course). Or also, use a (thread-safe, trivial with atomic ops) refcount for DMs maybe? This would also avoid the need to copy other-objects DM in modifiers…

Sergey Sharybin commented

2016-03-12 15:34:14 +01:00

@mont29, modifiers are totally allowed to use other object's derived mesh. There are two possibilities here:

The derived mesh which is used by shrinkwrap was not fully updated before the modifier started evaluation. This would mean missing relation in the dependency graph.
Shrinkwrap modifies other object's derived mesh, This is forbidden and must not be worked around with reference counters.

Once those points are ensured none of local DM copy or refcounting are needed.

@mont29, modifiers are totally allowed to use other object's derived mesh. There are two possibilities here: - The derived mesh which is used by shrinkwrap was not fully updated before the modifier started evaluation. This would mean missing relation in the dependency graph. - Shrinkwrap modifies other object's derived mesh, This is forbidden and must not be worked around with reference counters. Once those points are ensured none of local DM copy or refcounting are needed.

blender-admin commented

2016-04-28 12:32:59 +02:00

This issue was referenced by 94a6019a7b

This issue was referenced by 94a6019a7ba94f8b46b737c185293ecce19cc6a6

Sergey Sharybin commented

2016-04-28 12:33:10 +02:00

Changed status from 'Open' to: 'Resolved'

Sergey Sharybin closed this issue

2016-04-28 12:33:10 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

EXCEPTION_ACCESS_VIOLATION crash when removing modifiers or rendering #47715

File instantly crashes.