Crash with DOM Inspector [@ inDOMView::AttributeChanged(nsIDocument*, nsIContent*, int, nsIAtom*, int, unsigned int) ]

RESOLVED FIXED in mozilla2.0b1



10 years ago
2 months ago


(Reporter: alice0775, Assigned: timeless)



Windows XP

Firefox Tracking Flags

(Not tracked)


(crash signature)


(1 attachment)



10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090618 Firefox/3.5.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090618 Shiretoko/3.5pre ID:20090618042848

Random crash when click recent used folder drop-down button in Edit Bookmark panel.

Reproducible: Always

Steps to Reproduce:
1.Start Shiretoko with new profile
2.Using it for a while
3.Double click Star button, recent used folder drop-down button at right side of folder row.
Actual Results:  
Random crash

Expected Results:  
Do not crash

Crash report:


10 years ago
Version: unspecified → 3.5 Branch

Comment 1

10 years ago
You have some sort of inspector extension (firebug? dom inspector?) installed+enabled.

Signature	inDOMView::AttributeChanged(nsIDocument*, nsIContent*, int, nsIAtom*, int, unsigned int)
UUID	50b22cc2-a979-42d6-8dfb-b18432090618
Time 	2009-06-18 06:46:24.991173
Uptime	1245
Last Crash	523939 seconds before submission
Product	Firefox
Version	3.5pre
Build ID	20090618042848
Branch	1.9.1
OS	Windows NT
OS Version	5.1.2600 Service Pack 3
CPU	x86
CPU Info	GenuineIntel family 15 model 2 stepping 7
Crash Address	0x10
User Comments	
Processor Notes 	
Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	inDOMView::AttributeChanged 	layout/inspector/src/inDOMView.cpp:779
1 	xul.dll 	nsNodeUtils::AttributeChanged 	content/base/src/nsNodeUtils.cpp:110
2 	xul.dll 	nsGenericElement::SetAttrAndNotify 	content/base/src/nsGenericElement.cpp:4346
3 	xul.dll 	nsGenericElement::SetAttr 	content/base/src/nsGenericElement.cpp:4277
4 	xul.dll 	nsIContent::SetAttr 	obj-firefox/dist/include/content/nsIContent.h:265
5 	xul.dll 	nsMenuFrame::PopupOpened 	layout/xul/base/src/nsMenuFrame.cpp:582
6 	xul.dll 	nsMenuPopupFrame::ShowPopup 	layout/xul/base/src/nsMenuPopupFrame.cpp:610
7 	xul.dll 	nsXULPopupManager::ShowPopupCallback 	layout/xul/base/src/nsXULPopupManager.cpp:578
8 	xul.dll 	nsXULPopupManager::FirePopupShowingEvent 	layout/xul/base/src/nsXULPopupManager.cpp:1047
9 	xul.dll 	nsXULPopupShowingEvent::Run 	layout/xul/base/src/nsXULPopupManager.cpp:2012
10 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:510
11 	xul.dll 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:170
12 	xul.dll 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:193
13 	nspr4.dll 	PR_GetEnv 	
14 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:110
15 	firefox.exe 	firefox.exe@0x21a7 	
16 	kernel32.dll 	kernel32.dll@0x17076
Component: Bookmarks & History → DOM: Mozilla Extensions
Product: Firefox → Core
QA Contact: bookmarks → general
Version: 3.5 Branch → 1.9.1 Branch

Comment 2

10 years ago
Oh yes. I have installed DOM Inspector.

Now,I disable DOMi.
I will look at the state for a while.
Summary: Firefox 3.5pre Crash Report [@ inDOMView::AttributeChanged(nsIDocument*, nsIContent*, int, nsIAtom*, int, unsigned int) ] → Crash with DOM Inspector [@ inDOMView::AttributeChanged(nsIDocument*, nsIContent*, int, nsIAtom*, int, unsigned int) ]

Comment 3

