Last Comment Bug 271669 - crash [@ nsXULDocument::AttributeChanged]
: crash [@ nsXULDocument::AttributeChanged]
[patch] reproducible
: crash, topcrash, verified1.8.0.4, verified1.8.1
Product: Core
Classification: Components
Component: XUL (show other bugs)
: Trunk
: All All
: -- critical with 2 votes (vote)
: ---
Assigned To: David Baron :dbaron: ⌚️UTC-10
: Neil Deakin
: 310280 314649 320562 (view as bug list)
Depends on: 327256 340733
  Show dependency treegraph
Reported: 2004-11-24 21:27 PST by Adam Hauner
Modified: 2011-06-13 10:01 PDT (History)
19 users (show)
dveditz: blocking1.8.0.2-
dveditz: blocking1.8.0.4-
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

possible patch (25.39 KB, patch)
2006-04-09 14:01 PDT, David Baron :dbaron: ⌚️UTC-10
no flags Details | Diff | Splinter Review
possible patch (23.89 KB, patch)
2006-04-09 22:09 PDT, David Baron :dbaron: ⌚️UTC-10
bzbarsky: review+
jst: superreview+
bzbarsky: approval‑branch‑1.8.1+
dveditz: approval1.8.0.4+
Details | Diff | Splinter Review
a back port for Firefox 1.0 (24.21 KB, patch)
2006-05-25 14:54 PDT, Jan Varga [:janv]
no flags Details | Diff | Splinter Review

Description Adam Hauner 2004-11-24 21:27:25 PST

I met crash while opening SeaMonkey Preferences window after startup, maybe I
have clicked checkbox in Download manager.

Comment's from same signature Talkback:
Opened preferences. Clicked + next to "Appearance" when crash occurred.
starting firefox after last crash
i opened my "mozilla 1.8a4_de_AT webbrowser 5 seconds later a system warning
Trying to open my bookmarks.
trying to install and subsiquently run newsmonster

line 1142]
line 2202]
line 2126]
line 584]
line 102]
line 2036]
line 1288]
line 1288]
line 3621]
line 1307]
line 3621]
line 1307]
line 1384]
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsapi.c, line
line 1346]
line 181]
line 491]
line 85]
line 1513]
line 1589]
line 2820]
line 5959]
line 5875]
line 2942]
line 1936]
line 6012]
line 5844]
line 2402]
line 2131]
line 166]
line 1078]
line 1095]
line 5329]
line 5581]
line 4091]
line 1356]
USER32.dll + 0x1ef0 (0x77e11ef0)
USER32.dll + 0x204c (0x77e1204c)
USER32.dll + 0x21af (0x77e121af)
line 216]
line 1331]
line 1802]
line 1828]
KERNEL32.DLL + 0x2893d (0x796f893d)
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2004-12-05 21:31:00 PST
Adam, is this reproducible?  And what's the actual build ID?  The one you gave
has one too many digits...
Comment 2 Adam Hauner 2004-12-06 01:19:35 PST
20041112306/trunk/W2K should be 2004112306/trunk/W2K correctly.

I can't reproduce, but I filled it to track it, because I'm not only one seeing
it (there are 35 incidents actually in TB db). Many reports are about opening
Preferences, but not all.

