It started spiking 21.0b3. The regression for the spike is: http://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=c4dfe07f855c&tochange=e845a10035f2 Signature nsCSSScanner::Next(nsCSSToken&, bool) More Reports Search UUID f0903ba9-464c-482c-9be5-e513c2130419 Date Processed 2013-04-19 13:40:26 Uptime 1 Last Crash 6.6 hours before submission Install Age 7.7 hours since version was first installed. Install Time 2013-04-19 05:55:38 Product Firefox Version 21.0 Build ID 20130416200523 Release Channel beta OS Windows NT OS Version 6.1.7601 Service Pack 1 Build Architecture x86 Build Architecture Info AuthenticAMD family 20 model 1 stepping 0 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x3a User Comments Processor Notes sp-processor05.phx1.mozilla.com_5878:2012; exploitability tool failed: 127 EMCheckCompatibility True Total Virtual Memory 4294836224 Available Virtual Memory 4107730944 System Memory Use Percentage 29 Available Page File 4693471232 Available Physical Memory 2074857472 Frame Module Signature Source 0 xul.dll nsCSSScanner::Next layout/style/nsCSSScanner.cpp:1180 1 xul.dll `anonymous namespace'::CSSParserImpl::ParseDeclaration layout/style/nsCSSParser.cpp:4461 2 xul.dll `anonymous namespace'::CSSParserImpl::ParseRuleSet layout/style/nsCSSParser.cpp:2911 3 xul.dll `anonymous namespace'::CSSParserImpl::ParseSheet layout/style/nsCSSParser.cpp:991 4 xul.dll mozilla::css::Loader::ParseSheet layout/style/Loader.cpp:1624 5 xul.dll mozilla::css::SheetLoadData::OnStreamComplete layout/style/Loader.cpp:947 6 xul.dll nsUnicharStreamLoader::OnStopRequest netwerk/base/src/nsUnicharStreamLoader.cpp:95 7 xul.dll nsSyncLoadService::PushSyncStreamToListener content/base/src/nsSyncLoadService.cpp:385 8 xul.dll mozilla::css::Loader::LoadSheet layout/style/Loader.cpp:1432 9 xul.dll mozilla::css::Loader::LoadChildSheet layout/style/Loader.cpp:2088 10 xul.dll `anonymous namespace'::CSSParserImpl::ProcessImport layout/style/nsCSSParser.cpp:2050 11 xul.dll `anonymous namespace'::CSSParserImpl::ParseImportRule layout/style/nsCSSParser.cpp:2021 12 xul.dll `anonymous namespace'::CSSParserImpl::ParseAtRule layout/style/nsCSSParser.cpp:1648 13 xul.dll `anonymous namespace'::CSSParserImpl::ParseSheet layout/style/nsCSSParser.cpp:987 14 xul.dll mozilla::css::Loader::ParseSheet layout/style/Loader.cpp:1624 15 xul.dll mozilla::css::SheetLoadData::OnStreamComplete layout/style/Loader.cpp:947 16 xul.dll nsUnicharStreamLoader::OnStopRequest netwerk/base/src/nsUnicharStreamLoader.cpp:95 17 xul.dll nsSyncLoadService::PushSyncStreamToListener content/base/src/nsSyncLoadService.cpp:385 18 xul.dll mozilla::css::Loader::LoadSheet layout/style/Loader.cpp:1432 19 xul.dll mozilla::css::Loader::InternalLoadNonDocumentSheet layout/style/Loader.cpp:2198 20 xul.dll mozilla::css::Loader::LoadSheetSync layout/style/Loader.cpp:2106 21 xul.dll nsLayoutStylesheetCache::LoadSheet layout/style/nsLayoutStylesheetCache.cpp:311 22 xul.dll nsLayoutStylesheetCache::nsLayoutStylesheetCache layout/style/nsLayoutStylesheetCache.cpp:213 23 xul.dll nsLayoutStylesheetCache::EnsureGlobal layout/style/nsLayoutStylesheetCache.cpp:244 24 xul.dll nsLayoutStylesheetCache::UserChromeSheet layout/style/nsLayoutStylesheetCache.cpp:116 25 xul.dll nsDocumentViewer::CreateStyleSet layout/base/nsDocumentViewer.cpp:2145 26 mozjs.dll PRMJ_Now js/src/prmjtime.cpp:390 27 xul.dll nsContentUtils::GetUTFOrigin content/base/src/nsContentUtils.cpp:5730 More reports at: https://crash-stats.mozilla.com/report/list?signature=nsCSSScanner%3A%3ANext%28nsCSSToken%26%2C+bool%29

