Closed alvinhochun closed 2 years ago
It shouldn't be difficult to reproduce this, but it would help me to understand where exactly are the binaries. For example, what's the krita.dll
and krita.dll.debug
's full path?
Nevermind, I downloaded krita from https://binary-factory.kde.org/job/Krita_Nightly_Windows_Build/ so I can see all binaries.
However I can't reproduce this. mgwhelp_module_create
's ImageName
parameter is always correct for me.
It might be something more subtle going on here. Please double check this happens with the released catchsegv.exe
or catchsegv.exe
built with gcc.
@alvinhochun, please rerun catchsegv
with -v
option, ie, catchsegv.exe -v -m krita.com
.
I want to see what's logged on https://github.com/jrfonseca/drmingw/blob/0.9.5/src/common/debugger.cpp#L676-L698
My guess is that GetFileNameFromHandle
is somehow returning garbage. Why is not clear, and I can't investigate it furher without reprocuding locally. You'll need to step through GetFileNameFromHandle and see why it's failing.
One potential problem is my abuse of MAX_PATH
all over the place. I've been lazy, as I really should start using variable length vectors everywhere for paths, preferably Unicode. But it's time consuming grunt work..
Sorry, I see you already run with -v
... The relevant message is
CREATE_PROCESS PID=13776 TID=22388 lpBaseOfImage=00007FF7E4C40000
...
the expectation would be
CREATE_PROCESS PID=13776 TID=22388 lpBaseOfImage=00007FF7E4C40000 krita.com
...
so this is consistent with GetFileNameFromHandle
returning garbage. Why I don't know...
@alvinhochun , ignore all my previous rambles. I think I nailed it in https://github.com/jrfonseca/drmingw/commit/af8adbfd6387744c85311fc2634a5d6b57e1a809. Let me know if the issue persists.
Ah, thanks for looking into this. I always forgot to mention that I am using a ramdisk drive created with ImDisk, which often seems to expose some edge cases in applications.
In my case it is still failing to load. A snippet of the debug output:
[19300] GetFinalPathNameByHandle failed with 0x00000001
[19300] MGWHELP: \Device\ImDisk20\krita-v5.1.0-prealpha-1799-g386dee827c-dirty\bin\krita.com.debug - not found
[19300] MGWHELP: \Device\ImDisk20\krita-v5.1.0-prealpha-1799-g386dee827c-dirty\bin\.debug\krita.com.debug - not found
[19300] GetFinalPathNameByHandle failed with 0x00000001
[19300] MGWHELP: \Device\ImDisk20\krita-v5.1.0-prealpha-1799-g386dee827c-dirty\bin\krita.dll.debug - not found
[19300] MGWHELP: \Device\ImDisk20\krita-v5.1.0-prealpha-1799-g386dee827c-dirty\bin\.debug\krita.dll.debug - not found
And a snippet of the catchsegv -v
output:
CREATE_PROCESS PID=18276 TID=23856 lpBaseOfImage=00007FF7E4C40000 \Device\ImDisk20\krita-v5.1.0-prealpha-1799-g386dee827c-dirty\bin\krita.com
LOAD_DLL PID=18276 TID=23856 lpBaseOfDll=00007FFAA4D50000 \\?\C:\Windows\System32\ntdll.dll
LOAD_DLL PID=18276 TID=23856 lpBaseOfDll=00007FFAA3020000 \\?\C:\Windows\System32\kernel32.dll
LOAD_DLL PID=18276 TID=23856 lpBaseOfDll=00007FFAA24F0000 \\?\C:\Windows\System32\KernelBase.dll
CREATE_THREAD PID=18276 TID=10200
LOAD_DLL PID=18276 TID=23856 lpBaseOfDll=00007FFAA2B80000 \\?\C:\Windows\System32\ucrtbase.dll
CREATE_THREAD PID=18276 TID=11020
LOAD_DLL PID=18276 TID=10200 lpBaseOfDll=00007FFA4F440000 \Device\ImDisk20\krita-v5.1.0-prealpha-1799-g386dee827c-dirty\bin\krita.dll
CREATE_THREAD PID=18276 TID=24568
LOAD_DLL PID=18276 TID=24568 lpBaseOfDll=00007FFA64150000 \Device\ImDisk20\krita-v5.1.0-prealpha-1799-g386dee827c-dirty\bin\libkritaresources.dll
LOAD_DLL PID=18276 TID=10200 lpBaseOfDll=00007FFA4EE20000 \Device\ImDisk20\krita-v5.1.0-prealpha-1799-g386dee827c-dirty\bin\libkritaimage.dll
LOAD_DLL PID=18276 TID=24568 lpBaseOfDll=00007FFA62D70000 \Device\ImDisk20\krita-v5.1.0-prealpha-1799-g386dee827c-dirty\bin\libkritaglobal.dll
I think in the case of the path format like \Device\ImDisk20\...
it needs some kind of a prefix to get win32 APIs to open it correctly? Maybe something like \\.\
? IIRC the same thing also applies to a hard disk volume mounted to a folder mountpoint instead of a drive letter...
I think in the case of the path format like
\Device\ImDisk20\...
it needs some kind of a prefix to get win32 APIs to open it correctly? Maybe something like\\.\
?
Yep, GetFileNameFromHandle
body needs the rest of the sample code on https://msdn.microsoft.com/en-us/library/aa366789.aspx . I thought it wasn't necessary, but it unmistakably makes a diference on this case.
I'll push a fix after cleaning up the code somewhat.
Yay it works! 😄
Filing a new issue from https://github.com/jrfonseca/drmingw/issues/64#issuecomment-1094932631
The
ImageName
argument seems wrong? You can also see that https://github.com/jrfonseca/drmingw/blob/c03af4c377410745751498a2b83bb33ab16fbc91/src/mgwhelp/dwarf_pe.cpp#L249 is printing a path with the wrong directory.