catchsegv not resolving gnu_debuglink correctly about drmingw HOT 8 CLOSED

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.

from drmingw.

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?

from drmingw.

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.

from drmingw.

@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..

from drmingw.

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

from drmingw.

@alvinhochun , ignore all my previous rambles. I think I nailed it in af8adbf. Let me know if the issue persists.

from drmingw.

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

from drmingw.

Yay it works! 😄

from drmingw.