QtCreator Debugger fails ( gdb is complaining about python importing )

[xenovas]

Hi again ,

another issue arrived today which is about gdb in QtCreator that faills to start.. Basically the following Application output occurs when trying to debug my app

Debugging starts
Debugging has finished

yes ofcourse i have seen other forum threads but no one have been given a clear cut solution that fit my needs..

i ve seen somewhere that i needd to upgrade from python 2 to python 3 , but really i dont want to do that. ..

does anyone has a better solution to propose ?

im running Qt 4.8.0 on Windows 10 and i have statically built Qt 5.11.3 with Mingw 32

everything works perfect except the debugger

here is a snippet from my log

>&"python from gdbbridge import *\n"

>&"Traceback (most recent call last):\n"
>&"  File \"<string>\", line 1, in <module>\n"
>&"  File \"C:/Qt/Tools/QtCreator/share/qtcreator/debugger/gdbbridge.py\", line 40, in <module>\n"
>&"    from dumper import *\n"
>&"  File \"C:/Qt/Tools/QtCreator/share/qtcreator/debugger/dumper.py\", line 28, in <module>\n"
>&"    import copy\n"
>&"  File \"C:\\Python27\\Lib/copy.py\", line 52, in <module>\n"
>&"    import weakref\n"
>&"  File \"C:\\Python27\\Lib/weakref.py\", line 14, in <module>\n"
>&"    from _weakref import (\n"
>&"ImportError: cannot import name _remove_dead_weakref\n"
>&"Error while executing Python code.\n"
>134^error,msg="Error while executing Python code."

>&"python theDumper.loadDumpers({\"token\":135})\n"
>&"Traceback (most recent call last):\n"
>&"  File \"<string>\", line 1, in <module>\n"
>&"NameError: name 'theDumper' is not defined\n"
>&"Error while executing Python code.\n"
>135^error,msg="Error while executing Python code."
dNOTE: ENGINE SETUP FAILED
dState changed from EngineSetupRequested(1) to EngineSetupFailed(2)
<Debugging has failed.
dState changed from EngineSetupFailed(2) to DebuggerFinished(17)

dQUIT DEBUGGER REQUESTED IN STATE 17
>136^done
dCOOKIE FOR TOKEN 136 ALREADY EATEN (DebuggerFinished). TWO RESPONSES FOR ONE COMMAND?


d
dNON-CRITICAL TIMEOUT
dCOMMANDS STILL IN PROGRESS: 

[JonB]

@xenovas

i ve seen somewhere that i needd to upgrade from python 2 to python 3 , but really i dont want to do that. ..

If the python scripts being run for the debugger require Python 3 rather than Python 2 (there were a lot of changes, so often scripts are not compatible), what else do you want to do?

[xenovas]

@JonB thank you for your response...i have installed python 3.7.2 32bit and the issue has been solved

[hati]

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 –

...
>&"python sys.path.insert(1, 'C:/Qt/Tools/QtCreator/share/qtcreator/debugger/')\n"
>13^done

>&"python sys.path.append('C:/Qt/Tools/mingw530_32/bin/data-directory/python')\n"
>14^done

>&"python from gdbbridge import *\n"
>&"Traceback (most recent call last):\n"
...

– 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 ?...