Closed Bug 675437 Opened 14 years ago Closed 14 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: 14 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: 14 years ago → 14 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: