[Lldb-commits] [PATCH] D55142: Minidump debugging using the native PDB reader

[Adrian McCarthy via lldb-commits]

I believe the PDB is searched for in the EXE directory before the symbol
search path is used.  At least, that's what it used to do, back when I used
VS debugger for post-mortem debugging.  It was the only sane way to ensure
it would find the right version of the PDB if you didn't have a local
symbol server.

Yes, I understand that the security note was about DLL loading.  My point
was that, in general, Windows looks in well known places first, before
checking the current working directory.

On Tue, Dec 11, 2018 at 2:12 PM Leonard Mosescu <mosescu at google.com> wrote:

> The Windowsy thing to do is what Zach said:  Check the directory that
>> contains the .dmp for the .pdb.  It's the first place the VS debugger looks
>> when opening a minidump.  It's less sensitive to the user's environment.
>> (Making the user change the current working directory for this could be at
>> odds with other bits of the software that look relative the cwd.)
>>
>> https://docs.microsoft.com/en-us/visualstudio/debugger/using-dump-files?view=vs-2017#BKMK_Find_binaries__symbol___pdb__files__and_source_files
>>
>
> Except that it doesn't :) Neither VisualStudio nor the Windows Debuggers
> (windbg & co) look for PDBs in the same directory as the dump file. The
> search is controlled by an explicit "symbol search path". The link you
> mentioned is a bit confusing indeed (although it only claims that the
> .exe's are searched in the same directory as the .dmp)
>
> While security is not a big issue here, note that Windows generally
>> searches for DLLs in the known/expected places _before_ checking to see if
>> it's in the current working directory.  This prevents a sneaky download
>> from effectively replacing a DLL.  Replacing a PDB is probably less of a
>> concern.
>>
>> https://docs.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications
>>
>
> This is about the runtime dynamic module loader, not the debugger.
>
>
>
>
> On Tue, Dec 11, 2018 at 1:28 PM Adrian McCarthy <amccarth at google.com>
> wrote:
>
>> It's really frustrating how the email discussion doesn't always make it
>> to Phabricator.
>>
>> The Windowsy thing to do is what Zach said:  Check the directory that
>> contains the .dmp for the .pdb.  It's the first place the VS debugger looks
>> when opening a minidump.  It's less sensitive to the user's environment.
>> (Making the user change the current working directory for this could be at
>> odds with other bits of the software that look relative the cwd.)
>>
>>
>> https://docs.microsoft.com/en-us/visualstudio/debugger/using-dump-files?view=vs-2017#BKMK_Find_binaries__symbol___pdb__files__and_source_files
>>
>> While security is not a big issue here, note that Windows generally
>> searches for DLLs in the known/expected places _before_ checking to see if
>> it's in the current working directory.  This prevents a sneaky download
>> from effectively replacing a DLL.  Replacing a PDB is probably less of a
>> concern.
>>
>>
>> https://docs.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications
>>
>> So I +1 Zach's proposal.
>>
>> On Tue, Dec 11, 2018 at 12:07 PM Leonard Mosescu <mosescu at google.com>
>> wrote:
>>
>>> I think as combination of explicit symbol search path + something
>>> similar to Microsoft's symsrv would be a good "real" solution (and yes,
>>> that would be packaged as a SymbolVendor, outside SymbolFilePDB)
>>>
>>> For short term, I don't see a clearly superior alternative to searching
>>> the current directory.
>>>
>>> On Tue, Dec 11, 2018 at 12:02 PM Pavel Labath <pavel at labath.sk> wrote:
>>>
>>>> On 11/12/2018 20:34, Zachary Turner wrote:
>>>> > I meant the location of the minidump.  So if you have
>>>> C:\A\B\C\foo.dmp
>>>> > which is the dump file for bar.exe which crashed on another machine,
>>>> > then it would look for C:\A\B\C\bar.pdb.  That actually seems like
>>>> > fairly intuitive behavior to me, but maybe I'm in the minority :)
>>>> >
>>>> > We can see what Pavel, Adrian, and others think though or if they
>>>> have
>>>> > any other suggestions.
>>>> >
>>>>
>>>> It sounds like there is a precedent for searching in CWD. I don't know
>>>> how useful it is (I traced it back to r185366, but it is not mentioned
>>>> there specifically), but it is there, and I guess it's not completely
>>>> nonsensical from the POV of a command line user.
>>>>
>>>> I guess we can just keep that there and not call it a hack (though, the
>>>> fact that the searching happens inside SymbolFilePDB *is* a hack).
>>>>
>>>> Searching in the minidump directory would also make sense somewhat, but
>>>> I expect you would need more plumbing for that to happen (and I don't
>>>> know of a precedent for that).
>>>>
>>>> pl
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20181211/7027db21/attachment.html>