Page MenuHome

EXCEPTION_ACCESS_VIOLATION crash when removing modifiers or rendering
Closed, ResolvedPublic

Description

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:

  1. Open the file.
  2. Press 'Render' or 'F12'.
  3. File instantly crashes.

Alternatively:

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

Event Timeline

Ray Mairlot (madog) updated the task description. (Show Details)
Ray Mairlot (madog) raised the priority of this task from to Needs Triage by Developer.
Ray Mairlot (madog) set Type to Bug.

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

Sergey Sharybin (sergey) triaged this task as Confirmed, Medium priority.Mar 8 2016, 10:29 AM

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

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…

@Bastien Montagne (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.