Fix PDB loading for valid stacktraces

[sledgehammer999]

This was discovered by investigating #18339 (comment)

[glassez]

This was discovered by investigating #18339 (comment)

Could you clarify what's the problem did you find?

[sledgehammer999]

@glassez @xavier2k6 let's continue here for the stacktrace talk.

From #18452 (comment)

I can reproduce the issue @xavier2k6 is mentioning but inserting a deliberate crash. Running the app from inside WinDbg I can get a meaningful stacktrace. This at least denotes that the *.pdb file isn't corrupted.
I doubt that this has something to do with the SDK version used. My hunch is that this is a misconfiguration of Boost.Stacktrace. I am doing tests now to see if I can fix it.
Reminder: Our stacktrace functionality changed backends in v4.5.0.

What I have discovered so far:
The stacktrace functionality is affected by the current working directory of qbittorrent. It affects where it looks for the .pdb file. We correctly encode the path as simply "qbittorrent.pdb". However, Boost.Stacktrace uses it as a relative path to CWD and not relative to our .exe path. This may be a bug of Boost.Stacktrace.

@xavier2k6 I don't know how you started the official build in your tests. Was it via the start menu/desktop shortcut? If so, they were setting CWD wrongly before this PR.
By opening it via terminal command while your CWD was another dir?
By opening a torrent/magnet via browser? In this last case, windows seems to set a different CWD (probably the location of the passed file) than the installation path. I can't find if there are registry keys that control the CWD for file/uri associations. And even if there are, they may produce other sideffects. Like not being able to load files passed by relative paths.

@xavier2k6 for official builds: Test by right clicking the shortcuts->properties->Start in and correcting the path. It should produce valid stacktrace.
For unofficial builds launch via terminal while in another directory. It should produce invalid stacktrace.

[sledgehammer999]

glassez wrote (#18452 (comment)):

Could you try dumpbin /PDBPATH:VERBOSE <qbtinstallation_path>/qbittorrent.exe with official binary?

It still finds the pdb.
And dumpbin /HEADERS shows the path as simply "qbittorrent.pdb" which is the expected. (Scroll down until you encounter Debug Directories)

[glassez]

However, Boost.Stacktrace uses it as a relative path to CWD and not relative to our .exe path. This may be a bug of Boost.Stacktrace.

I would consider it as bug. Would you mind to report it to Boost?

[sledgehammer999]

I would consider it as bug. Would you mind to report it to Boost?

Sure but I would wait for some confirmation on these:
For official builds: Test by right clicking the shortcuts->properties->Start in and correcting the path. It should produce valid stacktrace.
For unofficial builds launch via terminal while in another directory. It should produce invalid stacktrace.

Can you and @xavier2k6 do a test in case I am wrong?

[xavier2k6]

Just a quick test with official 4.5.0 installed on windows 11, right clicked shortcut & indeed the start-in path was incorrect, it was starting in the translations folder.

I corrected it & it now produces valid stack traces.......should have initially tested in portable mode on my first investigation.....would've probably had shed light on where issue was sooner.

Will test other options you asked about in the morning.

[glassez]

Windows deployment and symbol files

So storing a relative pdb path in executable looks like the recommended way. It is hardly assumed that such unreliable behavior when it is searched in the working directory, which is unpredictable, is what is actually intended.

[glassez]

Unfortunately this patch will not solve the problem in all the cases (i.e. when qBittorrent started in another way than via shortcut).
What if try to set _NT_ALT_SYMBOL_PATH environment variable at the qBittorrent startup? Maybe Boost.Stacktrace handles it correctly?

[sledgehammer999]

Unfortunately this patch will not solve the problem in all the cases

To clarify. This patch stands on its own. Now the CWD of the shortcut is set to install_path\translations which is plainly wrong.

What if try to set _NT_ALT_SYMBOL_PATH environment variable at the qBittorrent startup?

We could. But this solution feels like a kludge.

[sledgehammer999]

Pushed an additional commit and changed PR title. (A different PR would have split the discussion yet again).
With this new commit stacktrace loading seems to work regardless of the CWD.

[glassez]

To clarify. This patch stands on its own. Now the CWD of the shortcut is set to install_path\translations which is plainly wrong.

👍
It should close #18442.

[glassez]

What if try to set _NT_ALT_SYMBOL_PATH environment variable at the qBittorrent startup?

We could. But this solution feels like a kludge.

SymInitialize function (dbghelp.h)
Symbol path for Windows debuggers

It seems that this is still the usual behavior of Windows debugging tools, that it does not look for symbols in the executable file folder. To achieve this, we need to add executable folder to symbol search path. This can be done by calling the appropriate functions. Earlier, when we used a different implementation of stack trace support, I happened to make the changes to specify the application folder for symbol search. But now we don't use Windows debugging functions directly (their use is hidden inside Boost.Stacktrace), so we are left with another suggested way - to use environment variables (I don't see anything wrong with that).

[sledgehammer999]

It should close #18442

I don't know if it closes that bug.
When someone tries to open the torrent folder there are two possibilities. The folder exists or not. If it exists Explorer opens that folder. If it doesn't exist Explorer silently fails (aka no window is shown).
I don't see how the CWD can be shown, or anything different than the torrent folder.

[oorzkws]

Has this been broken for some time? Ref: #17949 (comment)

[glassez]

Has this been broken for some time? Ref: #17949 (comment)

Seems the issue is here since 5c3c6b6.