Sandbox crashes with dtrampo.dll (Beijing Huorong Network Technology Co., Ltd.)
Categories
(External Software Affecting Firefox :: Other, defect, P2)
Tracking
(firefox-esr60 unaffected, firefox-esr68 unaffected, firefox68 unaffected, firefox69+ disabled, firefox70 ?)
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox-esr68 | --- | unaffected |
firefox68 | --- | unaffected |
firefox69 | + | disabled |
firefox70 | --- | ? |
People
(Reporter: philipp, Unassigned)
References
(Regression)
Details
(Keywords: crash, regression)
Crash Data
This bug is for crash report bp-7dfeb2ba-2df4-4eee-998a-d832d0190710.
Top 10 frames of crashing thread:
0 firefox.exe base::win::internal::ScopedHandleVerifier::OnHandleBeingClosed security/sandbox/chromium/base/win/scoped_handle_verifier.cc:206
1 firefox.exe static int mozilla::sandboxing::patched_CloseHandle security/sandbox/win/SandboxInitialization.cpp:29
2 dtrampo.dll dtrampo.dll@0x62bf
3 dtrampo.dll dtrampo.dll@0x8166
4 dtrampo.dll dtrampo.dll@0xc475
5 @0x5320c9f
6 kernelbase.dll FreeLibraryAndExitThread
7 ucrtbase.dll common_end_thread
8 ucrtbase.dll thread_start<unsigned int >
9 kernel32.dll BaseThreadInitThunk
these browser crash reports with involvement from the 3rd-party module "dtrampo.dll" (from Beijing Huorong Network Technology Co., Ltd.) are starting to show up from 32bit builds on windows in firefox 69.
Comment 1•5 years ago
|
||
Do we just need a blocklist entry here?
Comment 2•5 years ago
|
||
This is from a chromium sandbox feature related to close handle checks. Bob is going to look at this, technically it shouldn't be enabled beyond early beta.
Comment 3•5 years ago
|
||
(In reply to Jim Mathies [:jimm] from comment #2)
This is from a chromium sandbox feature related to close handle checks. Bob is going to look at this, technically it shouldn't be enabled beyond early beta.
This isn't actually crashing where I thought it was.
This isn't code trying to close a handle that is tracked, it appears to be getting an invalid (null or destroyed) handle verifier and failing when it tries to get a thread local member [1]
That's possibly because this appears to be happening during shutdown, looking at the dumps.
It should go away once EARLY_BETA_OR_EARLIER in not defined, but it still raises the questions as to what this DLL is doing.
It's possible that the sandbox changes, which affect the exe, are causing some assumptions they're making to no longer be true.
This code has moved classes/files in the changes from bug 1552160, but hasn't essentially changed.
Comment 4•5 years ago
|
||
The priority flag is not set for this bug.
:marcia, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•5 years ago
|
Reporter | ||
Comment 5•5 years ago
|
||
crashes are indeed gone in 69.0b8 which is the first build no longer flagged as early beta.
Comment 6•3 years ago
|
||
Closing because no crashes reported for 12 weeks.
Updated•2 years ago
|
Description
•