Closed Bug 242600 Opened 20 years ago Closed 19 years ago

"Edit" message filter after "Run Message Filter" causes Mozilla crash - Trunk TB11a1 [@ nsMsgFilter::GetFilterList]

Categories

(MailNews Core :: Filters, defect)

x86
All
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: World, Assigned: Bienvenu)

References

Details

(Keywords: crash, topcrash+)

Crash Data

Attachments

(3 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040504
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040504

"Edit" message filter after "Run Message Filter on this folder" caused Mozilla
crash.
Talkback-ID : TB38387X

Reproducible: Always
Steps to Reproduce:
1. Run Message Filter on a folder
2. View/Message Filter
3. "Edit" a enabled message filter

Actual Results:  
(case-1) Crash when "Edit" button of enabled filter is pressed
(case-2) Crash when "Edit" of a enabled filter after some successuful "Edit"
(case-3) "Edit" button hang (no filter edit window appears).
         Crash when clicked other position of Mail&News window.


Expected Results:  
Does not crash.

(1) Automatic message filter on automatic mail download does not cause problem.
(2) Edit of disabled filter does not cause problem.
(3) Filter condition itself and its result(matched mail or no matched mail) has
no relation to problem (comment on Talkback is not accurate).
(4) Filter name does not affect on problem.
    (Crash occurs on both english only filter name and Japanese filter name)
I am also seeing this in 1.8a1
Status: UNCONFIRMED → NEW
Ever confirmed: true
the stack from that talk back report:

JS_GetFrameFunctionObject 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsdbgapi.c,
line 791]
nsScriptSecurityManager::GetFramePrincipal 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/caps/src/nsScriptSecurityManager.cpp,
line 1834]
nsScriptSecurityManager::GetPrincipalAndFrame 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/caps/src/nsScriptSecurityManager.cpp,
line 1867]
nsScriptSecurityManager::GetSubjectPrincipal 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/caps/src/nsScriptSecurityManager.cpp,
line 1905]
nsScriptSecurityManager::GetSubjectPrincipal 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/caps/src/nsScriptSecurityManager.cpp,
line 1591]
nsScriptSecurityManager::SubjectPrincipalIsSystem 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/caps/src/nsScriptSecurityManager.cpp,
line 1625]
GlobalWindowImpl::CheckSecurityIsChromeCaller 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 2192]
GlobalWindowImpl::IsCallerChrome 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 2206]
GlobalWindowImpl::CanSetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 2943]
GlobalWindowImpl::Focus 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 2452]
nsWebShellWindow::HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/appshell/src/nsWebShellWindow.cpp,
line 609]
nsWindow::DispatchEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1071]
nsWindow::DispatchWindowEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1088]
nsWindow::DispatchFocus 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 5383]
nsWindow::ProcessMessage 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 4101]
nsWindow::WindowProc 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1350]
USER32.dll + 0x1ef0 (0x77de1ef0)
USER32.dll + 0x3869 (0x77de3869)
USER32.dll + 0x38ab (0x77de38ab)
ntdll.dll + 0x1ff57 (0x77f9ff57)
USER32.dll + 0x343f (0x77de343f)
USER32.dll + 0x1ef0 (0x77de1ef0)
USER32.dll + 0x3d1e (0x77de3d1e)
USER32.dll + 0x6e9b (0x77de6e9b)
nsWindow::WindowProc 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1361]
USER32.dll + 0x1ef0 (0x77de1ef0)
USER32.dll + 0x3869 (0x77de3869)
USER32.dll + 0x38ab (0x77de38ab)
ntdll.dll + 0x1ff57 (0x77f9ff57)
USER32.dll + 0x18ec (0x77de18ec)
PeekKeyAndIMEMessage 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsAppShell.cpp,
line 91]
nsAppShell::GetNativeEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsAppShell.cpp,
line 193]
nsXULWindow::ShowModal 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/appshell/src/nsXULWindow.cpp,
line 380]
nsContentTreeOwner::ShowAsModal 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/appshell/src/nsContentTreeOwner.cpp,
line 466]
nsWindowWatcher::OpenWindowJS 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp,
line 783]
GlobalWindowImpl::OpenInternal 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 4654]
GlobalWindowImpl::OpenDialog 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 3414]
XPTC_InvokeByIndex 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
XPCWrappedNative::CallMethod 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2029]
XPC_WN_CallMethod 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1288]
js_Invoke 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1283]
js_Interpret 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 3371]
js_Invoke 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1302]
js_InternalInvoke 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1379]
JS_CallFunctionValue 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsapi.c, line
3620]
nsJSContext::CallEventHandler 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/dom/src/base/nsJSEnvironment.cpp,
line 1280]
nsJSEventListener::HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/dom/src/events/nsJSEventListener.cpp,
line 180]
nsEventListenerManager::HandleEventSubType 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1461]
nsEventListenerManager::HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1538]
nsXULElement::HandleDOMEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2788]
PresShell::HandleDOMEventWithTarget 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6154]
nsButtonBoxFrame::MouseClicked 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsButtonBoxFrame.cpp,
line 178]
nsButtonBoxFrame::HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsButtonBoxFrame.cpp,
line 147]
PresShell::HandleEventInternal 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6124]
PresShell::HandleEventWithTarget 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6030]
nsEventStateManager::CheckForAndDispatchClick 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp,
line 2961]
nsEventStateManager::PostHandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp,
line 1968]
PresShell::HandleEventInternal 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6129]
PresShell::HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5999]
nsViewManager::HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 2233]
nsViewManager::DispatchEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 1977]
HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsView.cpp,
line 79]
nsWindow::DispatchEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1071]
nsWindow::DispatchWindowEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1088]
I could not recreate problem with 2004-05-27-09 trunk/Win-Me, POP3 server on
ADSL connection.

