crash nsContentUtils::IsEventAttributeName

VERIFIED FIXED in Firefox 8

Status

()

Core
General
--
critical
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: xtc4uall, Assigned: hsivonen)

Tracking

(Blocks: 1 bug, {crash, regression})

Trunk
mozilla8
crash, regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox8+ fixed)

Details

(Whiteboard: [inbound] [qa!], crash signature, URL)

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
This bug was filed from the Socorro interface and is 
report bp-f23f0dca-7f76-4a7c-8084-9549f2110730 .
============================================================= 

Seems to been introduced in today's Nightly (2011-07-30).

0 	xul.dll 	nsContentUtils::IsEventAttributeName(nsIAtom*,int) 	content/base/src/nsContentUtils.cpp:2978
1 	xul.dll 	nsGenericHTMLElement::UnsetAttr(int,nsIAtom*,int) 	content/html/content/src/nsGenericHTMLElement.cpp:1238
2 	xul.dll 	nsTreeSanitizer::SanitizeAttributes(mozilla::dom::Element*,nsTHashtable<nsISupportsHashKey>*,nsIAtom***,int,int,int) 	content/base/src/nsTreeSanitizer.cpp:1273
3 	xul.dll 	nsTreeSanitizer::Sanitize(nsIContent*) 	content/base/src/nsTreeSanitizer.cpp:1416
4 	xul.dll 	nsScriptableUnescapeHTML::ParseFragment(nsAString_internal const&,int,nsIURI*,nsIDOMElement*,nsIDOMDocumentFragment**) 	toolkit/components/feeds/nsScriptableUnescapeHTML.cpp:223
5 	xul.dll 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102
6 	xul.dll 	XPC_WN_CallMethod(JSContext*,unsigned int,unsigned __int64*) 	js/src/xpconnect/src/xpcwrappednativejsops.cpp:1595
7 	mozjs.dll 	js::Invoke(JSContext*,js::CallArgs const&,js::MaybeConstruct) 	js/src/jsinterp.cpp:656
8 	mozjs.dll 	js::Interpret(JSContext*,js::StackFrame*,js::InterpMode) 	js/src/jsinterp.cpp:4008
9 	mozjs.dll 	js::RunScript(JSContext*,JSScript*,js::StackFrame*) 	js/src/jsinterp.cpp:613
10 	mozjs.dll 	js::Invoke(JSContext*,js::CallArgs const&,js::MaybeConstruct) 	js/src/jsinterp.cpp:686
11 	mozjs.dll 	js::ExternalInvoke(JSContext*,js::Value const&,js::Value const&,unsigned int,js::Value*,js::Value*) 	js/src/jsinterp.cpp:805
12 	mozjs.dll 	JS_CallFunctionValue 	js/src/jsapi.cpp:5085
13 	xul.dll 	nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*,unsigned short,XPTMethodDescriptor const*,nsXPTCMiniVariant*) 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1657
14 	xul.dll 	nsXPCWrappedJS::CallMethod(unsigned short,XPTMethodDescriptor const*,nsXPTCMiniVariant*) 	js/src/xpconnect/src/xpcwrappedjs.cpp:585
15 	xul.dll 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114
16 	xul.dll 	SharedStub 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141
17 	xul.dll 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102

I got this when loading e.g. http://feeds.feedburner.com/stadt-bremerhaven/dqXM?format=xml

Maybe Fallout of Bug 482909
(Reporter)

Updated

6 years ago
Component: General → General
Product: Firefox → Core
QA Contact: general → general
Could be, yes.  That IsEventAttributeName call is made before we unset the attr, so holding a weak ref to the atom is _probably_ not the problem....
Blocks: 482909
tracking-firefox8: --- → ?
Keywords: regression
(Reporter)

Comment 2

6 years ago
Handing in the Regrange, FWIW:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=acd21e50bd12&tochange=8fb752f5e1fa

Comment 3

6 years ago
Created attachment 549593 [details]
stack

1. http://twitpic.com/photos/kcm_Kay/feed.rss NSFW (not 100% reliable)
2. Assert then Crash

##!!! ASSERTION: getting atom-value of nodeinfo-name: 'IsAtom()', file /work/mozilla/builds/nightly/mozilla/layout/style/../../content/base/src/nsAttrName.h, line 128
###!!! ASSERTION: getting atom-value of nodeinfo-name: 'IsAtom()', file /work/mozilla/builds/nightly/mozilla/layout/style/../../content/base/src/nsAttrName.h, line 128

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xd8d8d8d8
0x053e95e0 in nsContentUtils::IsEventAttributeName (aName=0x28c367a1, aType=1) at /work/mozilla/builds/nightly/mozilla/content/base/src/nsContentUtils.cpp:2978
2978	  if (name[0] != 'o' || name[1] != 'n')

