(In reply to Yannis Juglaret [:yannis] from comment #4) > Note that when we only have a cycle because of blocking. If we do not block the DLL, we avoid the cycle: > - if the DLL loads successfully, further calls into `PeekMessageW` will not call into `_ClientLoadLibrary` for the same library anymore, they will call the hook directly; > - if the DLL fails to load for another reason than blocking (e.g. `DllMain` returns `FALSE` on `DLL_PROCESS_ATTACH`), [we do not generate any DLL load event](https://searchfox.org/mozilla-central/source/toolkit/xre/dllservices/mozglue/LoaderObserver.cpp#61-66). [:gcp] noticed that by blaming that code, we can see that the events related to failure to load a blocked DLL were added in bug 1686229 to log DLLs that were actively blocked in third-party module pings. We think we should be able to break the cycle by sending at most one event per blocked DLL, e.g. keeping a hashmap of blocked DLLs for which we already sent an event.
Bug 1823412 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Yannis Juglaret [:yannis] from comment #4) > Note that when we only have a cycle because of blocking. If we do not block the DLL, we avoid the cycle: > - if the DLL loads successfully, further calls into `PeekMessageW` will not call into `_ClientLoadLibrary` for the same library anymore, they will call the hook directly; > - if the DLL fails to load for another reason than blocking (e.g. `DllMain` returns `FALSE` on `DLL_PROCESS_ATTACH`), [we do not generate any DLL load event](https://searchfox.org/mozilla-central/source/toolkit/xre/dllservices/mozglue/LoaderObserver.cpp#61-66). [:gcp] noticed that by blaming that code, we can see that the events we register after a failure to load a blocked DLL were added in bug 1686229. They allow us to log in third-party module pings which DLLs have been actively blocked. We think we should be able to break the cycle by sending at most one event per blocked DLL, e.g. keeping a hashmap of blocked DLLs for which we already sent an event.
(In reply to Yannis Juglaret [:yannis] from comment #4) > Note that when we only have a cycle because of blocking. If we do not block the DLL, we avoid the cycle: > - if the DLL loads successfully, further calls into `PeekMessageW` will not call into `_ClientLoadLibrary` for the same library anymore, they will call the hook directly; > - if the DLL fails to load for another reason than blocking (e.g. `DllMain` returns `FALSE` on `DLL_PROCESS_ATTACH`), [we do not generate any DLL load event](https://searchfox.org/mozilla-central/source/toolkit/xre/dllservices/mozglue/LoaderObserver.cpp#61-66). [:gcp] noticed that by blaming that code, we can see that the events we register after a failure to load a blocked DLL were added in bug 1686229. They allow us to log information in third-party module pings about which DLLs have been actively blocked. We think we should be able to break the cycle by sending at most one event per blocked DLL, e.g. keeping a hashmap of blocked DLLs for which we already sent an event.
(In reply to Yannis Juglaret [:yannis] from comment #4) > Note that when we only have a cycle because of blocking. If we do not block the DLL, we avoid the cycle: > - if the DLL loads successfully, further calls into `PeekMessageW` will not call into `_ClientLoadLibrary` for the same library anymore, they will call the hook directly; > - if the DLL fails to load for another reason than blocking (e.g. `DllMain` returns `FALSE` on `DLL_PROCESS_ATTACH`), [we do not generate any DLL load event](https://searchfox.org/mozilla-central/source/toolkit/xre/dllservices/mozglue/LoaderObserver.cpp#61-66). [:gcp] noticed that by blaming that code, we can see that the possibility to register events about failure to load a blocked DLL was added in bug 1686229. They allow us to log information in third-party module pings about which DLLs have been actively blocked. We think we should be able to break the cycle by sending at most one event per blocked DLL, e.g. keeping a hashmap of blocked DLLs for which we already sent an event.
(In reply to Yannis Juglaret [:yannis] from comment #4) > Note that when we only have a cycle because of blocking. If we do not block the DLL, we avoid the cycle: > - if the DLL loads successfully, further calls into `PeekMessageW` will not call into `_ClientLoadLibrary` for the same library anymore, they will call the hook directly; > - if the DLL fails to load for another reason than blocking (e.g. `DllMain` returns `FALSE` on `DLL_PROCESS_ATTACH`), [we do not generate any DLL load event](https://searchfox.org/mozilla-central/source/toolkit/xre/dllservices/mozglue/LoaderObserver.cpp#61-66). [:gcp] noticed that by blaming that code, we can see that the possibility to register events about failure to load a blocked DLL was added in bug 1686229. It allows us to log information in third-party module pings about which DLLs have been actively blocked. We think we should be able to break the cycle by sending at most one event per blocked DLL, e.g. keeping a hashmap of blocked DLLs for which we already sent an event.
(In reply to Yannis Juglaret [:yannis] from comment #4) > Note that when we only have a cycle because of blocking. If we do not block the DLL, we avoid the cycle: > - if the DLL loads successfully, further calls into `PeekMessageW` will not call into `_ClientLoadLibrary` for the same library anymore, they will call the hook directly; > - if the DLL fails to load for another reason than blocking (e.g. `DllMain` returns `FALSE` on `DLL_PROCESS_ATTACH`), [we do not generate any DLL load event](https://searchfox.org/mozilla-central/source/toolkit/xre/dllservices/mozglue/LoaderObserver.cpp#61-66). [:gcp] noticed that by blaming that code, we can see that the possibility to register events about failure to load a blocked DLL was added in bug 1686229. It allows us to log information in third-party module pings about which DLLs have been actively blocked. We think we should be able to break the cycle by sending at most one event per blocked DLL.
(In reply to Yannis Juglaret [:yannis] from comment #4) > Note that we only have a cycle because of blocking. If we do not block the DLL, we avoid the cycle: > - if the DLL loads successfully, further calls into `PeekMessageW` will not call into `_ClientLoadLibrary` for the same library anymore, they will call the hook directly; > - if the DLL fails to load for another reason than blocking (e.g. `DllMain` returns `FALSE` on `DLL_PROCESS_ATTACH`), [we do not generate any DLL load event](https://searchfox.org/mozilla-central/source/toolkit/xre/dllservices/mozglue/LoaderObserver.cpp#61-66). [:gcp] noticed that by blaming that code, we can see that the possibility to register events about failure to load a blocked DLL was added in bug 1686229. It allows us to log information in third-party module pings about which DLLs have been actively blocked. We think we should be able to break the cycle by sending at most one event per blocked DLL.