Closed Bug 675437 Opened 13 years ago Closed 13 years ago

crash nsContentUtils::IsEventAttributeName

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla8
Tracking Flags:
Tracking Status
firefox8 + fixed

People

(Reporter: xtc4uall, Assigned: hsivonen)

References

(
URL
)

Details

(Keywords: crash, regression, Whiteboard: [inbound] [qa!])

Crash Data

Attachments

(2 files)

stack
16.93 KB, text/plain
Details
Obtain the local name atom the right way
1.23 KB, patch
bzbarsky
: review+
Details | Diff | Splinter Review 
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
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
Attached file 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.
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
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
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]
Blocks: 675492
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+
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
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla8
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
Closed: 13 years ago → 13 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.
(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. ;-)
I don't see this signature on the 9.0 or 8.0a2.
(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
status-firefox8: --- → fixed
tracking-firefox8: ? → +
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.

Attachment

General

Creator:
Created:
Updated:
Size: