SymInitialize gets broken search paths

[fredrikz]

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]

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]

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]

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]

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]

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?