[PATCH] D30107: Make DynamicLibrary::getPermanentLibrary have a defined ordering.
Frederich Munch via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Feb 23 14:54:06 PST 2017
marsupial added inline comments.
================
Comment at: lib/Support/Windows/DynamicLibrary.inc:66
+ Current.resize(Bytes / sizeof(HMODULE));
+ if (!EnumProcessModulesEx(Self, Current.data(), Bytes, &Bytes, Flags)) {
+ MakeErrMsg(errMsg, "EnumProcessModulesEx failure");
----------------
marsupial wrote:
> vsk wrote:
> > marsupial wrote:
> > > vsk wrote:
> > > > Could you explain with some more detail why EnumProcessModulesEx needs to be repeated until its results don't change? Is there any guarantee that its results won't change again after this loop terminates?
> > > >
> > > > Apologies if my Windows ignorance is showing here...
> > > There is a small chance of thread A calling EnumProcessModulesEx to get the size of the list and in between that and EnumProcessModulesEx to get the actual list that thread B does something to explicitly or implicitly load another dll.
> > If there isn't a guarantee that, e.g a third thread C couldn't load another dylib after this loop terminates, I don't think we should have the loop.
> Generally I agree, but the cost of one compare that will most likely succeed to deal with an obscure event that would be hard to debug seems prudent?
Turns out the MSDN docs are pretty clear about not using the returned list if there has been a change. That is it may be possible for this to occur when [libA, libB, libC] are loaded:
Thread0: EnumProcessModulesEx: returns 3 for number of elements required
Thread0: EnumProcessModulesEx: called with HMODULE[3]
Thread1: FreeLibrary("libB")
Thread0: EnumProcessModulesEx: returns with [libA, libB, libC]
https://reviews.llvm.org/D30107
More information about the llvm-commits
mailing list