1793909 - Crash in [@ `static class WRL::Module<T>::Details::DefaultModule<T>& Microsoft::WRL::Module<T>::Create'::`2'::moduleSingleton::`dynamic atexit destructor']

Status: NEW

(Core :: Widget: Win32, defect, P5)

Description

[Gabriele Svelto [:gsvelto]]

Crash report: https://crash-stats.mozilla.org/report/index/be93aa01-1671-40e8-a445-219f90221006

Reason: EXCEPTION_ACCESS_VIOLATION_WRITE

Top 10 frames of crashing thread:

0 TextInputFramework.dll void `static class WRL::Module<1, class Microsoft::WRL::Details::DefaultModule<1> >::Details::DefaultModule<1>& Microsoft::WRL::Module<1, class Microsoft::WRL::Details::DefaultModule<1> >::Create'::`2'::moduleSingleton::`dynamic atexit destructor' 
1 TextInputFramework.dll virtual long CGetSelectionAsync::RunContinuation 
2 TextInputFramework.dll virtual long TextInputClient::EditControlRegister 
3 TextInputFramework.dll virtual void* std::_Func_impl<struct std::_Callable_obj<class <lambda_fd5862b078e28acefb4844d5d2fbcbbb>, 0>, class std::allocator<class std::_Func_class<long, struct std::_Nil, struct std::_Nil, struct std::_Nil, struct std::_Nil, struct std::_Nil, struct std::_Nil, struct std::_Nil> >, long, struct std::_Nil, struct std::_Nil, struct std::_Nil, struct std::_Nil, struct std::_Nil, struct std::_Nil, struct std::_Nil>::`vector deleting destructor' 
4 TextInputFramework.dll virtual long CTextInputClientFreeThread::EditControlRegister 
5 msctf.dll static bool CInputContextAdapter::Create 
6 msctf.dll void CDocumentInputManager::OnFocusChange 
7 msctf.dll long CThreadInputMgr::_SetFocus 
8 msctf.dll virtual long CThreadInputMgr::SetFocus 
9 xul.dll mozilla::widget::TSFTextStore::OnFocusChange widget/windows/TSFTextStore.cpp:5768

Low-volume crash, NULL pointer access apparently. Comments mention that this happens when clicking on elements in the devtools panel after having opened it with F12. Several crashes are coming from users using non-Latin languages, though the vast majority are from users in the en-US locale.

Comment 1

[Gabriele Svelto [:gsvelto]]

Here's another crash signature that's very likely to be the same crash. Given this is deep in Windows libraries and the signature is pretty specific there's chances that there are plenty more.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Since the crash volume is low (less than 15 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.

Comment 4

[Gabriele Svelto [:gsvelto]]

This is a signature change, the new signature is [@ `Microsoft::WRL::Module<T>::Create'::`2'::moduleSingleton::`dynamic atexit destructor' ]

Comment 5

[[e-mail]]

One of our users reported a reproducible crash
https://crash-stats.mozilla.org/report/index/f422d38a-5b74-4080-8eb7-f492a0240710#tab-details
with these STR:

1. Go to this website: https://streamable.com/uvlx0k
2. Right-click on video and select 'Copy Video URL' option
3. Paste into new compose window. Window hangs.
4. Click with mouse pointer on 'To', 'Subject', and content sections, app crashes.

We can't reproduce it. Note that the HTML pasted from FIrefox (not Chrome) contains absolutely placed content, xref bug 1276391.

Comment 6

[Ray Kraesig [:rkraesig]]

(In reply to [e-mail] from comment #5)

One of our users reported a reproducible crash [...]

We can't reproduce it.

The crash (both this crash report and all others with the same signature that I've looked at) seems to be in IME-related code. Can you check with the user what IME and language they use, and if they can still reproduce it with the keyboard set to US English?

Comment 7

[[e-mail]]

Thanks, will try to get this info, see the GitHub ticket quoted in comment #5.

Comment 8

[xpilarz0]

(In reply to Ray Kraesig [:rkraesig] from comment #6)

The crash (both this crash report and all others with the same signature that I've looked at) seems to be in IME-related code. Can you check with the user what IME and language they use, and if they can still reproduce it with the keyboard set to US English?

Hey,
OS: Windows 10.
OS Language: Polish.
IME: POL.

I've tried using ENG keyboard layout (US EN) and crash still occurs.
I've installed english dictionary for Thunderbird and tried it while creating new mail. Still crash occurs.

Repo:

1. Copy video URL by RMB on video using Firefox version 113.0.1 (64 bity)
2. Paste video URL into section where you create email's content. Nothing appears.
3. Focus 'To' section by clicking on it.
4. Focus email content section on clicking on it (where we pasted clipboard content)
5. crash occurs.

Comment 9

[Ray Kraesig [:rkraesig]]

That's odd. I don't believe Polish actually uses an IME, just a language-specific keyboard. The references to IME in the stack seem to be in Mozilla code, though, so this may be a misdetection on our end, or possibly just a unified code path I'm not familiar with.

I haven't been able to reproduce this locally. It's a bit of a long-shot, but: can you open a separate instance of Firefox (e.g., using a separate profile), go to this pseudo-URL...

data:text/html,<body><p>To: <input text></p><div style="height:500px;border:solid 1px" contenteditable>

... and try the steps-to-reproduce on that?

Comment 10

[[e-mail]]

That's odd. I don't believe Polish actually uses an IME, just a language-specific keyboard.

Correct. They actually use a US English layout with a few dead keys to get little cedillas and accents. It's called "Polish Programmers" (http://kbdlayout.info/KBDPL1/).

Comment 11

[xpilarz0]

This is what I get when viewing clipboard data using 'clipview' (http://www.peterbuettner.de/develop/tools/clipview/)

49319: HTML Format:

Version:0.9
StartHTML:00000138
EndHTML:00000324
StartFragment:00000172
EndFragment:00000288
SourceURL:https://streamable.com/uvlx0k
<html><body>
<!--StartFragment--><div style="position: absolute; user-select: text; top: -1000px; left: -1000px;">https://streamable.com/uvlx0k</div><!--EndFragment-->
</body>
</html>

You can copy this text, paste it to 'clipview' and use 'Push in Clip' button with 'HTML Format' (box next to button) to populate your clipboard with this data in correct format.
Pasting this data in Thunderbird as email content (following my repro steps) crashes program.

I noticed that if any letter was entered in email's content section before pasting clipboard data then the crash does not occur.

Comment 12

[xpilarz0]

I tried the repo on other Windows 10 machine and the crash does not occur.

This may be Window's 10 clipboard bug.

OS where crash occurs: Windows 10 Pro 1703
OS where crash does not occur: Windows 10 Pro 21H1

Comment 13

[xpilarz0]

(In reply to Ray Kraesig [:rkraesig] from comment #9)

That's odd. I don't believe Polish actually uses an IME, just a language-specific keyboard. The references to IME in the stack seem to be in Mozilla code, though, so this may be a misdetection on our end, or possibly just a unified code path I'm not familiar with.

I haven't been able to reproduce this locally. It's a bit of a long-shot, but: can you open a separate instance of Firefox (e.g., using a separate profile), go to this pseudo-URL...

data:text/html,<body><p>To: <input text></p><div style="height:500px;border:solid 1px" contenteditable>

... and try the steps-to-reproduce on that?

This works fine.

I guess that Thunderbird uses an HTML parser that works on new versions of Windows but doesn't work on old ones?

Comment 14

[xpilarz0]

I tried to reproduce this problem in Microsoft Outlook Pro 2019, but there they do not format the contents of the clipboard as HTML, only pastes the link to the page (no matter what type of formatting I choose) - which in my opinion is the correct behavior.

Comment 15

[Ray Kraesig [:rkraesig]]

(In reply to xpilarz0 from comment #11)

This is what I get when viewing clipboard data using 'clipview' (http://www.peterbuettner.de/develop/tools/clipview/)
[...]
You can copy this text, paste it to 'clipview' and use 'Push in Clip' button with 'HTML Format' (box next to button) to populate your clipboard with this data in correct format.
Pasting this data in Thunderbird as email content (following my repro steps) crashes program.

This is identical to what I'm seeing via NirSoft's InsideClipboard. Whatever the difference between your machine and mine is, this isn't it. (This test does rule out that it might be the additional Firefox-specific metadata in the clipboard that's causing the problem, though.)

 

(In reply to xpilarz0 from comment #13)

I guess that Thunderbird uses an HTML parser that works on new versions of Windows but doesn't work on old ones?

Thunderbird is based on Firefox ESR 115. Unless the Thunderbird folks have been doing some very surprising things, the HTML parser is shared between the two; and Firefox ESR 115's HTML parser works fine on all versions of Windows, as far as we're aware. (Although it wouldn't be a bad idea to test that pseudo-URL in ESR 115 on your machine. If you do, just make sure to install it to a separate location, and copy the link from a non-ESR Firefox!) The crash isn't in the HTML parser anyway, but in Windows-side code, on the ITfThreadMgr::SetFocus call that occurs well after the HTML has been parsed and rendered.

...I could believe that this is actually a Windows bug that Microsoft fixed sometime between 1709 and 21H1, but it's a little early to conclude that.

 

(In reply to xpilarz0 from comment #14)

I tried to reproduce this problem in Microsoft Outlook Pro 2019, but there they do not format the contents of the clipboard as HTML, only pastes the link to the page (no matter what type of formatting I choose) - which in my opinion is the correct behavior.

Reasonable; but that would be a different bug — this one's just about the crash.

Comment 16

[xpilarz0]

I tried to reproduce this problem in ESR 115 using that pseudo-URL. As in the case of Firefox 113.0.1 (64 bit), there is no crash after pasting the contents of the clipboard (from Firefox 113.0.1) and changing the focus between fields (but nothing was shown - just like in Thunderbird).

Comment 17

[Ray Kraesig [:rkraesig]]

Attachment: copy-test.html

The attached (very tiny, manually-inspectable) HTML file has a "Copy" button which loads a similar HTML fragment to the clipboard, but with the URL changed. If you run the repro procedure with this in place of the streamable.com URL, does the crash still occur?

If so then the problem is with just with pasting, as we thought. If not, then there may be something odd going on with Thunderbird recognizing and transcluding certain classes of URLs.

(And either way this should make testing easier in five years when someone's trying to check whether or not this bug has regressed.)

Comment 18

[xpilarz0]

(In reply to Ray Kraesig [:rkraesig] from comment #17)

If you run the repro procedure with this in place of the streamable.com URL, does the crash still occur?

yes, crash still occurs.

The strange thing is that if the section with the content of the email is not empty (e.g. I enter the letter 'a'), pasting the contents of the clipboard does not cause a crash (regardless of whether I paste the content before or after this letter; RMB or ctrl+v).

Crash occurs when I try to focus email content section again after pasting clipboard data.

Comment 19

[Ray Kraesig [:rkraesig]]

(In reply to Ray Kraesig [:rkraesig] from comment #15)

...I could believe that this is actually a Windows bug that Microsoft fixed sometime between 1709 and 21H1, but it's a little early to conclude that.

Welp. It's not too early to conclude that anymore.

While I haven't been able to aggregate over minor OS versions in crash-stats, all examined crashes appear to be tagged as Windows build version "10.0.15063" — more commonly known as Windows 10 version 1703.

Ordinarily I'd close this as RESOLVED INVALID, as is customary for upstream-resolved Windows bugs; but this is a common enough crash that implementing a workaround might be a good idea, even if we can't prioritize it highly.