I guess that this bug is problem of filter editing while filter is running.
Reason why :
I reported Bug 242970 and Bug 242579, which started to occur on 2004-04-29 trunk
build, after this bug.
Bug 242579 caused Junk Purge hang or Junk move hang.
I guess "Run Message Filter" became running status, if problem of Bug 242579
occurred.  
These two bugs were resolved by 2004-05-21 trunk build.
(Unfortunately, the next day of 1.8a1 release)

>(Bug 242970)
> Bug 241708 has broken Mail&News when mail directry on different drive from one
for profile directry.
> (Server Settings/Local directory was changed to \\.\D:\pop3.server.name after
2004-04-29 build)
>(Bug 242579)
> Multiple mail copy/move hangs when drive of mail directry is different from
one for profile directry (bug 242970 also occurs).
> This causes hang of Junk move/Junk purge and multiple mail delete.


I think this bug is hard to recreate after 2004-05-21 builds, but I guess this
bug will occur if message filter is edited while long running filter, for
example, many many message filter rules & large amount of mails & slow server
connection(especially when IMAP).
Correction of my Comment #3

Crash still occurs on with 2004-05-27-09 trunk/Win-2K when edit message filter
after "Run Filter on Folder".
Sorry for spam and my hasty conclusion in previous comment.
I think I have the same problem here (using nightly 2004061409 on Windows XP). I
have run the selected filter, then edited it (added new filter option) and when
I clicked OK Mozilla crashes in  nsMsgFilter::GetFilterList 087b6cfc. Here is my
talkback report:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB96083G

Is this the same or should I file a new bug report?
I have also seen this on the current trunk on (17/10/04 ish) Linux however it's
got a few of my own mods in so I thought it wasn't the same. Will try and
confirm later this week.
Bug 268402 is IMAP case
Product: MailNews → Core
Attached file Linux stack trace (obsolete) —
Just got round to trying this on Linux, took a couple of attempts, but testing
with procedure of run now and then edit on the filter list dialog, on a POP
account caused the crash (stack trace attached).

Build ID: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20041213

I couldn't get IMAP to fail in this manner.

Also got to fail using Tools->Run Filters on Folder and then edit filter.
mark: please rebuild with symbols (or submit a talkback report)... we need to
know where in mailnews you crashed.
Attached file Linux back trace
Opps, sorry, here is one with symbols from ddd, hopefully its good enough.
Attachment #168655 - Attachment is obsolete: true
Change "assigned to:" since current assignee is "not reading bugmail".
David, something seems to be wrong in "Run Filter on folder", for example, clean
up failure in termination process, because problem of hang/crash on next mail
receive also occurs if "Run Filter on folder" is used.
Assignee: sspitzer → bienvenu
*** Bug 296090 has been marked as a duplicate of this bug. ***
this cropped up in recent Thunderbird 1.1a1 topcrash reports (Windows as well as
Linux), and I can reproduce the crash.