9 years ago introduced the bug.
Blocks: 345982
Component: DOM: Mozilla Extensions → Layout: Misc Code
Keywords: crash
QA Contact: general → layout.misc-code
Version: 1.9.1 Branch → Trunk
Would you mind telling us what the bug is and saving the rest of us 5 minutes that you've clearly already spent?

Comment 5

9 years ago
This crash does not occur more than these past 1 month.
Can anybody change the status into WORKSFORME.

Comment 6

9 years ago
Created attachment 415818 [details] [diff] [review]

In the:
      // if this view has a root node but is not displaying it,
      // it is ok to act as if the changed attribute is on the root.
case, we don't get a contentRow, and we only want to use that row for some ordering. so we just insert the row...
Assignee: nobody → timeless
Ever confirmed: true
Attachment #415818 - Flags: review?(dbaron)
Comment on attachment 415818 [details] [diff] [review]

This code looks ok, but I don't understand the patch in bug 345982 at all; could you find somebody who does to review it?


9 years ago
Attachment #415818 - Flags: review?(sylvain.pasche)
Attachment #415818 - Flags: review?(neil)
Attachment #415818 - Flags: review?(dbaron)


9 years ago
Attachment #415818 - Flags: review?(sdwilsh)

Comment 8

9 years ago
I couldn't figure out how to reproduce this.
If we're not showing element nodes, then we won't find an insert node, since we're appending to a flat list.
If we're showing element nodes, then the element whose attribute is changing will have a row, so that contentNode is not null.
Both cases seem to have a bug in that insertNode could be null when it shouldn't, which would have to be fixed carefully to avoid tripping this issue.

Comment 9

9 years ago
right, all i'm saying is roughly a subset of what you're saying: the current code is buggy. note that i'm not putting significant effort into rewriting (or understanding) this code, if this patch isn't what you want, reassign the bug.

reporter: thanks for the bug report, i'm glad you aren't crashing anymore at this time, but you've pointed out a bug in our code, and we'd kind of like to get rid of such bugs even if you can't hit them today, someone else might hit them tomorrow, and i'd rather avoid that (the someone might be me!).
Comment on attachment 415818 [details] [diff] [review]

clearing request per comment 8
Attachment #415818 - Flags: review?(sdwilsh)

Comment 11

8 years ago
I can reproduce a crash with almost the same signature:
@ inDOMView::AttributeChanged(nsIDocument*, nsIContent*, int, nsIAtom*, int)

Steps to reproduce:
1) Open
2) Open DOM Inspector
3) right click on the last "text"-element -> Insert -> After
   Node Type:     Element
   Namespace URI: null
   Tag Name:      image
4) right click on attribute panel -> Insert
   Node Name:     x-link:href
   Node Value:    http:\\
   Namespace URI: SVG
5) double click on newly created attribute
6) switch Namespace URI to XML -> OK
7) crash!

Is this the same bug or a different bug?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a6pre) Gecko/20100625 Minefield/3.7a6pre

Comment 12

8 years ago
Andreas: i'm going to assume it's the same bug and thank you for the steps to reproduce. unfortunately my recollection of this bug is that i was seeking instruction from sdwilsh/neil as to what to do to fix it (beyond my proposed patch). since neil was looking for an understanding of how to reach the crash, hopefully he can use your steps
Comment on attachment 415818 [details] [diff] [review]

Well I think the whole block is bogus but this does at least wallpaper the crash. (In this case somehow the number of attributes tracked by the view disagrees with the actual number of attributes on the node. No idea why that happened though.)
Attachment #415818 - Flags: review?(neil) → review+


8 years ago
Keywords: checkin-needed
Last Resolved: 8 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a6
Crash Signature: [@ inDOMView::AttributeChanged(nsIDocument*, nsIContent*, int, nsIAtom*, int, unsigned int) ]


7 years ago
Attachment #415818 - Flags: review?(sylvain.pasche)


2 months ago
Product: Core → Core Graveyard
Component: Layout: Misc Code → Layout
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.