383423 - Thunderbird crashes when a saved search is defined for an IMAP account [@ nsMsgDatabase::FindInCache] and there is a folder whose name contains "|"

Status: RESOLVED WORKSFORME

(MailNews Core :: Database, defect)

Description

[David Sitsky]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: 2.0.0.0

I used to be able to create saved searches in Thunderbird for my IMAP account, but now it always crashes once I click on the final OK button.  I don't know what has changed to triggered this.  Mail is working fine otherwise.  I was initially searching for messages with a specific tag, but in fact the crash happens for any search condition, for example, subject contains x.

I can actually perform the searches themselves fine.  The problem occurs once I want it to become a saved search.




Reproducible: Always




Talkback crash IDs: TB32876721Q, TB32872201H, TB32871245E

Its quite possible that these are also for the same issue (happened yesterday): TB32844093Y, TB32843857X, TB32843827E.

Comment 1

[timeless]

Incident ID: 32876721
Stack Signature	nsMsgDatabase::FindInCache 33dd0f1a
Product ID	Thunderbird2
Build ID	2007032620
Trigger Time	2007-06-05 22:26:43.0
Platform	Win32
Operating System	Windows NT 6.0 build 6000
Module	thunderbird.exe + (00513982)
URL visited	
User Comments	
Since Last Crash	15899 sec
Total Uptime	2115687 sec
Trigger Reason	Access violation
Source File, Line No.	e:/builds/tinderbox/Tb-Mozilla1.8-Release/WINNT_5.0_Depend/mozilla/mailnews/db/msgdb/src/nsMsgDatabase.cpp, line 830
Stack Trace 	
nsMsgDatabase::FindInCache  [mozilla/mailnews/db/msgdb/src/nsMsgDatabase.cpp, line 830]
nsMsgDBService::RegisterPendingListener  [mozilla/mailnews/db/msgdb/src/nsMsgDatabase.cpp, line 216]
nsMsgAccountManager::AddVFListenersForVF  [mozilla/mailnews/base/src/nsMsgAccountManager.cpp, line 3119]
nsMsgAccountManager::OnItemAdded  [mozilla/mailnews/base/src/nsMsgAccountManager.cpp, line 3147]
nsMsgMailSession::OnItemAdded  [mozilla/mailnews/base/src/nsMsgMailSession.cpp, line 227]
nsMsgDBFolder::NotifyItemAdded  [mozilla/mailnews/base/util/nsMsgDBFolder.cpp, line 4735]
XPTC_InvokeByIndex  [mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp, line 102]
XPCWrappedNative::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2169]
XPC_WN_CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1455]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1396]
js_Interpret  [mozilla/js/src/jsinterp.c, line 3975]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1415]
nsXPCWrappedJSClass::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1415]
nsXPCWrappedJS::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 468]
SharedStub  [mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 147]
nsEventListenerManager::HandleEventSubType  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1655]
nsEventListenerManager::HandleEvent  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1762]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2230]
PresShell::HandleDOMEventWithTarget  [mozilla/layout/base/nsPresShell.cpp, line 6524]
nsButtonBoxFrame::DoMouseClick  [mozilla/layout/xul/base/src/nsButtonBoxFrame.cpp, line 182]
nsButtonBoxFrame::MouseClicked  [mozilla/layout/xul/base/src/nsButtonBoxFrame.h, line 61]
PresShell::HandleEventInternal  [mozilla/layout/base/nsPresShell.cpp, line 6466]
PresShell::HandleEventWithTarget  [mozilla/layout/base/nsPresShell.cpp, line 6323]
nsEventStateManager::CheckForAndDispatchClick  [mozilla/content/events/src/nsEventStateManager.cpp, line 3207]
nsEventStateManager::PostHandleEvent  [mozilla/content/events/src/nsEventStateManager.cpp, line 2170]
PresShell::HandleEventInternal  [mozilla/layout/base/nsPresShell.cpp, line 6497]
PresShell::HandleEvent  [mozilla/layout/base/nsPresShell.cpp, line 6261]
nsViewManager::HandleEvent  [mozilla/view/src/nsViewManager.cpp, line 2559]
nsViewManager::DispatchEvent  [mozilla/view/src/nsViewManager.cpp, line 2246]
HandleEvent  [mozilla/view/src/nsView.cpp, line 174]
nsWindow::DispatchEvent  [mozilla/widget/src/windows/nsWindow.cpp, line 1389]
nsWindow::DispatchMouseEvent  [mozilla/widget/src/windows/nsWindow.cpp, line 6442]
ChildWindow::DispatchMouseEvent  [mozilla/widget/src/windows/nsWindow.cpp, line 6689]
nsWindow::WindowProc  [mozilla/widget/src/windows/nsWindow.cpp, line 1577]
USER32.dll + 0x187af (0x75fe87af)
USER32.dll + 0x18936 (0x75fe8936)
USER32.dll + 0x18a7d (0x75fe8a7d)
USER32.dll + 0x18ad0 (0x75fe8ad0)
nsAppShell::DispatchNativeEvent  [mozilla/widget/src/windows/nsAppShell.cpp, line 221]
nsContentTreeOwner::ShowAsModal  [mozilla/xpfe/appshell/src/nsContentTreeOwner.cpp, line 478]
nsWindowWatcher::OpenWindowJS  [mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp, line 540]
nsGlobalWindow::OpenInternal  [mozilla/dom/src/base/nsGlobalWindow.cpp, line 6156]
nsGlobalWindow::OpenDialog  [mozilla/dom/src/base/nsGlobalWindow.cpp, line 4473]
XPTC_InvokeByIndex  [mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp, line 102]
XPCWrappedNative::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2169]
XPC_WN_CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1455]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1396]
js_Interpret  [mozilla/js/src/jsinterp.c, line 3975]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1415]
nsXPCWrappedJSClass::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1415]
nsXPCWrappedJS::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 468]
SharedStub  [mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 147]
XPTC_InvokeByIndex  [mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp, line 102]
XPCWrappedNative::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2169]
XPC_WN_CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1455]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1396]
js_Interpret  [mozilla/js/src/jsinterp.c, line 3975]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1415]
js_InternalInvoke  [mozilla/js/src/jsinterp.c, line 1490]
JS_CallFunctionValue  [mozilla/js/src/jsapi.c, line 4356]
nsJSContext::CallEventHandler  [mozilla/dom/src/base/nsJSEnvironment.cpp, line 1493]
nsJSEventListener::HandleEvent  [mozilla/dom/src/events/nsJSEventListener.cpp, line 195]
nsEventListenerManager::HandleEventSubType  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1655]
nsEventListenerManager::HandleEvent  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1762]