Some other comments for record:
I clicked on Prefs|Avanced to check settings. And, here I am. Previously I tried
to install the home button v.0.7, which is supposed to be compatible with
1.8a5. No response.	
trying to reset SSL	
browser open to default page, went to Edit, Preferences, and Appearances. Crash!	
after upgrade from 1.8a4 to 1.8a5 try to change language in user-profile	
trying to install micro mozilla theme
Home Page - Google
Selected Preferences, pressed + for Appearance	
opening the bookmarks menu
1) downloading nightly in DM
2) loading
3) opening preferences	
starting firefox after last crash
Opened preferences. Clicked + next to "Appearance" when crash occurred.
i opened my "mozilla 1.8a4_de_AT webbrowser 5 seconds later a system warning
appeared "mozilla - exe hat fehler verursacht und wird geschlossen..." at this
momen running tasks: 1276:865 - FreeMail von WEB.DE - Opera c´t 23/2004, S.166:
Soft-Link -
Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2004-12-06 08:36:30 PST
Well, it looks like the line number from talkback is bogus as usual (line 1142
can't possibly be crashing here).

The crash _could_ happen in line 1143 if something truly bizarre is going on and
aElement gets destroyed in the middle of this notification...
Comment 4 2004-12-06 09:58:29 PST
Does the crash only happen with certain extension(s)?
Does anyone have a debug build they can crash and debug?
Comment 5 Adam Hauner 2004-12-06 23:43:07 PST
Neil: I don't know, I usually don't use any extensions. Debug build - sorry, no.
Comment 6 Adam Hauner 2004-12-07 12:26:38 PST
TB2363692 points to
and TB2358776 points to:
In both cases it is line with alone "aModType":

// Now notify external observers
for (PRInt32 i = mObservers.Count() - 1; i >= 0; --i) {
    nsIDocumentObserver*  observer = (nsIDocumentObserver*)mObservers[i];
    observer->AttributeChanged(this, aElement, aNameSpaceID, aAttribute,

Is it better?
Comment 7 Boris Zbarsky [:bz] (still a bit busy) 2004-12-07 13:22:27 PST
Hmm.. that could crash if we have a null or deleted observer...
Comment 8 Ian Neal 2005-03-08 01:37:00 PST
I got this crash but no matter how I try doing the same steps again, it will not
crash again. I was trying to expland the "Appearance" pref tree. Again the stack
trace points to the aModType line.
Comment 9 timeless 2005-08-07 15:10:31 PDT
do we want to apply wallpaper? is there anything preventing these lists from
changing as the code loops around them?
Comment 10 Adam Guthrie 2005-09-28 17:23:08 PDT
*** Bug 310280 has been marked as a duplicate of this bug. ***
Comment 11 Adam Guthrie 2005-11-02 13:14:55 PST
*** Bug 314649 has been marked as a duplicate of this bug. ***
Comment 12 Roman Yepishev 2005-11-03 12:49:13 PST
OK, I managed to build the debug version and I can reproduce the same bug.

Could not figure what combination of account names/settings cause this and are there any relations of that kind, because it crashed randomly, sometimes working normally, sometimes not. There exists no other clickable button with arrow (except "print", but it's inactive at this stage), but it is clear that no activity should be performed before you click that nice button to make the crash happen again. I mean if any account has a 'Check on startup' it should be disabled as well as any possible start-up pop-ups.

#0  0x4094de06 in __libc_nanosleep () from /lib/
#1  0xfffffff4 in ?? ()
#2  0x4094dc87 in sleep () from /lib/
#3  0x08061232 in ah_crap_handler (signum=1084018420) at nsSigHandlers.cpp:132
#4  0x0806218a in nsProfileLock::FatalSignalHandler (signo=11)
    at nsProfileLock.cpp:210
#5  0x4020e5c3 in __pthread_sighandler () from /lib/
#6  <signal handler called>
#7  nsXULDocument::AttributeChanged (this=0x832fcf0, aElement=0x8577f58, 
    aNameSpaceID=0, aAttribute=0x81df650, aModType=2)
    at ../../../../../src/mozilla/content/xul/document/src/nsXULDocument.cpp:1138
#8  0x41aa0e38 in nsXULElement::SetAttrAndNotify (this=0x8577f58, 
    aNamespaceID=0, aAttribute=0x81df650, aPrefix=0x0, aOldValue=@0xbf845cd0, 
    aParsedValue=@0xbf845d68, aModification=0, aFireMutation=0, aNotify=1)
    at ../../../../../src/mozilla/content/xul/content/src/nsXULElement.cpp:1515
#9  0x41aa1223 in nsXULElement::SetAttr (this=0x8577f58, aNamespaceID=0, 
    aName=0x81df650, aPrefix=0x0, aValue=@0xbf845dcc, aNotify=1)
    at ../../../../../src/mozilla/content/xul/content/src/nsXULElement.cpp:1440
#10 0x4178e95b in nsIContent::SetAttr (this=0x0, aNameSpaceID=0, aName=0x0, 
    aValue=@0x0, aNotify=0) at nsIContent.h:284
#11 0x4192fa1b in nsMenuFrame::OpenMenu (this=0x87d8ee8, aActivateFlag=1)
    at ../../../../../src/mozilla/layout/xul/base/src/nsMenuFrame.cpp:732
#12 0x4192cbad in nsMenuFrame::ToggleMenuState (this=0x87d8ee8)
    at ../../../../../src/mozilla/layout/xul/base/src/nsMenuFrame.cpp:551
