4 ms·

> Note: this may be overzealous but to avoid legal issues I will not name that browser or the files/functions involved Curious, anyone else want to name the br

> Note: this may be overzealous but to avoid legal issues I will not name that browser or the files/functions involved Curious, anyone else want to name the browser?

benmmurphy 2y ago
it's probably not chrome because they are using this third party library: (https://github.com/fmtlib/fmt https://github.com/fmtlib/fmt). also, it might be that this sink is actually meant to write a message to the console but due to configuration options its a noop. though, i guess its unlikely the registers would have a string view [?] so maybe it is meant to be a noop.
lcampbell 2y ago
This looks like it, I think: https://searchfox.org/mozilla-central/source/toolkit/xre/dllservices/mozglue/WindowsDllBlocklist.cpp#556 https://searchfox.org/mozilla-central/source/toolkit/xre/dll...
- int0x29 2y ago
  This feels like excessive concern for OSS. Mozilla gets touchy about trademarks generally not code
  - dblohm7 2y ago
    Third party DLLs injected into browser processes cause all kinds of crash spikes.
syncsynchalt 2y ago
Looks like firefox: https://searchfox.org/mozilla-central/source/toolkit/xre/dllservices/mozglue/WindowsDllBlocklist.cpp#526 https://searchfox.org/mozilla-central/source/toolkit/xre/dll... (via https://searchfox.org/mozilla-central/source/toolkit/xre/dllservices/mozglue/WindowsDllBlocklist.cpp#559 https://searchfox.org/mozilla-central/source/toolkit/xre/dll... ) I'd assumed it would be Edge since the author was crawling through decompiled output and worrying about litigiousness, but the above code in a BaseThreadInitThunk() interceptor matches what the author is describing.
- Randor 2y ago
  Some horrible code in there too: https://searchfox.org/mozilla-central/source/toolkit/xre/dllservices/mozglue/WindowsDllBlocklist.cpp#452 https://searchfox.org/mozilla-central/source/toolkit/xre/dll... Indiscriminate blocking of any DLL in the world with 12/6 hex digit filenames.
  - kimixa 2y ago
    Reading the bug report https://bugzilla.mozilla.org/show_bug.cgi?id=973138 https://bugzilla.mozilla.org/show_bug.cgi?id=973138 feels reasonable. It must be hard to be in a position to be blamed for someone else's bad code - or even malware - one comment said it was 1/3 of the total crashes on Vista at the time. As a GPU driver dev I 100% understand this position - no user cares that gamedevs are hacking things left and right, they care if it runs.
    - ack_complete 2y ago
      There's plenty of blame to go around, really. My current project has a workaround for a user-mode graphics driver that sets the thread name without checking if D3D11_CREATE_DEVICE_SINGLETHREADED is set -- so there's code to detect this and call SetThreadDescription() to change it back so the main thread can be found in the debugger again. There also used to be a problem with a release DLL in Windows 10 that would output to OutputDebugString() with an encoding mismatch, thus spamming the debug output window with random kanji. I've heard that the Office team has resorted to detouring SetUnhandledExceptionFilter() since even they had problems with third party DLLs unhooking their in-process crash handler.
      - kimixa 2y ago
        > There's plenty of blame to go around, really. My current project has a workaround for a user-mode graphics driver that sets the thread name without checking if D3D11_CREATE_DEVICE_SINGLETHREADED is set -- so there's code to detect this and call SetThreadDescription() to change it back so the main thread can be found in the debugger again. I hope that wasn't the one I worked on :P Though I'm surprised that changed much there - the flag just means we can avoid wrapping some state in mutexes (and in many paths is a NOP as the driver still uses multiple threads internally, not worth the gain for the few things they won't touch), I'm surprised that makes it rename the user thread.

> Note: this may be overzealous but to avoid legal issues I will not name that browser or the files/functions involved Curious, anyone else want to name the browser?

benmmurphy 2y ago

it's probably not chrome because they are using this third party library: (https://github.com/fmtlib/fmt https://github.com/fmtlib/fmt). also, it might be that this sink is actually meant to write a message to the console but due to configuration options its a noop. though, i guess its unlikely the registers would have a string view [?] so maybe it is meant to be a noop.

lcampbell 2y ago

This looks like it, I think: https://searchfox.org/mozilla-central/source/toolkit/xre/dllservices/mozglue/WindowsDllBlocklist.cpp#556 https://searchfox.org/mozilla-central/source/toolkit/xre/dll...

int0x29 2y ago
This feels like excessive concern for OSS. Mozilla gets touchy about trademarks generally not code
- dblohm7 2y ago
  Third party DLLs injected into browser processes cause all kinds of crash spikes.

syncsynchalt 2y ago

Looks like firefox: https://searchfox.org/mozilla-central/source/toolkit/xre/dllservices/mozglue/WindowsDllBlocklist.cpp#526 https://searchfox.org/mozilla-central/source/toolkit/xre/dll... (via https://searchfox.org/mozilla-central/source/toolkit/xre/dllservices/mozglue/WindowsDllBlocklist.cpp#559 https://searchfox.org/mozilla-central/source/toolkit/xre/dll... ) I'd assumed it would be Edge since the author was crawling through decompiled output and worrying about litigiousness, but the above code in a BaseThreadInitThunk() interceptor matches what the author is describing.

Randor 2y ago
Some horrible code in there too: https://searchfox.org/mozilla-central/source/toolkit/xre/dllservices/mozglue/WindowsDllBlocklist.cpp#452 https://searchfox.org/mozilla-central/source/toolkit/xre/dll... Indiscriminate blocking of any DLL in the world with 12/6 hex digit filenames.
- kimixa 2y ago
  Reading the bug report https://bugzilla.mozilla.org/show_bug.cgi?id=973138 https://bugzilla.mozilla.org/show_bug.cgi?id=973138 feels reasonable. It must be hard to be in a position to be blamed for someone else's bad code - or even malware - one comment said it was 1/3 of the total crashes on Vista at the time. As a GPU driver dev I 100% understand this position - no user cares that gamedevs are hacking things left and right, they care if it runs.
  - ack_complete 2y ago
    There's plenty of blame to go around, really. My current project has a workaround for a user-mode graphics driver that sets the thread name without checking if D3D11_CREATE_DEVICE_SINGLETHREADED is set -- so there's code to detect this and call SetThreadDescription() to change it back so the main thread can be found in the debugger again. There also used to be a problem with a release DLL in Windows 10 that would output to OutputDebugString() with an encoding mismatch, thus spamming the debug output window with random kanji. I've heard that the Office team has resorted to detouring SetUnhandledExceptionFilter() since even they had problems with third party DLLs unhooking their in-process crash handler.
    - kimixa 2y ago
      > There's plenty of blame to go around, really. My current project has a workaround for a user-mode graphics driver that sets the thread name without checking if D3D11_CREATE_DEVICE_SINGLETHREADED is set -- so there's code to detect this and call SetThreadDescription() to change it back so the main thread can be found in the debugger again. I hope that wasn't the one I worked on :P Though I'm surprised that changed much there - the flag just means we can avoid wrapping some state in mutexes (and in many paths is a NOP as the driver still uses multiple threads internally, not worth the gain for the few things they won't touch), I'm surprised that makes it rename the user thread.