Comment 2

[David :Bienvenu]

very strange. Are you just searching your imap INBOX?

Comment 3

[David Sitsky]

Actually no - I have the structure:

- Inbox
- Drafts
- Sent
- Junk
- Trash
- @GTD
  - Projects
    - Name of project 1
    - Name of project 2
    - ...
  - Tickler file
    - More sub folders
- More folders below

I am restricting the search over all sub-folders in Projects.  I am connected to a UW IMAP server.

This was all working nicely, but something has changed which is causing the crash to occur everytime now.

Comment 4

[David Sitsky]

Incidentally, I have connected to the same IMAP account from a different computer, this one running Windows XP, and exactly the same error occurs.  The original machine is running Vista, so it appears there is something special about my IMAP account which causes this issue.

I am happy to enable any debugging as required.

Comment 5

[David :Bienvenu]

Do you have any existing saved searches over the same scope that work? I'm reasonably sure that we're having a problem parsing the search scope we've generated into folders, and we're getting a null folder, and crashing. We use '|' as the delimiter between folder uri's. An imap protocol log http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

might help me figure out what it is about your folder structure that's causing the problem.

Comment 6

[David Sitsky]

Ah ha - found the problem.  I had a folder with the name of "Someday | Maybe".  As soon as I removed the '|' character from the folder name, everything worked fine.

As far as I know, there is no reason why users can't use the '|' character within folder names - so perhaps this needs to be handled in a special way.

Anyway - glad there is a workaround at least.

Comment 7

[David :Bienvenu]

I figured it was something like that. I can't remember why I used '|' as the uri delimiter - maybe I thought it wasn't a valid character in uri's. We will have to escape it and unescape, it seems.

Comment 8

[Magnus Melin [:mkmelin]]

Doesn't seem to crash on linux/trunk. After restart the pipe is shown as %7C, but still working.

Comment 9

[Wayne Mery (:wsmwk)]

Sitsky, does this also work for you with trunk build? 
 ftp://ftp.mozilla.org/pub/thunderbird/nightly/3.0a1-candidates/build1/
 (install to it's own directory)

Comment 10

[David Sitsky]

I downloaded it, and I am afraid I can't create any IMAP folders (silently fails).  2.0.0.14 works fine for ordinary folder names.

Comment 11

[David Sitsky]

I connect to the IMAP server using TLS, and the certificate has expired.  I am getting a number of dialog boxes with this error - so I don't know if this is why I can't create folders with version 3.  With version 2, I get that warning on startup but then it never nags me afterwards, and everything seems to work fine from that point on.

I'm trying to get the sysadmin to update the certificate in the mean time.

Comment 12

[juan becerra [:juanb]]

Encountered a crash TB47539373H consistently today while trying to see a saved search in an IMAP account while testing TB20016build1. I search for a message, saved the search. Moved it so that it was a subfolder of the Inbox. When I click on the saved search it crashes.

Comment 13

[Magnus Melin [:mkmelin]]

juan: your crash is actually bug 369918.

Comment 15

[Wayne Mery (:wsmwk)]

can anyone reproduce this with a recent build/version?

I can't reproduce With current trunk on vista, in local or imap account

Comment 16

[Wayne Mery (:wsmwk)]

What's on crash-stats might not be this same crash, and is rare enough that it's not worth tracking

closing WFM based on comment 15