Closed Bug 760190 Opened 12 years ago Closed 6 years ago

OOM crash in `anonymous namespace'::CSSParserImpl::ParseSelector or ParseSelectorGroup

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Version:
13 Branch
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INCOMPLETE
Tracking Flags:
Tracking Status
firefox13 - ---
firefox14 - ---

People

(Reporter: scoobidiver, Unassigned)

References

Details

(Keywords: crash, regression, Whiteboard: [startupcrash][tbird crash])

Crash Data

It's #14 top browser crasher in 13.0b6 while it's #337 in 13.0b5.
It also spiked from 14.0a2/20120529042008 (#21 over the last day) and 15.0a1/20120527030515 (#60 over the last day).
Mac is unaffected.

The regression ranges are:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e4574b46f0ba&tochange=133aa3a2ef0a
http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=7802a253d406&tochange=74f5e0d677f2
http://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=5de6e4bd8ede&tochange=5dd4dde1d4eb
It's a regression from bug 719117.

Signature 	mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | `anonymous namespace''::CSSParserImpl::ParseSelector(nsCSSSelectorList*, wchar_t) More Reports Search
UUID	c992a32b-8f69-46d5-9933-f42982120531
Date Processed	2012-05-31 17:32:53
Uptime	2687
Last Crash	44.8 minutes before submission
Install Age	1.4 days since version was first installed.
Install Time	2012-05-30 09:07:04
Product	Firefox
Version	13.0
Build ID	20120528154913
Release Channel	beta
OS	Windows NT
OS Version	6.1.7601 Service Pack 1
Build Architecture	x86
Build Architecture Info	GenuineIntel family 6 model 37 stepping 5
Crash Reason	EXCEPTION_BREAKPOINT
Crash Address	0x72c419be
App Notes 	
AdapterVendorID: 0x8086, AdapterDeviceID: 0x0046, AdapterSubsysID: 04871025, AdapterDriverVersion: 8.15.10.2182
D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers- 
EMCheckCompatibility	True	
Total Virtual Memory	4294836224
Available Virtual Memory	3772362752
System Memory Use Percentage	44
Available Page File	6051905536
Available Physical Memory	2178744320
OOMAllocationSize	8

