New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 131310 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Jul 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Chrome_Mac: Crash Report - Stack Signature: FindKeyForPString-F6F61

Project Member Reported by kbr@chromium.org, Jun 6 2012

Issue description

Many GPU process crashes are being observed on Mac OS that appear to be font related. These appear to be the majority of the GPU process crashes currently in Canary. There's no reason the GPU process should be using or initializing fonts, so whatever calling code is causing this should just be disabled.

I filed this under the old stack signature because the new one varies fairly widely among reports with the same basic stack trace.

Similar reports to this one:

http://go/crash/reportdetail?reportid=1be570fb8f060da2
http://go/crash/reportdetail?reportid=2f5af40677f11b9d
http://go/crash/reportdetail?reportid=9583945fe6eba7fb
http://go/crash/reportdetail?reportid=d622b6fad0ddce85
http://go/crash/reportdetail?reportid=d4c7b4e62a9e9897
http://go/crash/reportdetail?reportid=982262fef7567c38

Stack trace from this report:

0x9b666ae2	 [ATS]	 + 0x00002ae2]	FindKeyForPString
0x9b666850	 [ATS]	 + 0x00002850]	_eFOGetFontFamilyFromName
0x9b6a43c1	 [ATS]	 + 0x000403c1]	FOGetFontFamilyFromName
0x92d541be	 [QD]	 + 0x000571be]	GetFNum
0x9502c6b0	 [HIToolbox]	 + 0x0005a6b0]	HLTBGetFontNumber
0x9502c2ea	 [HIToolbox]	 + 0x0005a2ea]	SetCustomizedFields
0x9502be1c	 [HIToolbox]	 + 0x00059e1c]	InitIntlValue
0x99e7b7b3	 [CarbonCore]	 + 0x000387b3]	IntlIsInitIntlValueDone
0x99e77fe5	 [CarbonCore]	 + 0x00034fe5]	SMInitIntlSpec
0x99e776ce	 [CarbonCore]	 + 0x000346ce]	LMGetIntlSpec
0x99e7b7ed	 [CarbonCore]	 + 0x000387ed]	GetScriptManagerVariable
0x94ff0814	 [HIToolbox]	 + 0x0001e814]	TSMCurrentKeyboardInputSourceRefCreate
0x9500029d	 [HIToolbox]	 + 0x0002e29d]	ValidateInputSourceToUseWithEnabledSet
0x94fff144	 [HIToolbox]	 + 0x0002d144]	MyActivateTSMDocument
0x94ffed2e	 [HIToolbox]	 + 0x0002cd2e]	ActivateTSMDocument
0x9502ce5b	 [HIToolbox]	 + 0x0005ae5b]	CallMyActivateTSMDocument
0x94fefee0	 [HIToolbox]	 + 0x0001dee0]	TimerVector
0x931ab2a5	 [CoreFoundation]	 + 0x0005d2a5]	__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__
0x931aac36	 [CoreFoundation]	 + 0x0005cc36]	__CFRunLoopDoTimer
0x93189ccf	 [CoreFoundation]	 + 0x0003bccf]	__CFRunLoopRun
0x931891db	 [CoreFoundation]	 + 0x0003b1db]	CFRunLoopRunSpecific
0x93189087	 [CoreFoundation]	 + 0x0003b087]	CFRunLoopRunInMode
0x94fd4722	 [HIToolbox]	 + 0x00002722]	RunCurrentEventLoopInMode
0x94fdba8a	 [HIToolbox]	 + 0x00009a8a]	ReceiveNextEventCommon
0x94fdb8f9	 [HIToolbox]	 + 0x000098f9]	BlockUntilNextEventMatchingListInMode
0x9549e0d7	 [AppKit]	 + 0x0000a0d7]	_DPSNextEvent
0x9549d941	 [AppKit]	 + 0x00009941]	-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
0x95499cb0	 [AppKit]	 + 0x00005cb0]	-[NSApplication run]




Product: Chrome_Mac
Stack Signature: FindKeyForPString-F6F61
New Signature Label: FindKeyForPString
New Signature Hash: 06fde48a_5fcd01c7_2203683f_8e744c80_6fff1080

Report link: http://go/crash/reportdetail?reportid=5ac8bddf5daa66df

Meta information:
Product Name: Chrome_Mac
Product Version: 21.0.1163.0
Report ID: 5ac8bddf5daa66df
Report Time: 2012/06/05 19:53:16, Tue
Uptime: 0 sec
Cumulative Uptime: 0 sec
OS Name: Mac OS X
OS Version: 10.7.4 11E53
CPU Architecture: x86
CPU Info: GenuineIntel family 6 model 42 stepping 7

 
Cc: jeremy@chromium.org
jeremy did a lot of work to make sure fonts work well with the sandbox. Jeremy, does this look familiar?