(In reply to Scoobidiver from comment #0) > It started spiking 21.0b3. The regression for the spike is: > http://hg.mozilla.org/releases/mozilla-beta/ > pushloghtml?fromchange=c4dfe07f855c&tochange=e845a10035f2 I don't see anything suspicious in that range. Does the increase correlate with the uptake of 21.0b3, or does it have some other temporal distribution (which would seam to indicate an external cause of the regression)?

(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #1) > Does the increase correlate with the uptake of 21.0b3, or does it have some > other temporal distribution (which would seam to indicate an external cause > of the regression)? There's no temporal correlation. Note that it's only the beginning of 21.0b3.

It's currently #15 top browser crasher in 21.0b3 with some duplicates. I suspect bug 839515 which has a patch different for Beta.

(In reply to Scoobidiver from comment #3) > I suspect bug 839515 which has a patch different for Beta. I don't see anything interesting in that patch, or in the crash stack in comment 0. This bug doesn't currently appear to be something we can take useful action on. (Are there any correlations of interest?)

(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #4) > (Are there any correlations of interest?) They are correlated to TestPilot 1.2.2. It's not surprising in Beta but I haven't found a crash report without it and the default theme. Usually some Beta testers disable it.

I found a crash report without TestPilot: bp-a52bc168-e0e7-45ad-9bfb-d6a5e2130420.

Not sure why I was CC'ed in this bug, but I have no experience with this part of the code, unfortunately.

(In reply to Panos Astithas [:past] from comment #7) > Not sure why I was CC'ed in this bug Because of comment 3.

In that case I think that patch is unrelated to the crash. The different patch for beta was necessary since theme stylesheets were moved to a different directory.

(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #4) > (Are there any correlations of interest?) 97.5% of crashes in 21.0b3 are on Windows 7 and 47% happens within one minute. Other auto-correlations require the fix of bug 836671.

What graphics cards are those people on? All Radeon by chance?

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #11) > What graphics cards are those people on? All Radeon by chance? I haven't though about bug 772330 because it was too low (only one GPU affected) and in CSS instead of Layout but it's indeed the case.

If somebody can reproduce this one, can you please set MOZ_CRASHREPORTER_FULLDUMP=1 in your environment and capture a full memory dump. On crash, the minidump will end up in profile/minidumps and will *not* show in about:crashes. Please send it to me via people.mozilla.com or dropbox or google drive or something. Setting NEEDINFO ashughes since his netbook saw this crash pretty consistently last time.

I've been using Firefox 21.0b3 all day on the netbook which reproduced the crash back in Firefox 19.0.1. I have yet to experience a crash. That said, my netbook is pre-installed with Windows 8 whereas ~97% of the crashes *here* are happening on Windows 7. As a result, I don't think my netbook is a good candidate for testing *this* crash.

Can we add padding around the crashing function in the hopes that it prevents this particular instability ? CC'ing roc here as he has helped us in the past with a similar build specific top-crasher by adding padding . Roc, would that be doable-appropriate here ?

No, there is really no point in padding particular functions. We've seen that the offsets of the memory corruption vary from build to build and we're basically just playing roulette with whether we hit a commonly-called function or not. nsCSSScanner::Next is a hot function, as was nsXPConnect::GetXPConnect. It's likely that this bug affects every release but most of the time it only hits cold functions and so it's lost under the noise.

I've been testing on the netbook I have, which is also on Windows 8, and I haven't had any luck reproducing the crash. I'll install Win 7 on it, and see if that makes a difference.

qawanted for comment 17

(In reply to Alex Keybl [:akeybl] from comment #18) > qawanted for comment 17 If Juan is unsuccessful I can try to order the following, which seems to come with the exact GPU referred to in this bug: http://www.newegg.ca/Product/Product.aspx?Item=N82E16856119058

I was finally able to install Windows 7 on the machine after experiencing problems with the network controller. I've been trying to reproduce the problem trying different kinds of URLs from the crash reports. They are very generic, lots of youtube.com videos. So far no luck. Some of the actions I tried were playing youtube videos with the latest flash, and changing the screen sizes in youtube. The machine is downloading several updates, and I will give it another try after it's done.

I left the machine running last night with several sites from the URLs associated with this crash as well as long playlist of youtube videos. This morning there was a system dialog saying the Plugin Container had stopped working and there was no sign of the app running, and no crash report dialog. There is a minidump associated with this, from 04-24, but I don't know if it is related to this crash signature. You can access the machine through VNC in the MV network at 10.250.6.86

There are no crashes in 21.0b4 and above.

Dropping qawanted from this bug due to comment 22. That said we will be dogfooding 21b7 and the 21RC with our netbooks. We will reopen this if we hit something.