I faced the same problem with QtCreator 4.9.0 (32-bit, based on Qt 5.12.2) on Windows 10 ver. 1803 (build 17134.472).
For me, switching to python 3(.7.2) made it worse: gdb failed to even start with "Unable to create a debugging engine." in the "Application output" log.
TLDR:
Unsetting the PYTHONPATH env.var. solved it for me (for either a py2 or a py3 main "system" install).
If you need it for some other application (as I did), launching from e.g. a batch file you can set PYTHONPATH for the other app only or, alternatively, unset it (set to empty value) for QtCreator only.
Note:
For having PYTHONHOME set (e.g. to "C:\Python27" for python 2.7) and PATH containing the "system" python path (e.g. "C:\Python27;C:\Python27\Scripts;" for python 2.7) I noticed no problem.
Explanation Possible explanation:
The debugger was able to load its python bindings and modules and work (seemingly) correctly when I uninstalled all of my "system" python.
That – together with my initial observation – tells me that my QtCreator uses python 2 with its own set of libraries/modules which got overridden by my "system" python libraries/modules by having PYTHONPATH set, and gdb did not find its own python modules.
EDIT:
There might actually be a problem in gdb or QtCreator, as according to the debugger log –
– gdb seems to add its module paths dynamically to sys.path, which should take place after the effect of the PYTHONPATH env.var., so its value should probably not cause a problem. Could its behavior here be intentionally different to the python docs on env.var.s ?...