It looks like this loading is done by the system, so even if the GPU process doesn't need it maybe it's hard to prevent it from happening.
No, that stack doesn't ring a bell.

Are these new crashes? do we have any way of reproducing? 

In all crashes I looked at this code is getting called exactly 1s after process startup.

Comment 3 by kbr@chromium.org, Jun 6 2012

They're happening at least as far back as M19. Was that the release where the Mac GPU sandbox was introduced? Sorry, but I haven't paid attention to the GPU process crash logs on Mac in a while. Unfortunately we don't have reproduction steps.

The gpu sandbox was r68321, two years ago. I think it's been active since we shipped the gpu process on stable.

Comment 5 by kbr@chromium.org, Jun 6 2012

Cc: wiltzius@chromium.org
Looking through the crash database, it *seems* that the earliest this crash started showing up in the GPU process was 19.0.1084.52. Tom Wiltzius is going to help me confirm this.

Wasn't the GPU sandbox on Mac strengthened recently (more recently than 2 years ago)?

The stack trace looks similar to this crash in Finder:

https://discussions.apple.com/thread/1693961?start=0&tstart=0

Near the base of the call stacks is ActivateTSMDocument. TSM probably means Text Services Manager.
`git log content/browser/gpu.sb` doesn't have any recent changes at least. I don't know about other parts (I think there aren't many other parts to the gpu sandbox besides this file though).
Just the sandbox warmup code, and I don't think that's changed in a while...
The earliest instance of this crash that I can find with dremel is 16.0.912.75, which was r116452.

http://crash.corp.google.com/reportdetail?reportid=f406ea6ae0c3eea1
Does this correlate with OS version?  Maybe it was a push on their end or some OS setting (the crashes do seem 10.7 specific).

Comment 11 by kbr@chromium.org, Jun 6 2012

Queries indicate that it's happening on both Snow Leopard and Lion with a frequency of about 1:2.3 (2.3 crashes on Lion for every one on Snow Leopard). There are a few single crashes on Leopard but they appear to be outliers.

Comment 12 by kbr@chromium.org, Jun 6 2012

Also, the numbers are trending upward; there are 10 times as many of these crashes reported on the M19 stable versions as on M18. Might be partly explained by increasing Chrome usage, but I don't think there are 10x as many Chrome Mac users on M19 as on M18.

Might be worth setting a breakpoint in CallMyActivateTSMDocument and seeing if the GPU process hits it in general.

Comment 14 by kbr@chromium.org, Jun 6 2012

Great idea. Interesting. It isn't usually hit. I double-checked to make sure a breakpoint in [NSApplication run] was hit. TimerVector isn't hit either. I tried WebGL, CSS 3D, Flash, and accelerated 2D Canvas content.

Could this be related to IME or assistive services?
Can we log the current URL in GPU crashes - I don't see them in any of the crashes above.

I'm also wondering if there's anything we can do to catch the spot on user's machines where a timer to execute this code is set - then when we crash we can upload that stack along with the rest of the crash dump.

Comment 17 by kbr@chromium.org, Jun 6 2012

We are supposed to be logging the URL the GPU process is servicing in crash reports, but I think that support has been broken on Mac OS at least. It's being investigated separately.

Comment 18 by kbr@chromium.org, Jun 6 2012

Filed  Issue 131466  regarding the missing URLs in crash reports. However, if this is happening because the GPU process is crashing very near startup, we probably don't have an associated URL. The GPU process is spawned early, and not on behalf of any particular web page.

This could definitely be related to IME or assistive services.

On Mac OS, the GPU process doesn't create any on-screen windows and doesn't need to support any form of user interaction. I think we might be able to switch it to a TYPE_IO MessageLoop, and wonder whether that would work around this issue.

Comment 19 by kbr@chromium.org, Jun 6 2012

Cc: jbau...@chromium.org
Labels: -Pri-2 Pri-1 OS-Mac Stability-Crash Mstone-21
I see this as far back as 11.0.696.65: http://crash.corp.google.com/reportdetail?reportid=b89099c0b19e86bc

The numbers are in the teens in M17, 50s for M18, and hundreds in M19 and 20.

Currently this is the #1 crash on canary.
Owner: kbr@chromium.org
Status: Assigned
I do think this is IME related. I think your comment about switching MessageLoop types to TYPE_IO (or even TYPE_DEFAULT) could work. Why don't we just try that on Canary?

Comment 22 by kbr@chromium.org, Jun 14 2012

Can do. I am out of the office right now and can't build Chrome for Mac -- jbates / jbauman, can one of you try that experiment and if it looks like it's working send the change out for review?

Still seeing this on canary 1180. Have we tried this change?

Comment 24 by kbr@chromium.org, Jun 20 2012

Sorry, looks like we didn't try it -- I'll do so right now.

Comment 25 by kbr@chromium.org, Jun 20 2012

Looks like it'll work. https://chromiumcodereview.appspot.com/10581041/ in progress.

Project Member

Comment 26 by bugdroid1@chromium.org, Jun 20 2012

Summary: Chrome_Mac: Crash Report - Stack Signature: FindKeyForPString-F6F61
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=143263

------------------------------------------------------------------------
r143263 | kbr@chromium.org | Wed Jun 20 14:13:06 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/content/gpu/gpu_main.cc?r1=143263&r2=143262&pathrev=143263

Change GPU process to use IO rather than UI MessageLoop on Mac OS. On this platform, the GPU process does not need to access any on-screen resources.

This is an attempted workaround for
http://code.google.com/p/chromium/issues/detail?id=131310 .

BUG= 131310 
TEST=ran WebGL content, Poster Circle, and Flash content on Mac OS X


Review URL: https://chromiumcodereview.appspot.com/10581041
------------------------------------------------------------------------
The numbers for canary 1182 are a little low, but there's not a single report of this, which is promising.

Comment 28 by kbr@chromium.org, Jun 22 2012

That's great news :)

Robert, would you be willing to take this bug and track the canary numbers for a little while to see if it really looks fixed? You could assign it back to me if it isn't.

Cc: kbr@chromium.org
Owner: rsesek@chromium.org
Absolutely.

Comment 30 by karen@chromium.org, Jul 11 2012

Labels: -Mstone-21 MovedFrom-21 Mstone-22
Moving all non essential bugs to the next Milestone

Comment 31 by kbr@chromium.org, Jul 18 2012

Cc: dharani@chromium.org
Owner: kbr@chromium.org
Status: Fixed
I happened to look through the GPU process crash logs for M21 and M22 and this is definitely fixed in M22. Marking as such so backports can be considered.

Labels: -Mstone-22 Mstone-20
Awesome! Please merge it in M20 - 1132 branch.

Comment 33 by kareng@google.com, Jul 18 2012

Labels: Merge-Approved
and to M21. thanks  - 1180 :)

