Crash-reporter doesn't seem to work correctly without Python installed??
Opened this issue · 8 comments
C:\Users\kevin\AppData\Roaming\TerraCraft\Games\LemnosLife\Game>gdb\gdbAttach.bat
C:\Users\kevin\AppData\Roaming\TerraCraft\Games\LemnosLife\Game>start LemnosLife.exe
C:\Users\kevin\AppData\Roaming\TerraCraft\Games\LemnosLife\Game>for /F "TOKENS=1,2,*" %a in ('tasklist /FI "IMAGENAME eq LemnosLife.exe"') do set MyPID=%b
C:\Users\kevin\AppData\Roaming\TerraCraft\Games\LemnosLife\Game>set MyPID=de
C:\Users\kevin\AppData\Roaming\TerraCraft\Games\LemnosLife\Game>set MyPID=========
C:\Users\kevin\AppData\Roaming\TerraCraft\Games\LemnosLife\Game>set MyPID=4884
C:\Users\kevin\AppData\Roaming\TerraCraft\Games\LemnosLife\Game>gdb\gdb -ex "set pagination off" -ex "set confirm off" -ex "set print thread-events off" -ex "handle SIGTRAP nostop noprint noignore" -ex "attach 4884" -ex continue -ex "bt f" -ex q
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Python path configuration:
PYTHONHOME = (not set)
PYTHONPATH = (not set)
program name = 'c:\tools\msys64\mingw64/bin/python'
isolated = 0
environment = 1
user site = 1
import site = 1
sys._base_executable = 'c:\\tools\\msys64\\mingw64/bin/python'
sys.base_prefix = 'D:\\a\\msys64\\mingw64'
sys.base_exec_prefix = 'D:\\a\\msys64\\mingw64'
sys.platlibdir = 'lib'
sys.executable = 'c:\\tools\\msys64\\mingw64/bin/python'
sys.prefix = 'D:\\a\\msys64\\mingw64'
sys.exec_prefix = 'D:\\a\\msys64\\mingw64'
sys.path = [
'D:\\a\\msys64\\mingw64\\lib\\python310.zip',
'D:\\a\\msys64\\mingw64\\lib\\python3.10',
'D:\\a\\msys64\\mingw64\\lib\\lib-dynload',
'',
]
Error occurred computing Python errormessage.
Python not initialized
Note that assuming that D:\\a\\ means c:\\tools\\, then all files/folders exist, except that there are no .zip, lib-dynload and now it is python3.11 and not python3.10. Hence giving a try rebuilding to have latest Python seems to make sense.
Discord user: 1130419636664553564 - don't contact him, as he is aggressive for no reason.
Note that this computer is under Windows 10 otherwise it's up to date.
The error message mentions msys but msys2 returns:
'msys2' n’est pas reconnu en tant que commande interne
ou externe, un programme exécutable ou un fichier de commandes.
on his machine while on my VirtualBox it doesn't return anything and launch a msys prompt.
Maybe it's because the gdb version that I share was compiled on msys...
Still have the issue after restarting to make sure that the recent choco install python wasn't problematic.
So it definetely seems that my gdb build on msys is to blame...
Note that this issue was (as I now installed the package) reproducible on my Windows (not trust) (note that due to a VirtualBox issue I can't take a snapshot, it's not reproducible on the Windows (trust) virtual machine, well now it is 👀).
Can first compare both chocolatey packages, as both machines are up to date.
choco install msys2
yes | pacman -S mingw-w64-x86_64-gdbsolves the issue. (C:\tools\msys64\msys2.exe otherwise msys2 requires to open a new shell (cmd or powershell))
pacman -Rns
restores the issue.
Removing c:\\tools\\msys64\\mingw64/bin/python doesn't restore the issue and I don't know how to access D:\\a\\msys64 , if it even exists, as `D:``` consists in VBoxGuestAdditions.
Let's try to grep msys64 binarily Windows LemnosLife to possibly find DLLs involved in the issue.
$ grep -r 'msys64'
grep: gdb/gdb.exe: binary file matches
grep: libtermcap-0.dll: binary file matches
grep: libintl-8.dll: binary file matches
grep: libpython3.10.dll: binary file matches
grep: libreadline8.dll: binary file matchesNoe Lajoie has the same issue.
Should also produce cleaner crash reports not containing something like Python Exception <class 'NameError'>: Installation error: gdb._execute_unwinders function is missing.
871083923311067177 is facing the same issue, notify him when I solved this issue.
794551366902743041 also faces this issue.
As of today my Framework Windows trust VM has the issue but snapshotting no matter my current snapshotting error would be very helpful otherwise it could be a headache to understand the issue source.
Note that my only Windows trust VM on Pegasus does not face the issue.
Framework Windows not trust VM also has the gdb issue but has the same snapshotting issue. Well as I have 2 VMs having the issue, let us find the solution on one and try this solution on the other.
New version of gdb now leads to:
gdb.exe --version
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Python path configuration:
PYTHONHOME = (not set)
PYTHONPATH = (not set)
program name = 'C:\mingw64\bin\python'
isolated = 0
environment = 1
user site = 1
safe_path = 0
import site = 1
is in build tree = 0
stdlib dir = 'D:\a\msys64\mingw64\lib\python3.11'
sys._base_executable = 'C:\\mingw64\\bin\\python'
sys.base_prefix = 'D:\\a\\msys64\\mingw64'
sys.base_exec_prefix = 'D:\\a\\msys64\\mingw64'
sys.platlibdir = 'lib'
sys.executable = 'C:\\mingw64\\bin\\python'
sys.prefix = 'D:\\a\\msys64\\mingw64'
sys.exec_prefix = 'D:\\a\\msys64\\mingw64'
sys.path = [
'D:\\a\\msys64\\mingw64\\lib\\python311.zip',
'D:\\a\\msys64\\mingw64\\lib\\python3.11',
'D:\\a\\msys64\\mingw64\\lib\\python3.11\\lib-dynload',
]
Error occurred computing Python errormessage.
Python not initialized
Even if copy:
libgcc_s_seh-1.dll
libgmp-10.dll
libiconv-2.dll
libintl-8.dll
libmpfr-6.dll
libncursesw6.dll
libpython3.11.dll
libreadline8.dll
libstdc++-6.dll
libtermcap-0.dll
libwinpthread-1.dll
libzstd.dll
zlib1.dll