Frame 	Module 	Signature 	Source
0 	mozalloc.dll 	mozalloc_abort 	memory/mozalloc/mozalloc_abort.cpp:79
1 	mozalloc.dll 	mozalloc_handle_oom 	memory/mozalloc/mozalloc_oom.cpp:60
2 	mozalloc.dll 	moz_xmalloc 	memory/mozalloc/mozalloc.cpp:105
3 	xul.dll 	`anonymous namespace'::CSSParserImpl::ParseSelector 	layout/style/nsCSSParser.cpp:3604
4 	xul.dll 	`anonymous namespace'::CSSParserImpl::ParseSelectorGroup 	layout/style/nsCSSParser.cpp:2654
5 	xul.dll 	`anonymous namespace'::CSSParserImpl::ParseSelectorList 	layout/style/nsCSSParser.cpp:2589
6 	xul.dll 	`anonymous namespace'::CSSParserImpl::ParseRuleSet 	layout/style/nsCSSParser.cpp:2552
7 	xul.dll 	`anonymous namespace'::CSSParserImpl::ParseSheet 	layout/style/nsCSSParser.cpp:935
8 	xul.dll 	mozilla::css::Loader::ParseSheet 	layout/style/Loader.cpp:1645
9 	xul.dll 	mozilla::css::Loader::LoadInlineStyle 	layout/style/Loader.cpp:1868
10 	xul.dll 	nsStyleLinkElement::DoUpdateStyleSheet 	content/base/src/nsStyleLinkElement.cpp:304
11 	xul.dll 	nsStyleLinkElement::UpdateStyleSheet 	content/base/src/nsStyleLinkElement.cpp:214
12 	xul.dll 	nsHtml5TreeOpExecutor::UpdateStyleSheet 	parser/html/nsHtml5TreeOpExecutor.cpp:334
13 	xul.dll 	nsHtml5TreeOperation::Perform 	parser/html/nsHtml5TreeOperation.cpp:638
14 	xul.dll 	nsHtml5TreeOpExecutor::RunFlushLoop 	parser/html/nsHtml5TreeOpExecutor.cpp:527
15 	xul.dll 	nsHtml5ExecutorFlusher::Run 	parser/html/nsHtml5StreamParser.cpp:159
16 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:657
17 	xul.dll 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:110
18 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/message_loop.cc:201
19 	xul.dll 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:175
20 	xul.dll 	nsBaseAppShell::Run 	widget/xpwidgets/nsBaseAppShell.cpp:189
21 	xul.dll 	nsAppShell::Run 	widget/windows/nsAppShell.cpp:252
22 	xul.dll 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:295
23 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3703
24 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:107
25 	firefox.exe 	__tmainCRTStartup 	crtexe.c:552
26 	ntdll.dll 	__RtlUserThreadStart 	
27 	shell32.dll 	shell32.dll@0x256ebb 	
28 	kernel32.dll 	LoadStringByReference 	
29 	kernel32.dll 	LoadStringByReference 	

More reports at:
https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char+const*+const%29+|+mozalloc_handle_oom%28unsigned+int%29+|+moz_xmalloc+|+%60anonymous+namespace%27%27%3A%3ACSSParserImpl%3A%3AParseSelector%28nsCSSSelectorList*%2C+wchar_t%29
https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char+const*+const%29+|+mozalloc_handle_oom%28unsigned+int%29+|+moz_xmalloc+|+%60anonymous+namespace%27%27%3A%3ACSSParserImpl%3A%3AParseSelectorGroup%28nsCSSSelectorList*%26%29
Is there any assistance QA can provide here?
Here are some URLs that were crashing for the first signature. Also note one comment which mentions crashing on scratch.mit.edu

8 https://www.facebook.com/login.php?login_attempt=1
4 http://www.facebook.com/
3 https://www.bnonline.fi.cr/Login/RegistroOTP.aspx
2 https://min.e-boks.dk/inbox.aspx
2 https://www.bnonline.fi.cr/BNCR.InternetBanking.Web/IBP_FTxn.aspx
1 https://web20.prod.bec.dk/kontooplysninger/servlet/RenteOplysninger2
1 http://www.google.dk/
1 http://apps.facebook.com/tripwow/ta-044b-46be-8730?fwo=1&st=fo_w_1338262624_1780
1 http://www.spelpunt.nl/applet.php?port=6041&roomjump=1&game=bingo
1 http://www.bbc.co.uk/iplayer/tv/categories/factual
1 https://www.facebook.com/photo.php?fbid=370621039667504&set=at.370620739667534.8
1 http://grimmag.drakensang.com/logout
1 http://www.facebook.com/teamhotstar
1 http://no.gosupermodel.com/friends/
1 http://www.facebook.com/SamaElWaSSOuf?ref=ts
1 https://www.google.co.id/search?q=yamaha+mio+yang+baru&oe=utf-8&rls=org.mozilla:
1 https://web20.prod.bec.dk/kontrakter/servlet/AftalerGodkend
1 http://www.filesin.com/6C14C231694/41D8CD98F06C14C231694/IPConfig-6.4.3-.rar.htm
1 http://ts6.travian.net/karte.php
1 http://strelec.ucoz.ru/?lrgN9e
1 https://www.facebook.com/media/set/?set=a.418428708190400.106801.100000698227782
1 http://www.zenfolio.com/briddell/edit
1 http://www.oasis.com/pt/memberhome/08ba48da/#searchresults&p23&Distance&true
1 http://www.youtube.com/watch?v=HcLTbqc2294&feature=related
1 http://www.yahoo.com/_ylt=Ar7CrNqMV6QfywaYVfc5aGCbvZx4;_ylc=X3oDMTlobXFtb2JuBF9T
1 http://www.bbc.co.uk/sport/0/cricket/
1 http://www.t-mobile.com/shop/phones/default.aspx?capcode=WMOS
1 http://fr-fr.livemocha.com/content/view/764
1 http://badoo.com/connections/message/267498736/
1 http://www.youtube.com/watch?v=DEXO16J4rUQ&feature=related
1 http://www.welt.de/spiele/online-spiele/article1336655/Sudoku.html
1 http://www.papilot.pl/wydarzenia/18339/Makabryczny-proceder-w-Indiach-Kobiety-us
1 https://flip.geojitbnpparibas.com/faces/lite/order/OrdPageDispatcher.jsp?newOrMo
1 http://hu.playforia.com/jatssz/pool/sima/
Looking at a few stacks it seems unlikely this has anything to do with
bug 719117, which was a bug about stopping/starting plugins.
There's also several crashes reported for Fx12 in the links given above:
bp-35a07ed2-20a5-452a-a7ec-cba852120531
bp-f681e5f9-c3d8-414c-888c-261112120530
bp-90cde5b9-7a3a-4769-8ae9-8d88c2120531
...
From bp-ff3bf364-b2e0-427c-be9d-c69f62120525:
Total Virtual Memory	2147352576
Available Virtual Memory	1946435584
System Memory Use Percentage	26
Available Page File	3656826880
Available Physical Memory	1472749568
OOMAllocationSize	12

This doesn't make sense to me - why are we aborting on OOM for a 12 byte
allocation with 1946435584 bytes of available memory?
(In reply to Mats Palmgren [:mats] from comment #3)
> Looking at a few stacks it seems unlikely this has anything to do with
> bug 719117, which was a bug about stopping/starting plugins.
bug 719177 is the only one that belongs to the three regression ranges.

> There's also several crashes reported for Fx12 in the links given above:
I haven't said it's a new crash. It only spiked on the three channels based on the build ID, not the date, so it's not an external cause.
To clarify, the two signatures did appear in Firefox 12 according to the signature summary (4 week data view):

mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | `anonymous namespace''::CSSParserImpl::ParseSelectorGroup(nsCSSSelectorList*&) 