http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsMsgFilter::GetFilterList&vendor=MozillaOrg&product=ThunderbirdTrunk&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid

here's one of the stack traces. I'll attach the entire smart analysis data in a
bit as it's a bit longer.
Keywords: crash, topcrash+
OS: Windows 2000 → All
Summary: "Edit" message filter after "Run Message Filter" causes Mozilla crash → "Edit" message filter after "Run Message Filter" causes Mozilla crash - Trunk TB11a1 [@ nsMsgFilter::GetFilterList]
oops, here's the first trace:

Rank StackSignature               Count  
---------------------------------------
11   nsMsgFilter::GetFilterList   5
 
 	Source File :
/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/mailnews/base/search/src/nsMsgFilter.cpp
line : 516
 
====================================================================================================
     Count   Offset    Real Signature
[ 1   nsMsgFilter::GetFilterList() 863e5b85 - nsMsgFilter::GetFilterList() ]
 
     Crash date range: 09-JUN-05 to 09-JUN-05
     Min/Max Seconds since last crash: 5 - 5
     Min/Max Runtime: 5 - 5
 
     Count   Platform List 
     1   [Linux 2.6.10-5-686]      
 
     Count   Build Id List 
     1   2005053113
 
     No of Unique Users         1
 
 Stack trace(Frame) 

	 nsMsgFilter::GetFilterList()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/mailnews/base/search/src/nsMsgFilter.cpp
 line 516] 
	 XPTC_InvokeByIndex()  
	 XPCWrappedNative::CallMethod(XPCCallContext&  XPCWrappedNative::CallMode)()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp
 line 3028]
	 XPC_WN_GetterSetter()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp
 line 1899] 
	 js_Invoke()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/js/src/jsinterp.c
 line 1182] 
	 js_InternalInvoke()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/js/src/jsinterp.c
 line 1279] 
	 js_InternalGetOrSet()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/js/src/jsinterp.c
 line 1322] 
	 js_GetProperty()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/js/src/jsobj.c
 line 2815] 
	 js_Interpret()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/js/src/jsinterp.c
 line 3299] 
	 js_Invoke()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/js/src/jsinterp.c
 line 1202] 
	 js_InternalInvoke()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/js/src/jsinterp.c
 line 1279] 
	 JS_CallFunctionValue()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/js/src/jsapi.c
 line 3865] 
	 nsJSContext::CallEventHandler()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp
 line 1385] 
	 nsJSEventListener::HandleEvent()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/dom/src/events/nsJSEventListener.cpp
 line 177] 
	 nsEventListenerManager::HandleEventSubType()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/content/events/src/nsEventListenerManager.cpp
 line 848] 
	 nsEventListenerManager::HandleEvent()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/content/events/src/nsEventListenerManager.cpp
 line 1667] 
	 nsGlobalWindow::HandleDOMEvent()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp
 line 914] 
	 DocumentViewerImpl::LoadComplete()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/layout/base/nsDocumentViewer.cpp
 line 842] 
	 nsDocShell::EndPageLoad()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/docshell/base/nsDocShell.cpp
 line 4623] 
	 nsWebShell::EndPageLoad()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/docshell/base/nsWebShell.cpp
 line 496] 
	 nsDocShell::OnStateChange()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/docshell/base/nsDocShell.cpp
 line 200] 
	 nsDocLoader::FireOnStateChange()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/uriloader/base/nsDocLoader.cpp
 line 848] 
	 nsDocLoader::doStopDocumentLoad()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/uriloader/base/nsDocLoader.cpp
 line 827] 
	 nsDocLoader::DocLoaderIsEmpty()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/uriloader/base/nsDocLoader.cpp
 line 729] 
	 nsDocLoader::OnStopRequest()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/uriloader/base/nsDocLoader.cpp
 line 650] 
	 nsLoadGroup::RemoveRequest()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/netwerk/base/src/nsLoadGroup.cpp
 line 848] 
	 nsCachedChromeChannel::HandleLoadEvent()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/chrome/src/nsChromeProtocolHandler.cpp
 line 713] 
	 PL_HandleEvent()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/xpcom/threads/plevent.c
 line 698] 
	 PL_ProcessPendingEvents()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/xpcom/threads/plevent.c
 line 633] 
	 nsEventQueueImpl::ProcessPendingEvents()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/xpcom/threads/nsEventQueue.cpp
 line 421] 
	 event_processor_callback()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/widget/src/gtk2/nsAppShell.cpp
 line 71] 
	 libglib-2.0.so.0 + 0x45eb1 (0xb7afdeb1)  
	 libglib-2.0.so.0 + 0x22d0f (0xb7adad0f)  
	 libglib-2.0.so.0 + 0x23cb5 (0xb7adbcb5)  
	 libglib-2.0.so.0 + 0x23fd7 (0xb7adbfd7)  
	 libglib-2.0.so.0 + 0x2421e (0xb7adc21e)  
	 nsAppShell::DispatchNativeEvent()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/widget/src/gtk2/nsAppShell.cpp
 line 276] 
	 nsXULWindow::ShowModal()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/xpfe/appshell/src/nsXULWindow.cpp
 line 848] 
	 nsContentTreeOwner::ShowAsModal()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/xpfe/appshell/src/nsContentTreeOwner.cpp
 line 428] 
	 nsWindowWatcher::OpenWindowJS()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp
 line 576] 
	 nsGlobalWindow::OpenInternal()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp
 line 848] 
	 nsGlobalWindow::OpenDialog()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp
 line 3430] 
	 XPTC_InvokeByIndex()  
	 XPCWrappedNative::CallMethod(XPCCallContext&  XPCWrappedNative::CallMode)()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp
 line 3028]
	 XPC_WN_CallMethod()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp
 line 1348] 
	 js_Invoke()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/js/src/jsinterp.c
 line 1182] 
	 js_Interpret()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/js/src/jsinterp.c
 line 3472] 
	 js_Invoke()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/js/src/jsinterp.c
 line 1202] 
	 js_InternalInvoke()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/js/src/jsinterp.c
 line 1279] 
	 JS_CallFunctionValue()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/js/src/jsapi.c
 line 3865] 
	 nsJSContext::CallEventHandler()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp
 line 1385] 
	 nsJSEventListener::HandleEvent()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/dom/src/events/nsJSEventListener.cpp
 line 177] 
	 nsEventListenerManager::HandleEventSubType()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/content/events/src/nsEventListenerManager.cpp
 line 848] 
	 nsEventListenerManager::HandleEvent()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/content/events/src/nsEventListenerManager.cpp
 line 1667] 
	 nsXULElement::HandleDOMEvent()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/content/xul/content/src/nsXULElement.cpp
 line 2194] 
	 PresShell::HandleDOMEventWithTarget()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/layout/base/nsPresShell.cpp
 line 6418] 
	 nsButtonBoxFrame::DoMouseClick()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/layout/xul/base/src/nsButtonBoxFrame.cpp
 line 62] 
	 nsButtonBoxFrame::HandleEvent()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/layout/xul/base/src/nsButtonBoxFrame.cpp
 line 145] 
	 PresShell::HandleEventInternal()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/layout/base/nsPresShell.cpp
 line 69] 
	 PresShell::HandleEventWithTarget()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/layout/base/nsPresShell.cpp
 line 6229] 
	 nsEventStateManager::CheckForAndDispatchClick()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/content/events/src/nsEventStateManager.cpp
 line 2924] 
	 nsEventStateManager::PostHandleEvent()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/content/events/src/nsEventStateManager.cpp
 line 1954] 
	 PresShell::HandleEventInternal()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/layout/base/nsPresShell.cpp
 line 848] 
	 PresShell::HandleEvent()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/layout/base/nsPresShell.cpp
 line 6166] 
	 nsViewManager::HandleEvent()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/view/src/nsViewManager.cpp
 line 848] 
	 nsViewManager::DispatchEvent()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/view/src/nsViewManager.cpp
 line 100] 
	 HandleEvent()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/view/src/nsView.cpp
 line 174] 
	 nsCommonWidget::DispatchEvent()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/widget/src/gtk2/nsCommonWidget.cpp
 line 219] 
	 nsWindow::OnButtonReleaseEvent()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/widget/src/gtk2/nsWindow.cpp
 line 1582] 
	 button_release_event_cb()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/widget/src/gtk2/nsWindow.cpp
 line 3702] 
	 libgtk-x11-2.0.so.0 + 0x117bca (0xb7d79bca)  
	 libgobject-2.0.so.0 + 0x8351 (0xb7b43351)  
	 libgobject-2.0.so.0 + 0x187e2 (0xb7b537e2)  
	 libgobject-2.0.so.0 + 0x176ef (0xb7b526ef)  
	 libgobject-2.0.so.0 + 0x17b75 (0xb7b52b75)  
	 libgtk-x11-2.0.so.0 + 0x1f9a11 (0xb7e5ba11)  
	 libgtk-x11-2.0.so.0 + 0x1167de (0xb7d787de)  
	 libgtk-x11-2.0.so.0 + 0x1157bb (0xb7d777bb)  
	 libgdk-x11-2.0.so.0 + 0x3cb0b (0xb7c23b0b)  
	 libglib-2.0.so.0 + 0x22d0f (0xb7adad0f)  
	 libglib-2.0.so.0 + 0x23cb5 (0xb7adbcb5)  
	 libglib-2.0.so.0 + 0x23fd7 (0xb7adbfd7)  
	 libglib-2.0.so.0 + 0x2451e (0xb7adc51e)  
	 libgtk-x11-2.0.so.0 + 0x11510f (0xb7d7710f)  
	 nsAppShell::Run()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/widget/src/gtk2/nsAppShell.cpp
 line 141] 
	 nsAppStartup::Run()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/toolkit/components/startup/src/nsAppStartup.cpp
 line 145] 
	 XRE_main()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/toolkit/xre/nsAppRunner.cpp
 line 830] 
	 main()