#13 0x41931319 in nsMenuFrame::HandleEvent (this=0x87d8ee8, 
    aPresContext=0x83fff30, aEvent=0xbf846258, aEventStatus=0xbf846094)
    at ../../../../../src/mozilla/layout/xul/base/src/nsMenuFrame.cpp:407
#14 0x4178af30 in PresShell::HandleEventInternal (this=0x821d0b8, 
    aEvent=0xbf846258, aView=0x8400768, aFlags=1, aStatus=0xbf846094)
    at ../../../src/mozilla/layout/base/nsPresShell.cpp:6408
#15 0x4178bf2a in PresShell::HandleEvent (this=0x821d0b8, aView=0x8400768, 
    aEvent=0xbf846258, aEventStatus=0xbf846094, aForceHandle=1, 
    at ../../../src/mozilla/layout/base/nsPresShell.cpp:6203
#16 0x41ad2b14 in nsViewManager::HandleEvent (this=0x84006e8, aView=0x8400768, 
    aEvent=0xbf846258, aCaptured=0)
    at ../../../src/mozilla/view/src/nsViewManager.cpp:2557
#17 0x41ad368e in nsViewManager::DispatchEvent (this=0x84006e8, 
    aEvent=0xbf846258, aStatus=0xbf8461c0)
    at ../../../src/mozilla/view/src/nsViewManager.cpp:2246
#18 0x41ac5e73 in HandleEvent (aEvent=0xbf846258)
    at ../../../src/mozilla/view/src/nsView.cpp:171
#19 0x4146b55e in nsCommonWidget::DispatchEvent (this=0x84007d8, 
    aEvent=0xbf846258, aStatus=@0xbf8462a8)
    at ../../../../src/mozilla/widget/src/gtk2/nsCommonWidget.cpp:219
#20 0x4146485e in nsWindow::OnButtonPressEvent (this=0x84007d8, 
    aWidget=0x8331ac8, aEvent=0x82fe828)
    at ../../../../src/mozilla/widget/src/gtk2/nsWindow.cpp:1556
#21 0x41464933 in button_press_event_cb (widget=0x0, event=0x82fe828)
    at ../../../../src/mozilla/widget/src/gtk2/nsWindow.cpp:3706
#22 0x4036f6cc in _gtk_marshal_BOOLEAN__BOXED ()
   from /usr/lib/
#23 0x4061a5fc in g_closure_invoke () from /usr/lib/
#24 0x4062a2f3 in g_signal_stop_emission () from /usr/lib/
#25 0x4062b2d1 in g_signal_emit_valist () from /usr/lib/
#26 0x4062b8c9 in g_signal_emit () from /usr/lib/
#27 0x40456db6 in gtk_widget_event_internal ()
   from /usr/lib/
#28 0x4036dbd5 in gtk_propagate_event () from /usr/lib/
#29 0x4036e09f in gtk_main_do_event () from /usr/lib/
#30 0x4055d1ea in gdk_event_dispatch () from /usr/lib/
#31 0x40673b7c in g_main_context_dispatch () from /usr/lib/
#32 0x40676f6b in g_main_context_check () from /usr/lib/
#33 0x40677287 in g_main_loop_run () from /usr/lib/
#34 0x4036d1b3 in gtk_main () from /usr/lib/
#35 0x41469342 in nsAppShell::Run (this=0x8190948)
    at ../../../../src/mozilla/widget/src/gtk2/nsAppShell.cpp:139
#36 0x415405b1 in nsAppStartup::Run (this=0x8190900)
    at ../../../../../src/mozilla/toolkit/components/startup/src/nsAppStartup.cpp:150
#37 0x08051169 in XRE_main (argc=1, argv=0xbf846bc4, aAppData=0x8067500)
    at ../../../src/mozilla/toolkit/xre/nsAppRunner.cpp:2313
#38 0x0804b398 in main (argc=0, argv=0x0)
    at ../../../src/mozilla/mail/app/nsMailApp.cpp:62
Comment 13 Boris Zbarsky [:bz] (still a bit busy) 2005-11-03 15:56:53 PST
So when you crash, what do local variables look like?  What's the exact line of code you crash on?
Comment 14 David Baron :dbaron: ⌚️UTC-10 2005-11-03 16:43:38 PST
In general we probably should be copying the observers array before notifying observers; it's a safer pattern to use.  But I don't see why the bug was assigned to me.
Comment 15 Roman Yepishev 2005-11-03 21:48:07 PST
The built in debug trace emits this right before segfault:

###!!! ASSERTION: index out of range: '0 <= aIndex && aIndex < Count()', file ../../dist/include/xpcom/nsVoidArray.h, line 80
Break: at file ../../dist/include/xpcom/nsVoidArray.h, line 80
Comment 16 Boris Zbarsky [:bz] (still a bit busy) 2005-11-03 21:56:04 PST
What's the stack trace to that assert?  What's the index look like there?
Comment 17 Roman Yepishev 2005-11-06 14:16:00 PST
I couldn't trace the behavior while running tb in debugger. It works without any errors or crashes when started this way :-/
Comment 18 Steve England [:stevee] 2005-12-16 12:32:25 PST
*** Bug 320562 has been marked as a duplicate of this bug. ***
Comment 19 Adam Guthrie 2005-12-16 13:04:26 PST
According to talkback, this is the #11 topcrasher for Firefox15.
Comment 20 Vlad Dascalu 2006-01-28 21:31:03 PST
I'm able to reproduce this bug with Thunderbird 1.5.

Upon startup, click the drop-down next to the "Get Messages" button.

I have 100k+ mails, and it seems it takes a couple of seconds on startup to initialize. If I click the "Get Messages" button within those seconds, I get a reproductible crash.

Talkback crashIDs: TB14397314X TB14461878H TB14461884E TB14512083Y TB14512175H TB14512178W TB14512183W TB14512189K

The crash happens all the time in the notification of observers thing, in nsXULDocument::AttributeChanged