Product 	Version 	Percentage 	Number Of Crashes
Firefox 	12.0 	        79.783 %	734
Firefox 	12.0b6 	         5.000 %        46
Firefox 	12.0b5 	         2.065 %	19
Firefox 	13.0b2 	         1.957 %	18
Firefox 	13.0b4 	         1.848 %	17
Firefox 	13.0b3 	         1.739 %	16
Firefox 	12.0b3 	         1.087 %	10
Firefox 	13.0b5 	         0.978 %	9
Firefox 	13.0b1 	         0.543 %	5
Firefox 	14.0a2 	         0.543 %	5
Firefox 	12.0b2 	         0.435 %	4
Firefox 	13.0b6 	         0.109 %	1
Firefox 	12.0b1 	         0.109 %	1
Firefox 	12.0b4 	         0.109 %	1 

The second signature was also present in 12 in smaller numbers

mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | `anonymous namespace''::CSSParserImpl::ParseSelector(nsCSSSelectorList*, wchar_t) (4 week data view)

Product 	Version 	Percentage 	Number Of Crashes
Firefox 	13.0b2 	        20.528 %	70
Firefox 	13.0b4 	        16.716 %	57
Firefox 	13.0b3 	        13.490 %	46
Firefox 	12.0 	        12.023 %	41
Firefox 	13.0b6 	        11.144 %	38
Firefox 	13.0b5 	        10.850 %	37
Firefox 	14.0a2 	         7.038 %	24
Firefox 	13.0b1 	         4.985 %	17
Firefox 	15.0a1 	         2.346 %	8
Firefox 	12.0b3 	         0.293 %	1
Firefox 	12.0b1 	         0.293 %	1
Firefox 	12.0b6 	         0.293 %	1
Here are some addon correlations that I picked up in the manual reports for the crashes on 13:

mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | `anonymous namespace''::CSSParserImpl::ParseSelector(nsCSSSelectorList*, wchar_t)|EXCEPTION_BREAKPOINT (81 crashes)
    100% (81/81) vs.  90% (41440/46165) {972ce4c6-7e08-4474-a285-3208198ce6fd} (Default, https://addons.mozilla.org/addon/8150)
     17% (14/81) vs.   7% (3398/46165) {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} (Adblock Plus, https://addons.mozilla.org/addon/1865)

Module correlations:

mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | `anonymous namespace''::CSSParserImpl::ParseSelector(nsCSSSelectorList*, wchar_t)|EXCEPTION_BREAKPOINT (81 crashes)
    128% (104/81) vs.  10% (4718/46165) msvcr71.dll
     88% (71/81) vs.   2% (709/46165) nio.dll
     88% (71/81) vs.   2% (709/46165) net.dll
     88% (71/81) vs.   2% (713/46165) jp2native.dll
     88% (71/81) vs.   2% (713/46165) deploy.dll
     88% (71/81) vs.   2% (790/46165) verify.dll
     88% (71/81) vs.   2% (791/46165) java.dll
     88% (71/81) vs.   2% (791/46165) jvm.dll
     88% (71/81) vs.   2% (791/46165) zip.dll
     88% (71/81) vs.   2% (793/46165) npjp2.dll
     65% (53/81) vs.   1% (395/46165) regutils.dll
     94% (76/81) vs.  43% (19921/46165) apphelp.dll
    100% (81/81) vs.  61% (28305/46165) shdocvw.dll
    100% (81/81) vs.  63% (29251/46165) nssckbi.dll
    100% (81/81) vs.  64% (29662/46165) freebl3.dll
    100% (81/81) vs.  64% (29690/46165) nssdbm3.dll
     96% (78/81) vs.  63% (29042/46165) urlmon.dll
    100% (81/81) vs.  67% (31083/46165) feclient.dll
    100% (81/81) vs.  68% (31607/46165) winrnr.dll
     60% (49/81) vs.  29% (13417/46165) pnrpnsp.dll
     60% (49/81) vs.  29% (13481/46165) DWrite.dll
     60% (49/81) vs.  29% (13490/46165) NapiNSP.dll
     59% (48/81) vs.  30% (13622/46165) nlaapi.dll
     63% (51/81) vs.  33% (15439/46165) wship6.dll
    100% (81/81) vs.  71% (32547/46165) gkmedias.dll
     74% (60/81) vs.  45% (20813/46165) ntmarta.dll
     52% (42/81) vs.  24% (10902/46165) explorerframe.dll
     52% (42/81) vs.  24% (10915/46165) dui70.dll
     88% (71/81) vs.  59% (27444/46165) iertutil.dll
     52% (42/81) vs.  24% (11203/46165) duser.dll
     47% (38/81) vs.  19% (8972/46165) slc.dll
    100% (81/81) vs.  73% (33508/46165) browsercomps.dll
    100% (81/81) vs.  73% (33611/46165) rasadhlp.dll
     60% (49/81) vs.  34% (15541/46165) Wldap32.dll
     47% (38/81) vs.  20% (9295/46165) cscapi.dll
     51% (41/81) vs.  24% (11024/46165) ntshrui.dll
     47% (38/81) vs.  20% (9413/46165) srvcli.dll
     48% (39/81) vs.  22% (10100/46165) linkinfo.dll
    100% (81/81) vs.  74% (34084/46165) softokn3.dll
    100% (81/81) vs.  74% (34091/46165) firefox.exe
    100% (81/81) vs.  74% (34122/46165) xpcom.dll
     52% (42/81) vs.  26% (12137/46165) RpcRtRemote.dll
    100% (81/81) vs.  75% (34414/46165) dbghelp.dll
     52% (42/81) vs.  28% (12875/46165) FWPUCLNT.DLL
    100% (81/81) vs.  76% (35189/46165) wininet.dll
     89% (72/81) vs.  66% (30323/46165) rsaenh.dll
     60% (49/81) vs.  37% (17255/46165) WSHTCPIP.DLL
    100% (81/81) vs.  77% (35620/46165) dnsapi.dll
     52% (42/81) vs.  29% (13591/46165) cryptsp.dll
    122% (99/81) vs. 101% (46448/46165) msvcr100.dll
     75% (61/81) vs.  55% (25397/46165) normaliz.dll
     78% (63/81) vs.  58% (26686/46165) msctf.dll
     94% (76/81) vs.  75% (34519/46165) psapi.dll
     60% (49/81) vs.  42% (19300/46165) AudioSes.dll
     30% (24/81) vs.  11% (5121/46165) d3d10_1core.dll
     30% (24/81) vs.  11% (5121/46165) d3d10_1.dll
     30% (24/81) vs.  11% (5137/46165) dxgi.dll
     60% (49/81) vs.  42% (19471/46165) MMDevAPI.dll
     60% (49/81) vs.  42% (19610/46165) propsys.dll
     31% (25/81) vs.  13% (6184/46165) WLIDNSP.DLL
     27% (22/81) vs.  10% (4597/46165) d3d10.dll
     27% (22/81) vs.  10% (4597/46165) d3d10core.dll
     27% (22/81) vs.  10% (4696/46165) d2d1.dll
     60% (49/81) vs.  44% (20165/46165) powrprof.dll
     52% (42/81) vs.  36% (16560/46165) profapi.dll
     60% (49/81) vs.  45% (20628/46165) winnsi.dll
     60% (49/81) vs.  45% (20628/46165) nsi.dll
     60% (49/81) vs.  45% (20632/46165) IPHLPAPI.DLL
     60% (49/81) vs.  45% (20636/46165) dwmapi.dll
    100% (81/81) vs.  85% (39154/46165) wintrust.dll
     73% (59/81) vs.  58% (26778/46165) t2embed.dll
    101% (82/81) vs.  87% (40138/46165) mswsock.dll
     25% (20/81) vs.  10% (4819/46165) wshbth.dll
     72% (58/81) vs.  58% (26697/46165) lpk.dll
     52% (42/81) vs.  38% (17735/46165) devobj.dll
     52% (42/81) vs.  38% (17737/46165) sechost.dll
     52% (42/81) vs.  38% (17737/46165) CRYPTBASE.dll
     52% (42/81) vs.  38% (17737/46165) KERNELBASE.dll
     41% (33/81) vs.  27% (12676/46165) sspicli.dll
     52% (42/81) vs.  39% (18184/46165) cfgmgr32.dll
     60% (49/81) vs.  49% (22616/46165) mpr.dll
     27% (22/81) vs.  16% (7381/46165) mdnsNSP.dll
     15% (12/81) vs.   4% (1718/46165) igd10umd32.dll
     35% (28/81) vs.  24% (11198/46165) msvcr90.dll
     19% (15/81) vs.   8% (3920/46165) AavmRpch.dll
     19% (15/81) vs.   8% (3920/46165) aswCmnOS.dll
     19% (15/81) vs.   8% (3920/46165) Aavm4h.dll
     19% (15/81) vs.   8% (3920/46165) ashTask.dll
     19% (15/81) vs.   8% (3920/46165) aswProperty.dll
     19% (15/81) vs.   8% (3920/46165) aswEngLdr.dll
     19% (15/81) vs.   8% (3920/46165) aswCmnBS.dll
     19% (15/81) vs.   8% (3920/46165) aswCmnIS.dll
     19% (15/81) vs.   8% (3920/46165) aswAux.dll
     19% (15/81) vs.   8% (3920/46165) ashBase.dll
    100% (81/81) vs.  90% (41714/46165) mscms.dll
     27% (22/81) vs.  19% (8584/46165) dhcpcsvc6.DLL
     26% (21/81) vs.  17% (8061/46165) oleacc.dll
    100% (81/81) vs.  92% (42634/46165) userenv.dll
     73% (59/81) vs.  65% (30144/46165) icm32.dll
      9% (7/81) vs.   2% (960/46165) msxml6.dll
     25% (20/81) vs.  18% (8411/46165) msvcp90.dll
    100% (81/81) vs.  94% (43595/46165) msasn1.dll
    100% (81/81) vs.  94% (43597/46165) crypt32.dll
Bug 759788 (a regression of bug 719117) landed in all three channels today.
Can you check in a few days and see if there's a downward spike?
From looking at the crash data, this doesn't appear to be a regression in FF13.0b6, although it does appear to be a regression (at least in crash volume) from FF12.0. Given this, we've decided to go to build with FF13.0b7 without a fix for this bug.
One commonality among the different URLs is that many of the sites use Java in some way.
I tested many of the URLs on both Windows 7 and Win XP lab machines and so far have not been able to generate a crash.
(In reply to Alex Keybl [:akeybl] from comment #9)
> From looking at the crash data, this doesn't appear to be a regression in
> FF13.0b6, although it does appear to be a regression (at least in crash
> volume) from FF12.0. Given this, we've decided to go to build with FF13.0b7
> without a fix for this bug.

Looking at this more, Comment 6 appears to be misleading. It doesn't line up with what I'm seeing on crash-stats. Scoobidiver is correct in that this exploded in beta 6 and isn't apparent on the top crash list in beta 5 (even now), so this isn't an external issue and does appear to be a regression in beta 6.

Unless Bug 759788 fixes this crash in Beta 7 (which is unconfirmed), we've still got a big problem here.
I'm now able to reproduce this reliably on a netbook with 2GB of RAM

STR:
1) go to scratch.mit.edu
2) click on front page projects
3) while plugin is loading, or soon after, click on the 'projects' link at the top
4) click more projects, play them, etc.
5) click 'galleries' link at the top
6) Click "Code Lyoko RPG" (may not be recently changed soon though)
7) If it doesn't crash there already, click on more Java pages linked from there
Java SE 6 U30
Version: 6.0.300.12

Low RAM and 32 bit windows may also have something to do with it. Haven't been able to reproduce since the first 2 times.
There could be something going on with the signature summary view, so that is something the CrashKill team should take a look at. Also https://crash-analysis.mozilla.com/rkaiser/2012-05-30/2012-05-30.firefox.13.explosiveness.html shows that crash on the radar but it was not flagged as a top crash according to the algorithm, so we should probably look at that as well.

(In reply to Alex Keybl [:akeybl] from comment #12)
> (In reply to Alex Keybl [:akeybl] from comment #9)
> > From looking at the crash data, this doesn't appear to be a regression in
> > FF13.0b6, although it does appear to be a regression (at least in crash
> > volume) from FF12.0. Given this, we've decided to go to build with FF13.0b7
> > without a fix for this bug.
> 
> Looking at this more, Comment 6 appears to be misleading. It doesn't line up
> with what I'm seeing on crash-stats. Scoobidiver is correct in that this
> exploded in beta 6 and isn't apparent on the top crash list in beta 5 (even
> now), so this isn't an external issue and does appear to be a regression in
> beta 6.
> 
> Unless Bug 759788 fixes this crash in Beta 7 (which is unconfirmed), we've
> still got a big problem here.
Alex, I've so far been unable to reproduce this in a VM, replicating your STR, OS, and Java version. I've got 40 "scratches" open now and playing and still no crash. My VM's memory is set to 512MB so I would expect it to be crashing by now.

Can you please try if this reproduces for you in 13.0b7? There are candidates available now. Also see if you can reproduce this with Java 7u4 (that's the latest version Sun offers from their download page).

Thanks
Better STR:

1) Install FF13b6
2) Create a new profile, load Firefox with that
3) in the second tab, go to scratch.mit.edu
4) Click "Jetpack Jeffrey" under Featured Projects
5) Press up and to the right until Jeffrey hits the top of the screen
6) Click "galleries" at the top
7) Go to page 2
8) Click "Code Lyoko RPG"
9) If it doesn't crash here, click one of the projects, it should crash soon
(In reply to Mats Palmgren [:mats] from comment #4)
> From bp-ff3bf364-b2e0-427c-be9d-c69f62120525:
> Total Virtual Memory	2147352576
> Available Virtual Memory	1946435584
> System Memory Use Percentage	26
> Available Page File	3656826880
> Available Physical Memory	1472749568
> OOMAllocationSize	12
> 
> This doesn't make sense to me - why are we aborting on OOM for a 12 byte
> allocation with 1946435584 bytes of available memory?

Maybe some sort of memory corruption to a heap (jemalloc) data structure?
Manual correlations suggest 6.0.310.5 version of Java is more common in the crash landscape: 56% (45/81) vs.   1% (342/46165) 6.0.310.5
(In reply to Alex Keybl [:akeybl] from comment #14)
> Java SE 6 U30
> Version: 6.0.300.12

Not to distract for testing, but that version of Java was blocked in bug 739955 was it not?
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #20)
> (In reply to Alex Keybl [:akeybl] from comment #14)
> > Java SE 6 U30
> > Version: 6.0.300.12
> 
> Not to distract for testing, but that version of Java was blocked in bug
> 739955 was it not?

Somebody from QA can double check what's going wrong there tomorrow on the netbook.
So I've reproduced 10 or so times on beta 6, and 0 times on beta 7. Juan is now able to reproduce. If he's not able to repro on beta 7 by the time I get home from work, I'll send plans for the final FF13 build.
Okay, thanks. Yeah, I don't see a point in spending much more energy on this, especially if:

A) We have a reproducible set of steps and hardware in hand
B) It is not affecting Beta 7

Alex, is there still value in having Softvision test on this specific issue or should I refocus them on doing their usual sign-off work and exploratory plug-ins testing?
On a Win XP VM with Java 6.0.320.5:

Using Fx13b6, I was able to reproduce this crash, same signature, 5 times in about 30 minutes by doing a combination of the steps in comment #17, and some tab drag-and-drop, and successive loading of different examples.

On Fx13b7 candidates, I have spent a little more than a half hour doing the same things, and I have yet to crash.
Thanks Juan. Given your's and Alex's testing I think we may be able to suspect this is resolved in Beta 7. I believe QA's focus should now be on trying to get Beta 7 out the door as soon as we can (targeting mid-day tomorrow as promised earlier). Beta feedback should prove us right or wrong, either way.
Adding qawanted for tracking purposes. There's no specific call-to-action for QA at this point but we will want to keep our eye on this as we continue to push toward release.
Keywords: qawanted
Keywords: needURLs
It's #291 top browser crasher in 13.0b7.
Keywords: topcrash
No longer a top crasher, no need to continue tracking.
tracking-firefox13: + → -
tracking-firefox14: + → -
~45% of firefox crashes are startup
~90% of thunderbird crashes are startup
Whiteboard: [startupcrash][tbird crash]
(In reply to Wayne Mery (:wsmwk) from comment #33)
> is
> https://crash-stats.mozilla.com/report/index/56af7f7d-e7f3-4afd-ae31-
> 869f02121019 the same crash?
I think it's an OOM too:
System Memory Use Percentage	96
Crash Signature: wchar_t)] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | `anonymous namespace''::CSSParserImpl::ParseSelectorGroup(nsCSSSelectorList*&) ] → wchar_t)] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | `anonymous namespace''::CSSParserImpl::ParseSelectorGroup(nsCSSSelectorList*&)] [@ `anonymous namespace''::CSSParserImpl::ParseSelectorGroup(nsCSSSelector…
Crash Signature: namespace''::CSSParserImpl::ParseSelectorGroup(nsCSSSelectorList*&)] → namespace''::CSSParserImpl::ParseSelectorGroup(nsCSSSelectorList*&)] [@ moz_abort | je_malloc | mozglue.dll@0x6280 ]
Mozilla/5.0 (Windows NT 6.1; rv:25.0) Gecko/20100101 Firefox/25.0
Build ID: 20130805030205

