search

wc-duck / dbgtools

Small collection of debug-related drop-in c/c++-utils
Other
240 stars 10 forks source link

SymInitialize gets broken search paths #5

Open fredrikz opened 4 years ago

fredrikz commented 4 years ago

It seems that mod = GetModuleFileName((HMODULE)0, search_path, length); in static void callstack_symbols_build_search_path(char* search_path, int length) can return a path with '..' in it. SymInitialize doesn't play well with this, so the path needs to be sanitized prior to usage

wc-duck commented 3 years ago

Do you have any more info on what SymInitialize() requires for its paths? From the documentation of GetModuleFileName() the out name is "The string returned will use the same format that was specified when the module was loaded. Therefore, the path can be a long or short file name, and can use the prefix \?. For more information, see Naming a File." So I'm mostly wondering what kind of normalization that need to be done here? Do we know if SymInitialize can handle short-paths and \?-prefixes?

wc-duck commented 3 years ago

Another question... I'm not really sure how I would handle something like this. If I get the path '../whoppa' I need to first get the absolute path. But if the application has changed cwd() I'm not really sure where the '..' is from? I could of course just normalize something like "whoho/../whaha/./whopp" but is that the problem you have or is it just that your app switched working dir?

fredrikz commented 3 years ago

Hmm, I see I've left out some vital information on how to reproduce the issue. Great. Because now I don't remember :)

I believe that in our case, we launched the application with '..' in the path, i.e. in a command prompt, launch an exe with:

C:\Folder>..\Folder2\my_program.exe

Which would result in a path inside the program which would be "C:\Folder\..\Folder2\my_program.exe". I'm not 100% certain this was the repro, so I'll look around a bit.

wc-duck commented 3 years ago

I have tried a lot of cases here on the machine I have access to and I can only get GetModulePath() to return absolute-paths... But I guess this might be some version problem or similar. I'll keep this bug open for reference until someone can reproduce it :) I'm however thinking about adding a log of what version of dbghelp.dll is loaded IF DBGTOOLS_SYMBOL_DEBUG_OUTPUT is in the environment.

wc-duck commented 3 years ago

I also did a test to just hard code paths with dots all over the place and I still worked so that might be due to the version of dbghelp.dll that is loaded?