Page MenuHome
Maniphest T65402

Making errors in script editor with system console turned on causes Blender to crash
Closed, ResolvedPublic
Actions

Description

System Information
Operating system: Windows 10, 64 bit
Graphics card: Geforce Nvidia 1070, 8 gb

Blender Version
Broken: blender-2.80.0-git.cc600de6695a-windows64

I noticed that whenever I make a mistake in my script in Blender's text editor and run it with System Console turned on I crash all the time instead of getting the warning message regarding error in the code.

Exact steps for others to reproduce the error
1- Launch blender, create a cube in the startup file.
2- Create new text file in Blender text editor.
3- Write import bpy to be able to copy and run code from information panel.
4- Enable system console window.
5- Scroll system console window up and down a bit to check it's contents, go back to blender window.
6- Change scale of the cube a little.
7.- Copy 'change scale' code in information tab and run it.
8.- Deliberately make mistakes in the code in text editor to get the error prompt.
9.- Hit Run Script key and crash.

Note: that it might take several attempts and switches between Blender and System Console.

Sounds convoluted, but quite simple to recreate really. Sometimes it takes several mistakes in a row to make it crash. But I noticed that you crash all the time when you open the System Console and scroll it up and down and then go back to blender and run the code with errors a couple of times. Basically this makes System Console unusable for me, and it's so annoying because it can suddenly destroy your work it's also quite unpredictable to effectively avoid =(.

Watch this video for details, I recreate the bug every time I try:

System_Console.flv6 MBDownload

Details

Commits
rB2d98ac33bef3: Fix T65402: Syntax error causes CPython assert
Type
Bug

Related Objects

Event Timeline

matc (matc) added a subscriber: matc (matc).Jun 1 2019, 11:02 PM
matc (matc) triaged this task as Confirmed, Medium priority.

I can reproduce it like this on 0360a2920dec9028d:

  1. Open default startup .blend
  2. Open "Text Editor" view
  3. Create new Text file
  4. Add code
  5. Click Run Script

The following code snippets do cause the crash:

import bpy
bpy.ops.transform.resize(value=(2.616XXXX53, 2.61653, 2.61653))
import bpy
bpy.ops.transform.resize(value=(2.61653XXXX, 2.61653, 2.61653))
import bpy
bpy.ops.transform.resize(value=(XXXX2.61653, 2.61653, 2.61653))

The following code snippets do not cause the crash:

import bpy
bpy.ops.transform.resize(valXXXXue=(2.61653, 2.61653, 2.61653))
import bpy
bpy.ops.transform.resiXXXXze(value=(2.61653, 2.61653, 2.61653))
import bpy
bpy.ops.transform.resize(value=('XXXX', 2.61653, 2.61653))
Campbell Barton (campbellbarton) added a comment.Jun 11 2019, 7:24 AM

I can't redo this bug on Linux.

Could someone paste a back-trace?

matc (matc) added a comment.Jun 12 2019, 5:10 AM

Just noticed that text->nlines is 1 in BPY_execute_text, independent of the actual lines. Don't know whether this has to do with anything.

 	ucrtbased.dll!00007ff98b731225()	Unknown
 	ucrtbased.dll!00007ff98b731043()	Unknown
 	ucrtbased.dll!00007ff98b73398f()	Unknown
 	python37_d.dll!00007ff98e398b45()	Unknown
 	python37_d.dll!00007ff98e358e73()	Unknown
 	python37_d.dll!00007ff98e3567a3()	Unknown
 	python37_d.dll!00007ff98e356a7f()	Unknown
 	python37_d.dll!00007ff98e359af8()	Unknown
>	blender.exe!parse_syntax_error(_object * err=0x000002cf98fece00, _object * * message=0x000000e0c87fea28, _object * * filename=0x000000e0c87fea48, int * lineno=0x000000e0c87feaf4, int * offset=0x000000e0c87feb14, _object * * text=0x000000e0c87fea68) Line 63	C
 	blender.exe!python_script_error_jump(const unsigned char * filepath=0x000002cf97bab9ea, int * lineno=0x000000e0c87feaf4, int * offset=0x000000e0c87feb14) Line 152	C
 	blender.exe!python_script_error_jump_text(Text * text=0x000002cf97bab9c8) Line 407	C
 	blender.exe!python_script_exec(bContext * C=0x000002cf81bac828, const unsigned char * fn=0x0000000000000000, Text * text=0x000002cf97bab9c8, ReportList * reports=0x000002cf9870b8d8, const bool do_jump=true) Line 470	C
 	blender.exe!BPY_execute_text(bContext * C=0x000002cf81bac828, Text * text=0x000002cf97bab9c8, ReportList * reports=0x000002cf9870b8d8, const bool do_jump=true) Line 570	C
 	blender.exe!text_run_script(bContext * C=0x000002cf81bac828, ReportList * reports=0x000002cf9870b8d8) Line 708	C
 	blender.exe!text_run_script_exec(bContext * C=0x000002cf81bac828, wmOperator * op=0x000002cf9ee4c768) Line 749	C
 	blender.exe!wm_operator_invoke(bContext * C=0x000002cf81bac828, wmOperatorType * ot=0x000002cf84b76078, wmEvent * event=0x000002cf8571c5a8, PointerRNA * properties=0x000000e0c87ff418, ReportList * reports=0x0000000000000000, const bool poll_only=false, bool use_last_properties=true) Line 1452	C
 	blender.exe!wm_operator_call_internal(bContext * C=0x000002cf81bac828, wmOperatorType * ot=0x000002cf84b76078, PointerRNA * properties=0x000000e0c87ff418, ReportList * reports=0x0000000000000000, const short context=1, const bool poll_only=false, wmEvent * event=0x000002cf8571c5a8) Line 1653	C
 	blender.exe!WM_operator_name_call_ptr(bContext * C=0x000002cf81bac828, wmOperatorType * ot=0x000002cf84b76078, short context=1, PointerRNA * properties=0x000000e0c87ff418) Line 1702	C
 	blender.exe!ui_apply_but_funcs_after(bContext * C=0x000002cf81bac828) Line 809	C
 	blender.exe!ui_handler_region_menu(bContext * C=0x000002cf81bac828, const wmEvent * event=0x000002cfa17cf518, void * UNUSED_userdata=0x000002cf985e1cc8) Line 10148	C
 	blender.exe!wm_handler_ui_call(bContext * C=0x000002cf81bac828, wmEventHandler_UI * handler=0x000002cfa0a0e4d8, const wmEvent * event=0x000002cfa17cf518, int always_pass=0) Line 623	C
 	blender.exe!wm_handlers_do_intern(bContext * C=0x000002cf81bac828, wmEvent * event=0x000002cfa17cf518, ListBase * handlers=0x000002cf84c4c198) Line 2701	C
 	blender.exe!wm_handlers_do(bContext * C=0x000002cf81bac828, wmEvent * event=0x000002cfa17cf518, ListBase * handlers=0x000002cf84c4c198) Line 2944	C
 	blender.exe!wm_event_do_handlers(bContext * C=0x000002cf81bac828) Line 3313	C
 	blender.exe!WM_main(bContext * C=0x000002cf81bac828) Line 420	C
 	blender.exe!main(int argc=1, const unsigned char * * UNUSED_argv_c=0x000002cf81ac5c80) Line 502	C
 	[External Code]
Chingiz Jumagulov (Krayzmond) added a comment.Jul 17 2019, 7:23 AM

Might this bug be related to something connected to Windows permissions and be Windows specific only? I had weird bugs with proprietary addons that I've purchased, some of them glitched on Windows when executing certain Python commands, especially the ones related to deletion or editing the blend files and etc. I had to report bugs to developers and we worked on work-arounds in code together but we also failed to specifically "catch the bug" with logs so that we could report it on this platform. Crashes appeared to be so random and Windows specific...

matc (matc) added a comment.Sun, Jul 21, 9:29 PM

Looks like this bug only happens with the debug build configuration. I tested rc2, and then built the current master with release target. Both handle the error cases gracefully.

If I click "Ignore" (5 times) on the error dialog with the debug configuration, subsequent errors do not cause the error dialog to prompt up anymore. And things start to behave exactly like with the release configuration. I guess the error is happening in release builds too, but is silently ignored.

matc (matc) added a comment.Mon, Jul 22, 12:54 AM

It's triggering an assertion in cpython.

(cpython(v3.7.0)) typeobject.c line 3085:

/* We may end up clearing live exceptions below, so make sure it's ours. */
assert(!PyErr_Occurred());

res = find_name_in_mro(type, name, &error);
/* Only put NULL results into cache if there was no error. */
if (error) {
    /* It's not ideal to clear the error condition,
       but this function is documented as not setting
       an exception, and I don't want to change that.
       E.g., when PyType_Ready() can't proceed, it won't
       set the "ready" flag, so future attempts to ready
       the same type will call it again -- hopefully
       in a context that propagates the exception out.
    */
    if (error == -1) {
        PyErr_Clear();
    }
    return NULL;
}

Restoring the syntax error a bit later should solve this.

diff --git a/source/blender/python/intern/bpy_traceback.c b/source/blender/python/intern/bpy_traceback.c
index c9c9e4adafb..382da69aaca 100644
--- a/source/blender/python/intern/bpy_traceback.c
+++ b/source/blender/python/intern/bpy_traceback.c
@@ -143,7 +143,6 @@ void python_script_error_jump(const char *filepath, int *lineno, int *offset)
     /* no traceback available when SyntaxError.
      * python has no api's to this. reference parse_syntax_error() from pythonrun.c */
     PyErr_NormalizeException(&exception, &value, (PyObject **)&tb);
-    PyErr_Restore(exception, value, (PyObject *)tb); /* takes away reference! */

     if (value) { /* should always be true */
       PyObject *message;
@@ -165,6 +164,8 @@ void python_script_error_jump(const char *filepath, int *lineno, int *offset)
         *lineno = -1;
       }
     }
+
+    PyErr_Restore(exception, value, (PyObject *)tb); /* takes away reference! */
   }
   else {
     PyErr_NormalizeException(&exception, &value, (PyObject **)&tb);
Campbell Barton (campbellbarton) added a comment.Tue, Jul 23, 12:32 PM

Thanks @matc (matc) for investigating, managed to redo w/ Python built in debug mode, committed.