#0  0x053e95e0 in nsContentUtils::IsEventAttributeName (aName=0x28c367a1, aType=1) at /work/mozilla/builds/nightly/mozilla/content/base/src/nsContentUtils.cpp:2978

What does this 0xd8d8d8d8 address mean?

Seen on Mac/Linux Nightly. Couldn't reproduce with yesterday's builds. I tried saving the content to reproduce locally but couldn't reproduce on Mac at least. I'll try again with fresh Linux builds.

Updated

6 years ago
Blocks: 532972
OS: Windows 7 → All
Hardware: x86_64 → All
Another crash-report:
https://crash-stats.mozilla.com/report/index/bp-3ecd5f46-1892-4f63-beb7-0b3cc2110730

STR: Install ForecastFox addon into an older build 
update from the older build to today's nightly
hover over the icons in the weather icons - crash 


works in cset: http://hg.mozilla.org/mozilla-central/rev/f5f1e3822540
broken in cset: http://hg.mozilla.org/mozilla-central/rev/8fb752f5e1fa

Comment 5

6 years ago
Also crashes on this link, using current nightly on windows:
http://pipes.yahoo.com/pipes/pipe.run?_id=6cc33ec11340418ec7c3cb5025327fff&_render=rss

crash-reports:
https://crash-stats.mozilla.com/report/index/bp-baeaa749-ad4c-417d-87a6-5fe5a2110730 [@ nsContentUtils::IsEventAttributeName(nsIAtom*, int) ]
https://crash-stats.mozilla.com/report/index/bp-9c3e935c-d94f-46d3-ab12-b02b42110730 [@ nsContentUtils::IsEventAttributeName(nsIAtom*, int) ]
https://crash-stats.mozilla.com/report/index/bp-f112a7d6-06a4-416d-b777-9fa3d2110730 [@ nsGenericHTMLElement::AfterSetAttr(int, nsIAtom*, nsAString_internal const*, int) ]
> ##!!! ASSERTION: getting atom-value of nodeinfo-name: 'IsAtom()', file
> /work/mozilla/builds/nightly/mozilla/layout/style/../../content/base/src
> /nsAttrName.h, line 128

Oh, yes.  |attrName->Atom()| is bogus, in general.  That should be LocalName() instead!

> What does this 0xd8d8d8d8 address mean?

/msg firebot 0xd8d8d8d8
*firebot* Was it not... er, someone, who said: 0xd8d8d8d8 is leaky MARKER2_0 or
          nsFixedSizeAllocator's deletion pattern
Duplicate of this bug: 675536
Also crashes at http://planet.mozilla.org/rss20.xml - setting that as 'URL' here, since no URL is set yet.
Crash Signature: [@ nsContentUtils::IsEventAttributeName(nsIAtom*, int)] → [@ nsContentUtils::IsEventAttributeName(nsIAtom*, int)] [@ nsContentUtils::IsEventAttributeName]
Flags: in-testsuite?
Blocks: 675492
(Assignee)

Comment 9

6 years ago
Created attachment 549732 [details] [diff] [review]
Obtain the local name atom the right way

It's unclear to me how to write a minimized test case for this. The Planet Mozilla RSS 2.0 feed crashed on a generated xml:base that's not in the actual feed. Yet, all the existing RSS 2.0 tests didn't crash.
Assignee: nobody → hsivonen
Status: NEW → ASSIGNED
Attachment #549732 - Flags: review?(bzbarsky)
> It's unclear to me how to write a minimized test case for this.

Make sure that the feed has an attribute that's not in the null namespace?

I have no idea why the existing tests didn't crash; that seems very suspicious.  Or did they just assert without crashing?
Comment on attachment 549732 [details] [diff] [review]
Obtain the local name atom the right way

r=me
Attachment #549732 - Flags: review?(bzbarsky) → review+
(Assignee)

Comment 12

6 years ago
Thanks. Landed in inbound:
http://hg.mozilla.org/integration/mozilla-inbound/rev/98303320cbbe

I'll experiment with writing a test again.
Whiteboard: [inbound]
http://hg.mozilla.org/mozilla-central/rev/98303320cbbe
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla8

Updated

6 years ago
Duplicate of this bug: 675904
Well, using latest hourly win32 m-c based on cset:
http://hg.mozilla.org/mozilla-central/rev/10927265c555
which should contain the fix for this bug, I find that ForecastFox still is crashing the browser. 

