43361 - Editing filters causes a crash

Status: VERIFIED WORKSFORME

(MailNews Core :: Filters, defect, P3)

Description

[marina]

**** observed with 2000-06-21-08 build ****
Steps to reproduce:
- open Messenger;
- go Edit|Message filters...;
- select previuosly created filter,click Edit;
- don't change anything, just OK the dlgbox to close it;
//note: seamonkey crashes (it doesn't happen if ctually change filter name)

Comment 1

[lchiang]

Marina - can you include a talkback report stack trace?

Comment 2

[laurel]

Incident 12839712:
 Call Stack:    (Signature = nsXULTreeOuterGroupFrame::EnsureRowIsVisible
ce2c7a1b) 
     
  nsXULTreeOuterGroupFrame::EnsureRowIsVisible 
                                              
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsXULTreeOuterGroupFrame.cpp,
line 761]
     
  nsXULTreeFrame::EnsureRowIsVisible 
                                              
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsXULTreeFrame.cpp, line 117]
     
  nsTreeBoxObject::EnsureIndexIsVisible 
                                              
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsTreeBoxObject.cpp, line 117]
     
  XPTC_InvokeByIndex 
                                              
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp,
line 139]
     
  nsXPCWrappedNativeClass::CallWrappedMethod 
                                              
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativeclass.cpp,
line 915]
     
  WrappedNative_CallMethod 
                                              
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp,
line 195]
     
  js_Invoke 
                                              
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 687]
     
  js_Interpret 
                                              
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2491]
     
  js_Invoke 
                                              
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 703]
     
  js_InternalInvoke 
                                              
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 776]
     
  JS_CallFunctionValue 
                                              
[d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 2803]
     
  nsJSContext::CallEventHandler 
                                              
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 790]
     
  nsJSEventListener::HandleEvent 
                                              
[d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 155]
     
  nsEventListenerManager::HandleEventSubType 
                                              
[d:\builds\seamonkey\mozilla\layout\events\src\nsEventListenerManager.cpp, line
755]
     
  nsEventListenerManager::HandleEvent 
                                              
[d:\builds\seamonkey\mozilla\layout\events\src\nsEventListenerManager.cpp, line
904]
     
  nsXULElement::HandleDOMEvent 
                                              
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULElement.cpp, line 3430]
     
  PresShell::HandleEventInternal 
                                              
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 3731]
     
  PresShell::HandleEventWithTarget 
                                              
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 3711]
     
  nsEventStateManager::CheckForAndDispatchClick
                                              
[d:\builds\seamonkey\mozilla\layout\events\src\nsEventStateManager.cpp, line
1763]
     
  nsEventStateManager::PostHandleEvent 
                                              
[d:\builds\seamonkey\mozilla\layout\events\src\nsEventStateManager.cpp, line
872]
     
  PresShell::HandleEventInternal 
                                              
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 3752]
     
  PresShell::HandleEvent 
                                              
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 3666]
     
  nsView::HandleEvent 
                                              
[d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 782]
     
  nsViewManager2::DispatchEvent 
                                              
[d:\builds\seamonkey\mozilla\view\src\nsViewManager2.cpp, line 1387]
     
  HandleEvent 
                                              
[d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 69]
     
  nsWindow::DispatchEvent 
                                              
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 564]
     
  nsWindow::DispatchWindowEvent 
                                              
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 581]
     
  nsWindow::DispatchMouseEvent 
                                              
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3681]
     
  ChildWindow::DispatchMouseEvent 
                                              
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3886]
     
  nsWindow::ProcessMessage 
                                              
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2801]
     
  nsWindow::WindowProc 
                                              
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 830]
     
  USER32.dll + 0x1820 (0x77e71820) 

Comment 3

[Alec Flett]

reassign to bryner, mr. EnsureRowIsVisible himself.
This is fallout from the tree landing.

Comment 4

[leger]

Adding crash keyword

Comment 5

[Alec Flett]

*** Bug 43454 has been marked as a duplicate of this bug. ***

Comment 6

[Jay Patel [:jay]]

Putting on [nsbeta2+][dogfood-] radar.  Does not need a fix ASAP for daily work, 
but we should fix this for beta2. 

Comment 7

[R.K.Aa.]

*** Bug 43934 has been marked as a duplicate of this bug. ***

Comment 8

[jlarsen]

Bug 43934 Adding a different way to crash, thought I'd add note in here.
If you create a New filter, when you type a name it crashes. Reopen 43934, if 
you think this is a seperate bug.

Comment 9

[laurel]

The bug about New filters problem is actually covered under bug #43934, which
was fixed just yesterday (to be in 6.27 builds).

Comment 10

[laurel]

My last comments should read bug #43474 as the New filter crash. 

Comment 11

[laurel]

This problem no longer occurs using 2000-06-27-09 m17 commercial build, linux
rh6.0, NT 4.0 and Mac OS 9.0.

Fixed along with 43474?
Marking worksforme

Comment 12

[marina]

isn't the resolution verified as fixed more appropriate here?

Comment 13

[laurel]

Sorry I'm not as fast at marking verified as you'd like, Marina. It is a two
step bug process.   

Comment 14

[marina]

it wasn't a speed of verification (i am not fast), it was a resolution "fixed" 
oppose to "worksforme"

Comment 15

[laurel]

Either fixed or worksforme would work. I happened to choose worksforme because
no one had marked it fixed and it now works for me.

Comment 16

[Mike Pinkerton (not reading bugmail)]

bryner and I saw this crash in various places, clicking Cancel in the edit filter 
dialog, and clicking "edit" in the main filter dialog.

we get this assertion when it crashes:
assertion failure: root_points_to_gcArenaPool at mozilla/js/src/jsgc.c:785

what do we want to do about this? should we just leave it resolved until we can 
get a better testcase? both bryner and I feel icky about leaving this 
"WORKSFORME".

adding shaver and brendan, just because i can.

Comment 17

[Brendan Eich [:brendan]]

Sounds like a dup of bug 43466 -- mark it dup if you agree.

/be

Comment 18

[Brian Ryner (not reading)]

Well, I'm not sure.  Looking at the original stack trace of this bug, it was a
crash in nsXULTreeOuterGroupFrame.cpp, line 761.  This line is currently
commented out.  So, what should we do with this bug?

Comment 19

[laurel]

If you need to reopen it, please do so.  However, I cannot reproduce a crash
with jun28 commmerical build (linux, mac , having trouble with NT and today's
build) in the ways pinkerton mentioned. I couldn't yesterday, either.

So if there's more detail to the crash scenario(s), please provide details.

Comment 20

[Brendan Eich [:brendan]]

Sorry, the tree crash is not a dup of 43466.  The crash in debug-built jsgc.c, 
asserting root_points_to_gcArenaPool after closing a dialog box has to be a dup 
of 43466.  If the original tree crash is gone, then you can leave this verified 
worksforme, I say.

/be

Comment 21

[Brian Ryner (not reading)]

Sounds good to me.

Comment 22

[Alec Flett]

the original crash had nothing to do with the GC arena pool assert.

Laurel, to make sure you're seeing the original crash, not the GC assert crash, 
make sure that mail filters are the first dialog you open (i.e. start with a 
profile that already has accounts, etc, so you aren't opening the account wizard 
or anything)