1135 waterson            // Now notify external observers
1136                     for (PRInt32 i = mObservers.Count() - 1; i >= 0; --i) {
1137                         nsIDocumentObserver*  observer = (nsIDocumentObserver*)mObservers[i];
1138 jst                     observer->AttributeChanged(this, aElement, aNameSpaceID, aAttribute,
1139                                        aModType);

Crashing at 1138.
Comment 21 Vlad Dascalu 2006-01-28 21:33:35 PST
Regarding the previous post, no extensions installed except Talkback.

Using Mozilla Thunderbird version 1.5 (20051201)
Comment 22 Vlad Dascalu 2006-01-28 21:34:24 PST
Also, "Get Messages" should read "Get Mail" in comment #20.
Comment 23 Vlad Dascalu 2006-01-28 21:36:43 PST
Hmm, code-wise: do we have here some kind of lock in order to ensure that nobody else modifies the observers array while we do the 'for' loop?

If an array is removed while we're in the for loop, a crash would easily happen.

Any code gurus can answer if there is a lock or not? (I could take a peak at the code but I'm way behind :) )
Comment 24 Vlad Dascalu 2006-01-28 21:37:17 PST
array -> observer
Comment 25 Bernd 2006-01-29 00:22:18 PST
#10 0x4178e95b in nsIContent::SetAttr (this=0x0, aNameSpaceID=0, aName=0x0, 
    aValue=@0x0, aNotify=0) at nsIContent.h:284

Doesnt that mean that at
mContent is not valid?
Comment 26 Boris Zbarsky [:bz] (still a bit busy) 2006-01-29 21:48:29 PST
> Hmm, code-wise: do we have here some kind of lock in order to ensure that
> nobody else modifies the observers array while we do the 'for' loop?

No, we do not.  nsDocument has some such protection; this class does not.

If you can reproduce reliably, I can post a patch to do the nsDocument thing for you to try...

bernd, that stack frame looks confused (note that the attr name is 0 too and that everything is fine in the next frame).
Comment 27 Daniel Veditz [:dveditz] 2006-02-23 11:22:21 PST
No fix, misses
Comment 28 Vlad Dascalu 2006-03-10 13:27:13 PST
(In reply to comment #26)
> If you can reproduce reliably, I can post a patch to do the nsDocument thing
> for you to try...

That would mean setting up an environment where I can compile/run a debug version of Thunderbird, which I don't have the time for, currently.

Comment 29 Boris Zbarsky [:bz] (still a bit busy) 2006-03-10 21:46:21 PST
So actually, AttributeChanged handles an observer removing itself; just not others.  Just like nsDocument...
Comment 30 Marc Bejarano 2006-03-16 08:41:31 PST
TB16449102Z, too
Comment 31 Darin Fisher 2006-03-23 10:03:52 PST
boris: are you interested in trying to fix this for the 1.8 branches?  if a fix is simple enough (such as what dbaron proposed in comment #14) then perhaps we should try to get this into the stable branches.  thoughts?
Comment 32 Boris Zbarsky [:bz] (still a bit busy) 2006-03-23 13:34:36 PST
Copying the observers array might work... it'd also be a pretty big perf hit.  And it's not immediately obvious to me that it would help.  I suppose we could write up a patch to do that and see whether it does help somehow...
Comment 33 Daniel Veditz [:dveditz] 2006-03-24 12:11:53 PST
A fix in isn't looking like it will happen. Please renominate if this gets a patch on the trunk.
Comment 34 David Baron :dbaron: ⌚️UTC-10 2006-04-09 14:01:15 PDT
Created attachment 217776 [details] [diff] [review]
possible patch

This does what I suggested in comment 14.
Comment 35 Boris Zbarsky [:bz] (still a bit busy) 2006-04-09 14:16:30 PDT
Comment on attachment 217776 [details] [diff] [review]
possible patch

I'll try to review tonight, but this looks like a case where a macro (with PR_BEGIN/END_MACRO to handle scoping for the nsCOMArray) with the method&args for the call on each observer as the arg would be nice.
Comment 36 David Baron :dbaron: ⌚️UTC-10 2006-04-09 19:24:58 PDT
Comment on attachment 217776 [details] [diff] [review]
possible patch

I'll post such a patch after dinner.
Comment 37 David Baron :dbaron: ⌚️UTC-10 2006-04-09 22:09:02 PDT
Created attachment 217808 [details] [diff] [review]
possible patch
Comment 38 Boris Zbarsky [:bz] (still a bit busy) 2006-04-09 23:15:54 PDT
Comment on attachment 217808 [details] [diff] [review]
possible patch

Looks good.  Here's hoping the perf hit will not be noticeable.  ;)
Comment 39 Johnny Stenback (:jst, 2006-04-10 16:14:47 PDT
Comment on attachment 217808 [details] [diff] [review]
possible patch

Comment 40 David Baron :dbaron: ⌚️UTC-10 2006-04-11 16:44:51 PDT
Checked in to trunk.
Comment 41 David Baron :dbaron: ⌚️UTC-10 2006-04-11 21:16:58 PDT
So it looks like this did hurt Tdhtml and Txul a little.
Comment 42 Boris Zbarsky [:bz] (still a bit busy) 2006-04-12 08:39:18 PDT
Makes sense; those have tons of document observer notifications....

It might help to have fewer observers (eg have the presshell be notified by the binding manager).

Not sure what else would help, offhand.  :(
Comment 43 Daniel Veditz [:dveditz] 2006-04-19 12:22:54 PDT
Fixed per comment 40
Comment 44 Darin Fisher 2006-04-19 12:23:58 PDT
Can you guys keep a nsCOMArray around as a member variable that will generally be large enough to avoid a call to malloc?
Comment 45 Boris Zbarsky [:bz] (still a bit busy) 2006-04-19 14:56:30 PDT
Darin, at the moment notifications can actually nest in some cases.... Probably a bug in most of those, but it precludes using a member for any sort of temporary here.
Comment 46 Darin Fisher 2006-04-19 15:48:52 PDT
OK.  You could, I suppose, use a temp nsCOMArray when the member variable is not empty or if some boolean flag is set.
Comment 47 Daniel Veditz [:dveditz] 2006-04-21 14:24:32 PDT
Comment on attachment 217808 [details] [diff] [review]
possible patch

approved for 1.8.0 branch, a=dveditz for drivers
Comment 48 David Baron :dbaron: ⌚️UTC-10 2006-04-21 15:29:32 PDT
Checked in to MOZILLA_1_8_BRANCH and MOZILLA_1_8_0_BRANCH.

Marking appropriate fixed keywords, although we're really not sure if this fixes it, I don't think.
Comment 49 Jan Varga [:janv] 2006-05-25 14:54:07 PDT
Created attachment 223373 [details] [diff] [review]
a back port for Firefox 1.0
Comment 50 Adam Guthrie 2006-11-13 11:09:08 PST
This crash isn't showing up in the topcrash lists for 2.0 or Marking as VERIFIED and clearing blocking flags.

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