Since its an hourly build the crash-report is useless - no symbols.  Guess we get to wait for tomorrows nightly :(

Personally, I think this should be backed out until the isues are understood. I had no problems with Forecast Fox prior to the landing of:
https://bugzilla.mozilla.org/show_bug.cgi?id=482909 

unless there is another bug aggravating ForecastFox that landed in the range I noted in comment #4 above - I don't have a way to biset those patches as I don't have a build environ to work with.
Status: RESOLVED → UNCONFIRMED
Ever confirmed: false
Resolution: FIXED → ---
Target Milestone: mozilla8 → ---
Damn bugzilla - setting back to resolved fixed for now:
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
And fixing the target milestone.

Jim, the ForecastFox issue is separate from this bug.  It's a regression from the same changeset, but a totally different problem; it's immediately obvious from just comparing the crash signature of the crash from comment 4 to the crash signature of this bug.  Is there a separate bug filed for that crash?
Target Milestone: --- → mozilla8
(In reply to comment #17)
> And fixing the target milestone.
> 
> Jim, the ForecastFox issue is separate from this bug.  It's a regression
> from the same changeset, but a totally different problem; it's immediately
> obvious from just comparing the crash signature of the crash from comment 4
> to the crash signature of this bug.  Is there a separate bug filed for that
> crash?

Not that I've found, but really have not look too hard, as I was under the mistaken impression the crash was this bug..
Target Milestone: mozilla8 → ---
Aaand fixing the target milestone _again_.  ;)

I filed bug 675925.

Comment 20

6 years ago
(In reply to comment #19)
> Aaand fixing the target milestone _again_.  ;)
> 
> I filed bug 675925.

Bug 675492 has existed already, and a search for "Forecastfox" should have brought it up fast. Even looking into dependencies of this bug here would have helped. ;-)

Comment 21

6 years ago
https://crash-stats.mozilla.com/report/index/bp-cfa9c8f4-6562-4b48-bdb1-02f2a2110802
https://crash-stats.mozilla.com/report/index/bp-ac1a41e1-935b-4668-990c-6ca912110802
https://crash-stats.mozilla.com/report/index/bp-ba173074-fffd-40c1-8fdc-d55172110802
https://crash-stats.mozilla.com/report/index/bp-ff678811-0e7a-4cc8-9cf2-10fa82110802
https://crash-stats.mozilla.com/report/index/bp-b0788888-9928-4bb7-ba68-121ef2110802
https://crash-stats.mozilla.com/report/index/bp-025eeab4-f593-4280-b0b1-fb2602110801
https://crash-stats.mozilla.com/report/index/bp-50a8fb4d-84b7-461b-b9c6-f1eb32110801
https://crash-stats.mozilla.com/report/index/bp-8a963af6-2fd7-4a1c-a189-cd2af2110731
https://crash-stats.mozilla.com/report/index/bp-b8198ab3-134d-4320-9d8d-d287e2110731
https://crash-stats.mozilla.com/report/index/bp-1fe31fb5-654e-44d3-81cd-776ed2110731
https://crash-stats.mozilla.com/report/index/bp-bab8fb46-5f2f-402a-8fc2-ad4132110731
https://crash-stats.mozilla.com/report/index/bp-c2667be3-c714-40f4-9d17-977f62110731
https://crash-stats.mozilla.com/report/index/bp-a3a146db-f3ba-42f9-940e-930ae2110731
https://crash-stats.mozilla.com/report/index/bp-31521a22-070c-48dd-83c6-c916b2110730
Duplicate of this bug: 675506

Comment 23

6 years ago
I don't see this signature on the 9.0 or 8.0a2.

Comment 24

6 years ago
(In reply to Sheila Mooney from comment #23)
> I don't see this signature on the 9.0 or 8.0a2.

Sure, this has been fixed for 8 (fixing the TM again as comment #19 somehow didn't).
Target Milestone: --- → mozilla8

Updated

6 years ago
status-firefox8: --- → fixed
tracking-firefox8: ? → +

Comment 25

6 years ago
I tested to see if the issue is verified fixed on Beta, Aurora and Nightly builds of Firefox.
I used the link from comment 8 to check if the browser crashes as it did for the Nightly build from 31 July: 
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0a1) Gecko/20110731 Firefox/8.0a1
I got the following results:

Win7:
-> WFM on Nightly: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111004 Firefox/10.0a1
-> WFM on Aurora: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a2) Gecko/20111004 Firefox/9.0a2
-> WFM on Beta: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0

Mac OS 10.7:
-> WFM on Beta: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20100101 Firefox/8.0
-> WFM on Aurora: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0a2) Gecko/20111004 Firefox/9.0a2
-> WFM on Nightly: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a1) Gecko/20111004 Firefox/10.0a1

Ubuntu 11.04:
-> WFM on Beta: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0
-> WFM on Aurora: Mozilla/5.0 (X11; Linux x86_64; rv:9.0a2) Gecko/20111003 Firefox/9.0a2
-> WFM on Nightly: Mozilla/5.0 (X11; Linux x86_64; rv:10.0a1) Gecko/20111004 Firefox/10.0a1

Since on All Platforms and all Firefox branches the issue is not reproducible anymore I'm setting the status to Verified and setting "[qa!]" (verified on all branches) in the whiteboard
Status: RESOLVED → VERIFIED
Whiteboard: [inbound] → [inbound] [qa!]
You need to log in before you can comment on or make changes to this bug.