Comment 35 by kbr@chromium.org, Jul 18 2012

Labels: -Merge-Approved
Project Member

Comment 36 by bugdroid1@chromium.org, Jul 18 2012

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=147310

------------------------------------------------------------------------
r147310 | kbr@chromium.org | 2012-07-18T21:10:23.629346Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1180/src/content/gpu/gpu_main.cc?r1=147310&r2=147309&pathrev=147310

Merge 143263 - Change GPU process to use IO rather than UI MessageLoop on Mac OS. On this platform, the GPU process does not need to access any on-screen resources.

This is an attempted workaround for
http://code.google.com/p/chromium/issues/detail?id=131310 .

BUG= 131310 
TEST=ran WebGL content, Poster Circle, and Flash content on Mac OS X


Review URL: https://chromiumcodereview.appspot.com/10581041

TBR=kbr@chromium.org
Review URL: https://chromiumcodereview.appspot.com/10808020
------------------------------------------------------------------------
Project Member

Comment 37 by bugdroid1@chromium.org, Jul 18 2012

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=147311

------------------------------------------------------------------------
r147311 | kbr@chromium.org | 2012-07-18T21:12:15.475471Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1132/src/content/gpu/gpu_main.cc?r1=147311&r2=147310&pathrev=147311

Merge 143263 - Change GPU process to use IO rather than UI MessageLoop on Mac OS. On this platform, the GPU process does not need to access any on-screen resources.

This is an attempted workaround for
http://code.google.com/p/chromium/issues/detail?id=131310 .

BUG= 131310 
TEST=ran WebGL content, Poster Circle, and Flash content on Mac OS X


Review URL: https://chromiumcodereview.appspot.com/10581041

TBR=kbr@chromium.org
Review URL: https://chromiumcodereview.appspot.com/10806019
------------------------------------------------------------------------

Comment 38 Deleted

Project Member

Comment 39 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 40 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals -Feature-GPU -Mstone-20 Cr-Internals-GPU M-20 Cr-Internals
Project Member

Comment 41 by bugdroid1@chromium.org, Mar 14 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Sign in to add a comment