[/builds/tinderbox/thunderbird-trunk/Linux_2.4.18-14_Depend/mozilla/mail/app/nsMailApp.cpp
 line 63] 
	 libc.so.6 + 0x158c8 (0xb75248c8)
I know the traces differ, but could this be related to bug 296992 since both of
these involve editing or running mail filters?
If I repeat these steps a few times, I crash here:

JS_GetFrameFunctionObject(JSContext * 0x045b57c0, JSStackFrame * 0x0012a0e4)
line 805 + 24 bytes
nsScriptSecurityManager::GetFramePrincipal(JSContext * 0x045b57c0, JSStackFrame
* 0x0012a0e4, unsigned int * 0x0012b788) line 1900 + 14 bytes
nsScriptSecurityManager::GetPrincipalAndFrame(JSContext * 0x045b57c0,
JSStackFrame * * 0x0012b760, unsigned int * 0x0012b788) line 1939 + 17 bytes
nsScriptSecurityManager::GetSubjectPrincipal(JSContext * 0x045b57c0, unsigned
int * 0x0012b788) line 1981 + 17 bytes
nsScriptSecurityManager::doGetSubjectPrincipal(unsigned int * 0x0012b788) line
1628 + 13 bytes
nsScriptSecurityManager::GetSubjectPrincipal(nsScriptSecurityManager * const
0x00bbb818, nsIPrincipal * * 0x0012b7b4) line 1612 + 12 bytes
nsScriptSecurityManager::SubjectPrincipalIsSystem(nsScriptSecurityManager *
const 0x00bbb818, int * 0x0012b7c8) line 1662 + 36 bytes
nsContentUtils::IsCallerChrome() line 915 + 21 bytes
PresShell::HandleEventInternal(nsEvent * 0x0012bbc0, nsIView * 0x040f7be0,
unsigned int 0x00000001, nsEventStatus * 0x0012b9bc) line 6292 + 5 bytes