I could not reproduce the crash using the steps from Comments 13 and 17 neither on Firefox 13.06 nor on the latest Nightly 25.0a1. 

Checked the Socorro reports and I found several crashes related with the signatures from this bug on Firefox 22, 23 and 24. 

- for the first signature - there are 176 crashes on Firefox 22, 5 crashes on Firefox 23 betas and 1 crash on Firefox 24.
http://bit.ly/13CNvxk


- for the second signature - there are 33 crashes on Firefox 23.
http://bit.ly/13XKCCF

- and for the third signature - there are 6 crashes on Firefox 23 and 1 crash on Firefox 23b10.

Considering the low volume of crashes, is there any more need for QA tracking? Is it ok if I remove the qawanted keyword?
> - and for the third signature - there are 6 crashes on Firefox 23 and 1
> crash on Firefox 23b10.

http://bit.ly/13CPqCa
Checked the Socorro reports and these are the results:
- for the first signature there are: 25 crashes on Firefox 23, 3 crashes on Firefox 24, 0 crashes on Firefox 25 and 26. (http://bit.ly/16muShO)
-for the second signature there are: 2 crashes on Firefox 23, 0 crashes on Firefox 24, 25, 26 (http://bit.ly/13PNgih)
- for the third signature there are 0 crashes for Firefox 23, 24, 25 and 26 (http://bit.ly/1asTEOg).
- I couldn't find any crashes for the 4th signature.

Considering the low volume of crashes, I'm removing the qawanted keyword.
Keywords: qawanted
Crash Signature: namespace''::CSSParserImpl::ParseSelectorGroup(nsCSSSelectorList*&)] [@ moz_abort | je_malloc | mozglue.dll@0x6280 ] → namespace''::CSSParserImpl::ParseSelectorGroup(nsCSSSelectorList*&)] [@ moz_abort | je_malloc | mozglue.dll@0x6280 ] [@ mozalloc_abort | mozalloc_handle_oom | moz_xmalloc | `anonymous namespace''::CSSParserImpl::ParseSelector] [@ mozalloc_abort | moza…
I tried https://scratch.mit.edu/projects/94408254/ (comment 13) in a new profile using nightly build
no crash


(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #34)
> ~45% of firefox crashes are startup
> ~90% of thunderbird crashes are startup

still pretty much true.

and still low volume for current versions
https://crash-stats.mozilla.com/search/?signature=~CSSParserImpl&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=uptime&_columns=user_comments#facet-signature
CSSParserImpl is gone so it's not worth tracking these signatures anymore.
Please file new bugs as appropriate.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.