Last Comment Bug 675437 - crash nsContentUtils::IsEventAttributeName
: crash nsContentUtils::IsEventAttributeName
Status: VERIFIED FIXED
[inbound] [qa!]
: crash, regression
Product: Core
Classification: Components
Component: General (show other bugs)
: Trunk
: All All
: -- critical with 2 votes (vote)
: mozilla8
Assigned To: Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01)
:
Mentors:
http://planet.mozilla.org/rss20.xml
: 675506 675536 675904 (view as bug list)
Depends on:
Blocks: 532972 482909 675492
  Show dependency treegraph
 
Reported: 2011-07-30 07:46 PDT by XtC4UaLL [:xtc4uall]
Modified: 2011-10-05 05:57 PDT (History)
24 users (show)
dholbert: in‑testsuite?
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
fixed


Attachments
stack (16.93 KB, text/plain)
2011-07-30 12:29 PDT, Bob Clary [:bc:]
no flags Details
Obtain the local name atom the right way (1.23 KB, patch)
2011-08-01 00:30 PDT, Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01)
bzbarsky: review+
Details | Diff | Splinter Review

Description XtC4UaLL [:xtc4uall] 2011-07-30 07:46:44 PDT
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
Comment 1 Boris Zbarsky [:bz] 2011-07-30 08:47:14 PDT
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....
Comment 2 XtC4UaLL [:xtc4uall] 2011-07-30 11:32:35 PDT
Handing in the Regrange, FWIW:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=acd21e50bd12&tochange=8fb752f5e1fa
Comment 3 Bob Clary [:bc:] 2011-07-30 12:29:13 PDT
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.
Comment 4 Jim Jeffery not reading bug-mail 1/2/11 2011-07-30 13:09:54 PDT
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 Christian Ascheberg 2011-07-30 17:04:53 PDT
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) ]
Comment 6 Boris Zbarsky [:bz] 2011-07-30 19:39:40 PDT
> ##!!! 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
Comment 7 Daniel Holbert [:dholbert] 2011-07-31 16:46:35 PDT
*** Bug 675536 has been marked as a duplicate of this bug. ***
Comment 8 Daniel Holbert [:dholbert] 2011-07-31 16:48:09 PDT
Also crashes at http://planet.mozilla.org/rss20.xml - setting that as 'URL' here, since no URL is set yet.
Comment 9 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2011-08-01 00:30:59 PDT
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.
Comment 10 Boris Zbarsky [:bz] 2011-08-01 06:05:33 PDT
> 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 11 Boris Zbarsky [:bz] 2011-08-01 06:05:55 PDT
Comment on attachment 549732 [details] [diff] [review]
Obtain the local name atom the right way

r=me
Comment 12 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2011-08-01 07:15:24 PDT
Thanks. Landed in inbound:
http://hg.mozilla.org/integration/mozilla-inbound/rev/98303320cbbe

I'll experiment with writing a test again.
Comment 13 Marco Bonardo [::mak] (Away 6-20 Aug) 2011-08-02 03:19:07 PDT
http://hg.mozilla.org/mozilla-central/rev/98303320cbbe
Comment 14 Thomas Ahlblom 2011-08-02 05:28:31 PDT
*** Bug 675904 has been marked as a duplicate of this bug. ***
Comment 15 Jim Jeffery not reading bug-mail 1/2/11 2011-08-02 06:49:18 PDT
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.
Comment 16 Jim Jeffery not reading bug-mail 1/2/11 2011-08-02 06:50:05 PDT
Damn bugzilla - setting back to resolved fixed for now:
Comment 17 Boris Zbarsky [:bz] 2011-08-02 07:02:33 PDT
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?
Comment 18 Jim Jeffery not reading bug-mail 1/2/11 2011-08-02 07:06:36 PDT
(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..
Comment 19 Boris Zbarsky [:bz] 2011-08-02 07:12:04 PDT
Aaand fixing the target milestone _again_.  ;)

I filed bug 675925.
Comment 20 Robert Kaiser 2011-08-02 08:02:26 PDT
(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 22 Brian Carpenter [:geeknik] 2011-08-03 16:10:43 PDT
*** Bug 675506 has been marked as a duplicate of this bug. ***
Comment 23 Sheila Mooney 2011-08-25 14:53:16 PDT
I don't see this signature on the 9.0 or 8.0a2.
Comment 24 Robert Kaiser 2011-08-26 05:00:03 PDT
(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).
Comment 25 AndreiD[QA] 2011-10-05 05:57:39 PDT
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

Note You need to log in before you can comment on or make changes to this bug.