I'll try this with Purify.
after rebuilding, I no longer crash with these steps - can we check if this
contines to show up in talback builds from today or later? This may have been fixed.
Bug 266905 is another crash after "Run Filter on folder"(crash when following
mail download).
David, will your patch or modification resolve Bug 266905 too? 
I don't have a patch - I just can't recreate the crash. It might be the case
that timeless's patch fixed this problem, though I can't explain why it would.
*** Bug 295220 has been marked as a duplicate of this bug. ***
Mozilla Suite nightly/latest-trunk(2005061306 ZIP build/Win-32) still crashes
when "Edit Message Filter" after "Run Filters on Folder".
(1) Start Mozilla Browser and Mozilla Mail&News using my current profile.
    => POP3 servers access on start-up but no mail is downloded
       because no new mail.
(2) Tools/"Run Filters on Folder" on "Inbox" folder.
    => No mail is moved because no matching mail.
(3) Tools/"Message Filters"
    (3-1) "Edit" an enabled filter, then save("OK") with no modification
          => No problem
    (3-2) "Edit" another enabled filter
          => Crash. Talkback was not kicked.
I tried above steps three times and Mozilla crashed in any attempt of step (3-2).

Followings are all checkins on mozilla/mailnews/base/search/src/nsMsgFilter.cpp
since 2005/01/01.
> 2005-06-10 15:15 1.101 Bug 266905 Mozilla crash or hang on POP3 mail download,
>                        if "Run Filter on Folder" is executed
> 2005-06-01 11:13 1.100 support for filters that reply/forward messages
> 2005-04-20 07:45 1.99  Bug 262184: support Copy as a filter action
                         (as in tbird 1.0). Finally landing on the trunk
