Exception: Access Violation- where to get more information?

If you’ve done a lot of addon development or scripting in Blender, there is a very high probability that you’ve seen Blender crash to the desktop without any warning or error at all. If you’re running with a terminal open, you probably also know that this is almost always because of an Access Violation crash.

Hopefully, you know right away what caused it so you can go and fix it. But if you’re like me you work in a large studio with a lot of people writing a lot of different scripts, so you probably have non-technical artists coming and saying “Hey blender just crashed, I wasn’t doing anything in particular”. I’ve been able to repro the crash on their machine just by doing random things- but I haven’t been able to narrow down where it’s coming from or why it’s happening. I’ve tried running with the --debug-all flag and the ouput I got wasn’t super useful. It tells me there’s an access violation, okay great- WHAT script or operator caused it? what data was being accessed that no longer existed?? How are we supposed to debug these scripts in a large studio environment? These guys are running lots of different scripts and addons, I don’t know if it’s hardops causing it or something in-house and custom, or blender itself. How do I get more information on what is causing a crash?

You can start by building a debug build of Blender yourself. When you also enable ASAN (address sanitizer), you can already get a better idea of where the crash exactly happens in the C code.
To figure out which line of Python caused it, you can either attach a Python debugger to Blender, or just insert some print statements to narrow down the bug.

That’s certainly an option on my machine- but I suppose there are no options for when a random artist at my studio asks me to come to his desk and track down a problem? I don’t think I’ll be able to convince all of our artists to pull down the source from git and do a debug build, and replicating each artist’s individual setup so I can debug it on my machine is going to prove difficult as well. If these are the only options then that’s what I’ll have to do I suppose.

That said- I feel like this is a solvable problem with slightly more verbose logging with the debug-all flag enabled. it dumps out a lot of information but it’s still missing things. For example, one crash I was able to capture with the -debug-all flag on:

wm_event_do_handlers: Handling event
wmEvent type:224 / DEL, val:1 / PRESS,
shift:0, ctrl:0, alt:0, oskey:0, keymodifier:0,
mouse:(851,538), ascii:’ ‘, utf8:’’, keymap_idname:(null), pointer:0000021758D841F8
graph_id_tag_update: id=MECylinder.002 flags=GEOMETRY source=USER_EDIT
graph_id_tag_update: id=MECylinder.002 flags=GEOMETRY source=USER_EDIT
graph_id_tag_update: id=MECylinder.002 flags=SELECT source=USER_EDIT
graph_id_tag_update: id=MECylinder.002 flags=SELECT source=USER_EDIT
[SCScene :: View Layer]: Operation is entry point for update: GEOMETRY_EVAL()
[SCScene :: View Layer]: Operation is entry point for update: COPY_ON_WRITE()
[SCScene :: View Layer]: Operation is entry point for update: GEOMETRY_EVAL_DONE()
[SCScene :: View Layer]: Operation is entry point for update: GEOMETRY_SELECT_UPDATE()
[SCScene :: View Layer]: Accumulated recalc bits for OBCylinder.002: 8322
[SCScene :: View Layer]: Accumulated recalc bits for MECylinder.002: 8834
[SCScene :: View Layer]: deg_evaluate_copy_on_write on MECylinder.002 (0000021758EC70C8)
[SCScene :: View Layer]: deg_evaluate_copy_on_write on OBCylinder.002 (0000021758EE3278)
[SCScene :: View Layer]: BKE_object_data_select_update on MECylinder.002 (0000021758EC70C8)
[SCScene :: View Layer]: BKE_mesh_eval_geometry on MECylinder.002 (0000021758EC70C8)
[SCScene :: View Layer]: BKE_object_eval_uber_data on OBCylinder.002 (0000021758EE3278)
[SCScene :: View Layer]: BKE_object_handle_data_update on OBCylinder.002 (0000021758EE3278)
[SCScene :: View Layer]: BKE_object_select_update on OBCylinder.002 (0000021758EE3278)
[SCScene :: View Layer]: BKE_object_data_select_update on MECylinder.002 (0000021758EC70C8)
Depsgraph updated in 0.030844 seconds.
Error : EXCEPTION_ACCESS_VIOLATION
Address : 0x00007FF7E4DB3F35
Module : E:\blender-2.80\blender.exe

The events that preceeded this were innocuous selection/orbit camera events. On this user’s machine, his delete key is bound to a context-sensitive delete operator which has been in use at our studio since 2.78 days and has never failed before, so the final ‘event’ before the crash appears to be a red herring. What happened beteween that event and the crash? That’s the type of information I wish the debug output showed.

Figuring out what is wrong at an artists desk is not a great way go about this. We’re working on adding automated crash reporting to blender so you’ll have a nice report with proper stack trace on a centralized server in case of crashes. Will not solve the issues, but you’ll have a better idea where the problems are without having to visit any desks and go ‘uhh yeah dunno…weird…right?’

Keep an eye on https://developer.blender.org/D3576

2 Likes

This is great to hear, thanks for the link!