Issue metadata
Sign in to add a comment
|
Chrome_Mac: Crash Report - -[BridgedContentView insertText:replacementRange:] |
||||||||||||||||||||||
Issue descriptionreporter:tapted@google.com Magic Signature: -[BridgedContentView insertText:replacementRange:] Crash link: https://crash.corp.google.com/browse?q=product.name%3D'Chrome_Mac'%20AND%20expanded_custom_data.ChromeCrashProto.magic_signature_1.file_path%20LIKE%20'%25%2Fui%2Fviews%25'%20AND%20product.Version%3D'65.0.3325.88'%20AND%20expanded_custom_data.ChromeCrashProto.magic_signature_1.name%3D'-%5BBridgedContentView%20insertText%3AreplacementRange%3A%5D'&stbtiq=&reportid=&index=0 ------------------------------------------------------------------------------- Sample Report ------------------------------------------------------------------------------- Product name: Chrome_Mac Magic Signature : -[BridgedContentView insertText:replacementRange:] Product Version: 65.0.3325.88 Process type: browser Report ID: 9132190be9ad6539 Report Url: https://crash.corp.google.com/9132190be9ad6539 Report Time: 2018-02-24T19:08:14-08:00 Upload Time: 2018-02-24T19:08:17.647-08:00 Uptime: 104000 ms CumulativeProductUptime: 0 ms OS Name: Mac OS X OS Version: 10.13.3 17D102 CPU Architecture: amd64 CPU Info: family 6 model 69 stepping 1 ------------------------------------------------------------------------------- Crashing thread: Thread index: 0. Stack Quality: 29%. Thread id: 123680. ------------------------------------------------------------------------------- 0x00000001105453f8 (Google Chrome Framework - bridged_content_view.mm: 1431) -[BridgedContentView insertText:replacementRange:] 0x00007fff40577cd0 (AppKit + 0x001c0cd0) 0x00007fff40e08e58 (AppKit + 0x00a51e58) 0x00007fff40577c7f (AppKit + 0x001c0c7f) 0x00007fff40e06dd0 (AppKit + 0x00a4fdd0) 0x00007fff40e086dc (AppKit + 0x00a516dc) 0x00007fff405778ea (AppKit + 0x001c08ea) 0x00007fff4057786d (AppKit + 0x001c086d) 0x00007fff405773d0 (AppKit + 0x001c03d0) 0x00007fff40576ca0 (AppKit + 0x001bfca0) 0x00007fff42106813 (HIToolbox + 0x00008813) DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) 0x00007fff42105b5c (HIToolbox + 0x00007b5c) SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) 0x00007fff421059d2 (HIToolbox + 0x000079d2) SendEventToEventTargetWithOptions 0x00007fff42159c88 (HIToolbox + 0x0005bc88) SendTSMEvent_WithCompletionHandler 0x00007fff4230a197 (HIToolbox + 0x0020c197) __SendTextInputEvent_WithCompletionHandler_block_invoke 0x00007fff423083bd (HIToolbox + 0x0020a3bd) SendTextInputEvent_WithCompletionHandler 0x00007fff42379fc3 (HIToolbox + 0x0027bfc3) -[IMKInputSession _postEvent:completionHandler:] 0x00007fff423890ef (HIToolbox + 0x0028b0ef) -[IMKInputSession insertText:replacementRange:completionHandler:] 0x00007fff42389bb6 (HIToolbox + 0x0028bbb6) -[IMKInputSession insertText:replacementRange:validFlags:completionHandler:] 0x00007fff4237b00c (HIToolbox + 0x0027d00c) __71-[IMKInputSession imkxpc_insertText:replacementRange:validFlags:reply:]_block_invoke 0x00007fff42e3458b (CoreFoundation + 0x000a358b) __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ 0x00007fff42e17042 (CoreFoundation + 0x00086042) __CFRunLoopDoBlocks 0x00007fff42e16e07 (CoreFoundation + 0x00085e07) __CFRunLoopRun 0x00007fff42e15f42 (CoreFoundation + 0x00084f42) CFRunLoopRunSpecific 0x00007fff423640e8 (HIToolbox + 0x002660e8) -[IMKInputSessionXPCInvocation invocationAwaitXPCReply] 0x00007fff423689da (HIToolbox + 0x0026a9da) -[IMKInputSession deactivate] 0x00007fff4231afbf (HIToolbox + 0x0021cfbf) IMKInputSessionDeactivate 0x00007fff4231a3a2 (HIToolbox + 0x0021c3a2) DeactivateInputMethodInstance 0x00007fff4230c9fc (HIToolbox + 0x0020e9fc) utDeactivateIMforDocument 0x00007fff4215f2e3 (HIToolbox + 0x000612e3) utDeactivateAllIM4Document 0x00007fff4215ee4b (HIToolbox + 0x00060e4b) MyDeactivateTSMDocument 0x00007fff4215ecd6 (HIToolbox + 0x00060cd6) DeactivateTSMDocument 0x00007fff405a8961 (AppKit + 0x001f1961) 0x00007fff40e0dd30 (AppKit + 0x00a56d30) 0x00007fff403db07c (AppKit + 0x0002407c) 0x00007fff404d23cc (AppKit + 0x0011b3cc) 0x00007fff42e1c89e (CoreFoundation + 0x0008b89e) -[__NSArrayM enumerateObjectsWithOptions:usingBlock:] 0x00007fff40ca0ea4 (AppKit + 0x008e9ea4) 0x00007fff403db776 (AppKit + 0x00024776) 0x00007fff403ddc8e (AppKit + 0x00026c8e) 0x00007fff405a8857 (AppKit + 0x001f1857) 0x00007fff404cb98a (AppKit + 0x0011498a) 0x00007fff403ddbce (AppKit + 0x00026bce) 0x00007fff405a8857 (AppKit + 0x001f1857) 0x00007fff405a8521 (AppKit + 0x001f1521) 0x00007fff405a7f6b (AppKit + 0x001f0f6b) 0x000000011145e92a (Google Chrome Framework - autocomplete_text_field.mm: 367) -[AutocompleteTextField textDidEndEditing:] 0x00007fff42e2bbbb (CoreFoundation + 0x0009abbb) __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ 0x00007fff42e2baa9 (CoreFoundation + 0x0009aaa9) _CFXRegistrationPost 0x00007fff42e2b7f1 (CoreFoundation + 0x0009a7f1) ___CFXNotificationPost_block_invoke 0x00007fff42de966f (CoreFoundation + 0x0005866f) -[_CFXNotificationRegistrar find:object:observer:enumerator:] 0x00007fff42de87a2 (CoreFoundation + 0x000577a2) _CFXNotificationPost 0x00007fff44ecd466 (Foundation + 0x00006466) -[NSNotificationCenter postNotificationName:object:userInfo:] 0x00007fff40596e26 (AppKit + 0x001dfe26) 0x00000001114627d0 (Google Chrome Framework - autocomplete_text_field_editor.mm: 346) -[AutocompleteTextFieldEditor resignFirstResponder] 0x00007fff404a90be (AppKit + 0x000f20be) 0x000000011144a910 (Google Chrome Framework - framed_browser_window.mm: 94) -[FramedBrowserWindow makeFirstResponder:] 0x000000010da2d482 (Google Chrome Framework - web_contents_view_mac.mm: 230) content::WebContentsViewMac::Focus() 0x00000001105b049f (Google Chrome Framework - widget.cc: 599) views::Widget::Close() 0x000000011054dbdc (Google Chrome Framework - button.cc: 233) views::Button::OnMouseReleased(ui::MouseEvent const&) 0x0000000110535c61 (Google Chrome Framework - ink_drop_host_view.cc: 263) views::InkDropHostView::OnMouseEvent(ui::MouseEvent*) 0x000000010f8306a1 (Google Chrome Framework - scoped_target_handler.cc: 32) ui::ScopedTargetHandler::OnEvent(ui::Event*) 0x000000010f82ebc3 (Google Chrome Framework - event_dispatcher.cc: 191) ui::EventDispatcher::ProcessEvent(ui::EventTarget*, ui::Event*) 0x000000010f82e9f3 (Google Chrome Framework - event_dispatcher.cc: 86) ui::EventDispatcherDelegate::DispatchEvent(ui::EventTarget*, ui::Event*) 0x00000001105ad15c (Google Chrome Framework - root_view.cc: 442) views::internal::RootView::OnMouseReleased(ui::MouseEvent const&) 0x00000001105b2386 (Google Chrome Framework - widget.cc: 1218) views::Widget::OnMouseEvent(ui::MouseEvent*) 0x0000000110543395 (Google Chrome Framework - bridged_content_view.mm: 642) -[BridgedContentView mouseEvent:] 0x000000011054a701 (Google Chrome Framework - cocoa_mouse_capture.mm: 89) ___ZN5views17CocoaMouseCapture14ActiveEventTap4InitEv_block_invoke 0x00007fff40563365 (AppKit + 0x001ac365) 0x00007fff40b8c529 (AppKit + 0x007d5529) 0x000000010e8ccbf9 (Google Chrome Framework - chrome_browser_application_mac.mm: 267) __34-[BrowserCrApplication sendEvent:]_block_invoke 0x000000010ec87159 (Google Chrome Framework + 0x01dc8159) base::mac::CallWithEHFrame(void () block_pointer) 0x000000010e8cc9d5 (Google Chrome Framework - chrome_browser_application_mac.mm: 251) -[BrowserCrApplication sendEvent:] 0x00007fff403edd9c (AppKit + 0x00036d9c) 0x000000010ec95f5b (Google Chrome Framework - message_pump_mac.mm: 806) base::MessagePumpNSApplication::DoRun(base::MessagePump::Delegate*) 0x000000010ec94add (Google Chrome Framework - message_pump_mac.mm: 180) base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*) 0x000000010ecb8c44 (Google Chrome Framework - run_loop.cc: 130) <name omitted> 0x000000010e8d2117 (Google Chrome Framework - chrome_browser_main.cc: 1973) ChromeBrowserMainParts::MainMessageLoopRun(int*) 0x000000010d642d33 (Google Chrome Framework - browser_main_loop.cc: 1236) content::BrowserMainLoop::RunMainMessageLoopParts() 0x000000010d645701 (Google Chrome Framework - browser_main_runner.cc: 145) content::BrowserMainRunnerImpl::Run() 0x000000010d63f32b (Google Chrome Framework - browser_main.cc: 46) content::BrowserMain(content::MainFunctionParams const&) 0x000000010e884f3f (Google Chrome Framework - content_main_runner.cc: 717) content::ContentMainRunnerImpl::Run() 0x00000001101992aa (Google Chrome Framework - main.cc: 456) service_manager::Main(service_manager::MainParams const&) 0x000000010e884483 (Google Chrome Framework - content_main.cc: 19) content::ContentMain(content::ContentMainParams const&) 0x000000010cec2869 (Google Chrome Framework - chrome_main.cc: 129) ChromeMain 0x000000010a586dd3 (Google Chrome - chrome_exe_main_mac.cc: 165) main 0x00007fff6a729114 (libdyld.dylib + 0x00001114) start 0x00007fff6a729114 (libdyld.dylib + 0x00001114) start ------------------------------------------------------------------------------- Manual regression range finder link ------------------------------------------------------------------------------- https://crash.corp.google.com/browse?q=expanded_custom_data.ChromeCrashProto.magic_signature_1.name%3D'-%5BBridgedContentView%20insertText%3AreplacementRange%3A%5D'#-property-selector,-samplereports,+productname,+productversion:1000,+directory,-clientid,+operatingsystem,+url,+simplifiedurl,+extensions
,
Mar 26 2018
MacViews triage: we have one solitary report of this, so it must be pretty rare. I'm leaving this available and marking it M-X.
,
May 14 2018
So this is weird - 70% of Crashes are happening in Korea. The rest are outliers -- 3-6% each in Vietnam, US, Australia, Japan. Only 1 crash in m67, but this is about 30% of crashes in the current stable channel with *views* in the file path. https://crash.corp.google.com/browse?q=product.name%3D%27Chrome_Mac%27+AND+expanded_custom_data.ChromeCrashProto.magic_signature_1.file_path+LIKE+%27%25%2Fui%2Fviews%25%27+AND+product.Version+LIKE+%2766.0.3359.%25%27+AND+expanded_custom_data.ChromeCrashProto.magic_signature_1.name%3D%27-%5BBridgedContentView+insertText%3AreplacementRange%3A%5D%27
,
Jun 1 2018
Issue 848736 has been merged into this issue.
,
Jun 1 2018
Issue 848736 contains repro steps.
,
Jun 8 2018
I think they're different. Or the repro cases are at least. Issue 848736 has RunMoveLoop() in the stack, but the stack in the description does not.
However, it's possible they can be addressed together.
In a debug build, we hit a dcheck
- (void)insertText:(id)text replacementRange:(NSRange)replacementRange {
if (!hostedView_)
return;
// Verify inputContext is not nil, i.e. |textInputClient_| is valid and no
// menu is active.
DCHECK([self inputContext]);
/* segfault trying to access |textInputClient_| */
Note:
- (NSTextInputContext*)inputContext {
// If the textInputClient_ does not exist, return nil since this view does not
// conform to NSTextInputClient protocol.
if (!textInputClient_)
return nil;
So... why is AppKit dispatching message to BridgedContentView via NSTextInputContext when it returns a nil NSTextInputContext for its inputContext. Humph.
,
Jun 8 2018
yeh - https://chromium-review.googlesource.com/c/chromium/src/+/1092390
,
Jun 9 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4acd4805db0d79872a6ec904e28f1587bada7389 commit 4acd4805db0d79872a6ec904e28f1587bada7389 Author: Trent Apted <tapted@chromium.org> Date: Sat Jun 09 04:20:07 2018 Ensure BridgedContentView informs AppKit when its inputContext changes. AppKit holds on to a raw, weak global pointer pointing to the current NSTextInputContext. The global pointer only updates in [NSApp updateWindows]. Specifically, it updates when -updateWindows invokes +[NSTextInputContext currentInputContext_withFirstResponderSync:]. -updateWindows is invoked on every AppKit event loop iteration, except those run in NSEventTrackingRunLoopMode. The inputContext for a window can also change during the processing of the _current_ event, leaving the old one invalid for later event processing stages. For example, if a views::EventMonitor spies on the event stream and closes a window, the old inputContext could be invalid for the rest of the event processing. This CL adds an explicit call to [NSApp updateWindows] from BridgedContentView whenever its inputContext is changing, and it is responsible for the current inputContext. Bug: 846386, 817097 Change-Id: I2ae21b101bdb0fbc2145b8869d8069cd04605af9 Reviewed-on: https://chromium-review.googlesource.com/1092390 Commit-Queue: Trent Apted <tapted@chromium.org> Reviewed-by: Avi Drissman <avi@chromium.org> Reviewed-by: Sarah Chan <spqchan@chromium.org> Cr-Commit-Position: refs/heads/master@{#565848} [modify] https://crrev.com/4acd4805db0d79872a6ec904e28f1587bada7389/ui/views/cocoa/bridged_content_view.mm [modify] https://crrev.com/4acd4805db0d79872a6ec904e28f1587bada7389/ui/views/cocoa/bridged_native_widget.mm [modify] https://crrev.com/4acd4805db0d79872a6ec904e28f1587bada7389/ui/views/widget/native_widget_mac_interactive_uitest.mm
,
Jun 12 2018
tested in 69.0.3455.0 - should be fixed. I wanna check up on it though. E.g. the "70% of Crashes are happening in Korea." can't really be explained by the known repro case.
,
Jul 2
Just to update the latest behavior of this issue in the latest channels: Still seeing 51 crashes from 33 clients so far on latest beta - 68.0.3440.42 on Mac OS. This crash is ranked as number #1 in 'Browser' beta crashes. 69.0.3479.0 0.08% 1 - Canary 69.0.3472.3 0.71% 9 - Dev 68.0.3440.42 4.13% 52 - Beta 67.0.3396.99 5.72% 72 - Stable Link to the list of builds: ------------------------- https://crash.corp.google.com/browse?q=product_name%3D%27Chrome_Mac%27+AND+expanded_custom_data.ChromeCrashProto.ptype%3D%27browser%27+AND+expanded_custom_data.ChromeCrashProto.magic_signature_1.name%3D%27-%5BBridgedContentView+insertText%3AreplacementRange%3A%5D%27#-productname:1000,productversion:100,-magicsignature:50,-magicsignature2:50,-stablesignature:50,-magicsignaturesorted:50 tapted@ -- Can this fix be merged to beta. Thanks!
,
Jul 3
96.00% of the m68 crashes have the experiment, ViewsBrowserWindows: Enabled, which 50/50 in Beta, but isn't going to stable. The continuing crashes in m69 after 69.0.3455.0 bother me though. The m68 crashers -- 71% are from Vietnam, 20% are from Korea. Likely these users are using IME input. 100% of crashers are on 10.13 High Sierra. The m69 crashers -- 117 in this query for m69* https://crash.corp.google.com/browse?q=product_name%3D%27Chrome_Mac%27+AND+expanded_custom_data.ChromeCrashProto.magic_signature_1.name%3D%27-%5BBridgedContentView+insertText%3AreplacementRange%3A%5D%27+AND+product.Version+LIKE+%2769.%25%27 Again, Korea/Vietnam dominate, a few more in the US. Mostly 10.13, but some 10.12 and 10.14 as well. Looking at the stack (it's nuts!) - e.g. http://go/crash/87a1167053524d57 I see we are calling [NSApp updateWindows] when the window is being destroyed: 0x00007fff2873b4cc (AppKit + 0x00a574cc ) +[NSTextInputContext currentInputContext_withFirstResponderSync:] 0x0000000118d75f34 (Google Chrome Framework -bridged_content_view.mm:342 ) -[BridgedContentView setTextInputClient:] 0x0000000118dceef4 (Google Chrome Framework -focus_manager.cc:369 ) views::FocusManager::SetFocusedViewWithReason(views::View*, views::FocusManager::FocusChangeReason) But when there is IME, AppKit is spinning a nested runloop, -[IMKInputSessionXPCInvocation invocationAwaitXPCReply] which is calling back into __71-[IMKInputSession imkxpc_insertText:replacementRange:validFlags:reply:]_block_invoke which puts us back in 0x0000000118d78916 (Google Chrome Framework -bridged_content_view.mm:1393 ) -[BridgedContentView insertText:replacementRange:] 0x00007fff27ea48c4 (AppKit + 0x001c08c4 ) -[NSTextInputContext(NSInputContext_WithCompletion) insertText:replacementRange:completionHandler:] So.. it seems that AppKit is *so* bad that we can't even clear this raw pointer it has to the input context without it accessing the damn thing. ugh.
,
Jul 3
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9fc164420bec73ad4f58441bcf4d4948192ae508 commit 9fc164420bec73ad4f58441bcf4d4948192ae508 Author: Trent Apted <tapted@chromium.org> Date: Tue Jul 03 23:39:54 2018 MacViews: Always null-check BridgedContentView's textInputClient_ When a real IME window is up, AppKit spins a nested runloop that interacts with the IME window over XPC while we're trying to invalidate our NSTextInputClient (e.g. because the window has been deleted). However, this may also cause AppKit to *use* the very NSTextInputClient that we're trying to invalidate. Specifically, this seems to happen with phonetic languages such as Korean and Vietnamese. These use rule-based transforms that do not commonly pop-up a candidate window. In such cases, a key such as Enter may simultaneously commit a composition _and_ trigger the omnibox action, which moves focus away from the omnibox thereby invalidating the textInputClient_. -BridgedContentView insertText: was the last hold-out that didn't have a null check. AttributedSubstringForRangeHelper() and GetFirstRectForRangeHelper() handle a null client already. SystemPreferences -> Keyboard -> Input Sources, then interact with the omnibox. Test: On Mac, add/enable the "2-Set Korean" input method under Bug: 817097 Change-Id: Ia7d1ebb796b9c98437b563ea405cad785e92ea30 Reviewed-on: https://chromium-review.googlesource.com/1124073 Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org> Commit-Queue: Trent Apted <tapted@chromium.org> Cr-Commit-Position: refs/heads/master@{#572396} [modify] https://crrev.com/9fc164420bec73ad4f58441bcf4d4948192ae508/ui/views/cocoa/bridged_content_view.mm
,
Jul 5
I'm gonna call this Fixed again as of 69.0.3481.0. Query to track: https://crash.corp.google.com/browse?q=product_name%3D%27Chrome_Mac%27+AND+expanded_custom_data.ChromeCrashProto.magic_signature_1.name%3D%27-%5BBridgedContentView+insertText%3AreplacementRange%3A%5D%27#-productname:1000,productversion:100,-magicsignature:50,-magicsignature2:50,-stablesignature:50,-magicsignaturesorted:50 (should be no crashes after 69.0.3480.0) Note there is some follow-up in Issue 860362 for a non-crash related issue.
,
Jul 6
tapted@, thank you for the fix. Can you please request a merge to M68 branch: 3440 as we are seeing considerable no.of crashes (~70 unique clients) on current M68 beta#68.0.3440.42?
,
Jul 9
Per #c12, "96.00% of the m68 crashes have the experiment, ViewsBrowserWindows: Enabled, which 50/50 in Beta, but isn't going to stable." So I don't think it's worth a merge. Also it will be tricky - #c9 caused an uptick of crashes on m69. Also I'd want to get closure on Issue 860362 as well. (elly/abdul - any opinions?) Perhaps we should turn down the experiment in m68 for users in Korea/Vietnam.
,
Jul 9
I'd rather not merge this and instead restrict the experiment locales (although I have no idea how to achieve that).
,
Jul 10
I think we just add a locales key to the finch config, e.g.
{
"bug_id": ..,
"study": {
"name": "...",
"locales": [
"en-US",
"en-GB"
],
...
Although.. I suspect we can only whitelist, not blacklist
,
Jul 31
The NextAction date has arrived: 2018-07-31
,
Aug 1
still no crashes after 69.0.3480.0, which includes a couple of dev releases. Current beta (68.0.3440.75) has a small number of crashes, but beta should bump to 3497 soon. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by tapted@chromium.org
, Feb 27 2018Labels: Proj-MacViews
Status: Available (was: Untriaged)
The Cocoa browser's autocomplete_text_field.mm is higher up in the stack -- this looks like it might be a weird data race within AppKit, but we can probably workaround the crash (segfault accessing |textInputClient_|), in - (void)insertText:(id)text replacementRange:(NSRange)replacementRange { if (!hostedView_) return; // Verify inputContext is not nil, i.e. |textInputClient_| is valid and no // menu is active. DCHECK([self inputContext]); textInputClient_->DeleteRange(gfx::Range(replacementRange)); [self insertTextInternal:text]; }