Does it matter that not all filters work, and they continue to not work
consistently? Could it be anything with the filter name or contents?
(In reply to comment #22)
> Could it be anything with the filter name or contents?

No relation to filter name nor filter rules.
Followings are all of filters edited in my previous tests.

  name="Junk-#angel-talks.com" 
  enabled="yes"
  type="1"
  action="Move to folder"
  actionValue="mailbox://japan.com@dion.00.japan.com/Trash"
  action="JunkScore"
  actionValue="100"
  condition="OR (subject,contains,@angel-talks.com)"

  name="Junk-XmailNNNNjp@yahoo.co.jp"
  enabled="yes"
  type="1"
  action="Move to folder"
  actionValue="mailbox://japan.com@dion.00.japan.com/Trash"
  action="JunkScore"
  actionValue="100"
  condition="AND (from,contains,mail) AND (from,contains,jp@yahoo.co.jp)
             AND (age in days,is less than,-1)"

  name="Junk-001"
  enabled="yes"
  type="1"
  action="Move to folder"
  actionValue="mailbox://japan.com@dion.00.japan.com/Junk"
  action="JunkScore"
  actionValue="100"
  condition="AND (to,is,ctcnet@edc.org) AND (from,is,m-wada@japan.com)
             AND (subject,begins with,Returned due to virus; was:)"

  name="Bugzilla"
  enabled="yes"
  type="1"
  action="Move to folder"
  actionValue="mailbox://japan.com@dion.00.japan.com/
                         01-%E3%82%82%E3%81%98%E3%82%89%E7%B5%84/Bugzilla"
  condition="AND (from,contains,bugzilla-daemon@mozilla.org)"


> Does it matter that not all filters work, and they continue to not work
> consistently? 

I don't know.
But all filters are filters which are used every day and they have no problem on
automatic filter when automatic mail download on start-up and automatic mail
download by interval-timer.
And filters have no problem when "Run Filters on Folder" too. 
I know what the problem is and I'm working on a fix.  More info when I have a
fix. But the problem  has been around for several years, so I think these are
all dups of each other, even if the problem isn't always easily recreatable in
any given build.
(In reply to comment #23)
> (In reply to comment #22)
> > Could it be anything with the filter name or contents?
> 
> No relation to filter name nor filter rules.
> Followings are all of filters edited in my previous tests.
> 
>   name="Junk-#angel-talks.com" 
>   enabled="yes"
>   type="1"
>   action="Move to folder"
>   actionValue="mailbox://japan.com@dion.00.japan.com/Trash"
>   action="JunkScore"
>   actionValue="100"
>   condition="OR (subject,contains,@angel-talks.com)"
> 
>   name="Junk-XmailNNNNjp@yahoo.co.jp"
>   enabled="yes"
>   type="1"
>   action="Move to folder"
>   actionValue="mailbox://japan.com@dion.00.japan.com/Trash"
>   action="JunkScore"
>   actionValue="100"
>   condition="AND (from,contains,mail) AND (from,contains,jp@yahoo.co.jp)
>              AND (age in days,is less than,-1)"
> 
>   name="Junk-001"
>   enabled="yes"
>   type="1"
>   action="Move to folder"
>   actionValue="mailbox://japan.com@dion.00.japan.com/Junk"
>   action="JunkScore"
>   actionValue="100"
>   condition="AND (to,is,ctcnet@edc.org) AND (from,is,m-wada@japan.com)
>              AND (subject,begins with,Returned due to virus; was:)"
> 
>   name="Bugzilla"
>   enabled="yes"
>   type="1"
>   action="Move to folder"
>   actionValue="mailbox://japan.com@dion.00.japan.com/
>                          01-%E3%82%82%E3%81%98%E3%82%89%E7%B5%84/Bugzilla"
>   condition="AND (from,contains,bugzilla-daemon@mozilla.org)"
> 
> 
> > Does it matter that not all filters work, and they continue to not work
> > consistently? 
> 
> I don't know.
> But all filters are filters which are used every day and they have no problem on
> automatic filter when automatic mail download on start-up and automatic mail
> download by interval-timer.
> And filters have no problem when "Run Filters on Folder" too. 



Where did you get this filter list? I am consistently having one not work in
addition to these other problems and am wondering if there is any relationship.
(In reply to comment #25)
> Where did you get this filter list?
Message filter is kept in msgFilterRules.dat under Mail directry.
See "Installation Instructions"/"Files Created or Used" section of Mozilla's
release notes for details or other important files.
( http://www.mozilla.org/releases/mozilla1.8b1/installation.html#files )
Attached patch proposed fixSplinter Review
the problem was that we were inserting filters into temporary lists, and
setting the (unref-counted) filterList pointer to the temporary list.
Eventually, the temporary list would get garbage collected, and become invalid.
Then, if you bring up edit filters, the filter list would be garbage. We should
probably use a weak ref here, but this fix will still be needed, because we
don't want have the filters point to the temporary filter list in any case.
Ideally, we'd clone the filters too, but that's a big change at this time.
Attachment #186159 - Flags: superreview?(mscott)
I take back what I said about the problem having been around for a while. It was
introduced at the very start of 1.1, when I made insertIntoFilterList set the
filter list on the inserted filter.
*** Bug 295220 has been marked as a duplicate of this bug. ***
Attachment #186159 - Flags: superreview?(mscott) → superreview+
Attachment #186159 - Flags: approval-aviary1.1a2?
Attachment #186159 - Flags: approval-aviary1.1a2? → approval-aviary1.1a2+
fix checked in - please try tomorrow's trunk build.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
*** Bug 296992 has been marked as a duplicate of this bug. ***
(In reply to comment #27)
> ... We should
> probably use a weak ref here, but this fix will still be needed, because we
> don't want have the filters point to the temporary filter list in any case.
...
> Ideally, we'd clone the filters too, but that's a big change at this time.


Should there be a new bug opened on that for the future or is there already? If
not, now is a good time before it gets forgotten. If so, could you list the bug
number here?



(In reply to comment #28)
> I take back what I said about the problem having been around for a while. It was
> introduced at the very start of 1.1, when I made insertIntoFilterList set the
> filter list on the inserted filter.

Well, this bug has been around since 2004-05-04, if that is a while.

When did this get checked in? I just had another crash with a late
afternoon/early evening "hourly" build. version 1.0+ (20050614)
With Mozilla Suite latest-trunk 2005061506(ZIP build,Win-2K),
I couldn't re-produce crash of this bug any more by initial test procedure nor
by test procedure of comment #21.
I can say this bug is now WORKSFORME, although I can not say this bug has been
FIXED & VERIFIED by no crash in my tests. 

I can use "Run Filters on Folder" without fear again from today!
Thanks a lot, David.
(This is a new evidence of my theory, "If David joins, critical mail&news bug
for me is resolved soon". ;-)
Seems OK so far, but I'd rather KNOW that it was fixed before trusting it again.
FWIW, the problem filter is now working again as well.
Blocks: 266905
Product: Core → MailNews Core
Crash Signature: [@ nsMsgFilter::GetFilterList]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: