292041 - Crash on some drag and drop of mail from current messages list into IMAP folders [@ nsMsgDatabase::GetTableCreateIfMissing]

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Michael Witbrock]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.6) Gecko/20050321 Firefox/1.0.2
Build Identifier: Thunderbird 20040526  (and the last two months of builds)

After using thunderbird for some time (can be as few as ten minutes), dragging a
mail message into an IMAP folder will cause a crash. After restarting, dragging
the same message into the same folder will not cause a crash. 
This crash can also occur when dragging and dropping more than one message at a
time (i.e. several selected) and, I THINK, when dragging between folders.

Note: I have hundreds of IMAP folders, several nested deeply

Reproducible: Sometimes

Steps to Reproduce:
1. Use thunderbird for some time
2. drag and drop messgages into folders
3.

Actual Results:  
Crash (and quality feedback agent)

Expected Results:  
Completed the drag and drop operation correctly. 

This happens several times per day (say, once per hour)

Comment 1

[David :Bienvenu]

can you post some talkback incident ids to this bug?

Comment 2

[Michael Witbrock]

I will as soon as I work out how to access the ids, or get another crash.

Comment 3

[Michael Witbrock]

Here you go:

TB5396588Q, TB5388150M, TB5387083Y, TB5387011Z, TB5386632K

Comment 4

[timeless]

kinda looks like !m_mdbStore via GetStore().

Incident ID: 5396588
Stack Signature	nsMsgDatabase::GetTableCreateIfMissing 346ba35d
Product ID	ThunderbirdTrunk
Build ID	2005042607
Trigger Time	2005-04-27 06:43:15.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	thunderbird.exe + (004d6c72)
URL visited	
User Comments	
Since Last Crash	10087 sec
Total Uptime	16430 sec
Trigger Reason	Access violation
Source File, Line No.
e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/mailnews/db/msgdb/src/nsMsgDatabase.cpp,
line 1550
Stack Trace 	
nsMsgDatabase::GetTableCreateIfMissing 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/mailnews/db/msgdb/src/nsMsgDatabase.cpp,
line 1550]
nsImapMailDatabase::GetAllPendingHdrsTable 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/mailnews/db/msgdb/src/nsImapMailDatabase.cpp,
line 132]
nsImapMailFolder::CopyMessages 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/mailnews/imap/src/nsImapMailFolder.cpp,
line 6669]
nsMsgCopyService::DoNextCopy 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/mailnews/base/src/nsMsgCopyService.cpp,
line 286]
nsMsgCopyService::DoCopy 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/mailnews/base/src/nsMsgCopyService.cpp,
line 235]
nsMsgCopyService::CopyMessages 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/mailnews/base/src/nsMsgCopyService.cpp,
line 487]
nsMsgFolderDataSource::DoCopyToFolder 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/mailnews/base/src/nsMsgFolderDataSource.cpp,
line 2000]
nsMsgFolderDataSource::DoCommand 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/mailnews/base/src/nsMsgFolderDataSource.cpp,
line 845]
CompositeDataSourceImpl::DoCommand 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/rdf/base/src/nsCompositeDataSource.cpp,
line 1337]
nsMessenger::CopyMessages 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/mailnews/base/src/nsMessenger.cpp,
line 1326]
XPTC_InvokeByIndex 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
XPCWrappedNative::CallMethod 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2065]
XPC_WN_CallMethod 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1287]
js_Invoke 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 1320]
js_Interpret 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 3608]
js_Invoke 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 1340]
nsXPCWrappedJSClass::CallMethod 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp,
line 1339]
nsXPCWrappedJS::CallMethod 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp,
line 450]
SharedStub 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp,
line 147]
nsXULTreeBuilder::Drop 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/content/xul/templates/src/nsXULTreeBuilder.cpp,
line 2057]
nsTreeBodyFrame::HandleEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/layout/xul/base/src/tree/src/nsTreeBodyFrame.cpp,
line 2012]
PresShell::HandleEventInternal 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6361]
PresShell::HandleEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6142]
nsViewManager::HandleEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp,
line 2506]
nsViewManager::DispatchEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp,
line 2228]
HandleEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/view/src/nsView.cpp,
line 174]
nsWindow::DispatchEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1180]
nsNativeDragTarget::ProcessDrag 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsNativeDragTarget.cpp,
line 237]
nsNativeDragTarget::Drop 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsNativeDragTarget.cpp,
line 360]
ole32.dll + 0x118e86 (0x775f8e86)
ole32.dll + 0x1190c8 (0x775f90c8)
ole32.dll + 0xefc98 (0x775cfc98)
ole32.dll + 0xefb20 (0x775cfb20)
nsDragService::StartInvokingDragSession 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsDragService.cpp,
line 188]
nsDragService::InvokeDragSession 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsDragService.cpp,
line 149]
XPTC_InvokeByIndex 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
XPCWrappedNative::CallMethod 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2065]
XPC_WN_CallMethod 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1287]
js_Invoke 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 1320]
js_Interpret 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 3608]
js_Invoke 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 1340]
js_InternalInvoke 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 1417]
JS_CallFunctionValue 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/js/src/jsapi.c,
line 3851]
nsJSContext::CallEventHandler 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp,
line 1384]
nsJSEventListener::HandleEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/dom/src/events/nsJSEventListener.cpp,
line 184]
nsEventListenerManager::HandleEventSubType 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1545]
nsEventListenerManager::HandleEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1642]
nsXULElement::HandleDOMEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2192]
nsEventStateManager::GenerateDragGesture 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/content/events/src/nsEventStateManager.cpp,
line 1534]
nsEventStateManager::PreHandleEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/content/events/src/nsEventStateManager.cpp,
line 477]
PresShell::HandleEventInternal 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6295]
PresShell::HandleEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6142]
nsViewManager::HandleEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp,
line 2506]
nsViewManager::DispatchEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp,
line 2228]
HandleEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/view/src/nsView.cpp,
line 174]
nsWindow::DispatchEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1180]
nsWindow::DispatchMouseEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 5900]
ChildWindow::DispatchMouseEvent 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 6153]
nsWindow::WindowProc 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1472]
USER32.dll + 0x8734 (0x77d48734)
USER32.dll + 0x8816 (0x77d48816)
USER32.dll + 0x89cd (0x77d489cd)
USER32.dll + 0x8a10 (0x77d48a10)
nsAppShell::Run 
[e:/builds/tinderbox/thunderbird-trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsAppShell.cpp,
line 159]

Comment 5

[timeless]

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

Comment 6

[Michael Witbrock]

Additional information:
I don't SEEM to have had either the TB hangs/zombies after inactivity mentioned
in the DUP or the crash on move bug since I did a complete reinstall INCLUDING
renaming the TB directory (simply reinstalling on top of a preexisting setup
didn't help). 

For what it's worth.

Comment 7

[Peter Tandler]

Today I had a crash of TB when deleting mails (see dupl. bug #293568) after TB
was idle for a while. By chance I noticed that Google Desktop Search was active
during the idle period (in the windows task manager) and TB had also some CPU
usage, so I could imagine that GDS was indexing mails.

See TB6469222G for the crash data.

(and also TB6455385H, TB6351615X, TB6265638M, TB6240934X, TB6056993W,
TB5968413M, TB5745765X, TB5713915W, TB5712899K, TB5651102Q, TB5623845M)

Comment 8

[Peter Tandler]

BTW: related to bug #243701?

Comment 9

[David :Bienvenu]

I don't know how we can get a msg db with a null or invalid store like this,
unless there's some sort of ref-counting problem with msg db's. I'm not sure
what GDS could be doing that would cause this. I'd really like to be able to
reproduce this before applying any band-aids.

Comment 10

[Peter Tandler]

A couple of days ago, I re-installed TB (as suggested in comment #6) and
especially did /not/ re-installed the google desktop stuff afterwards. Since
then, I did not have any crash.

Is there anything I could do to help reproducing this bug? e.g. is there
anything I should do /before/ re-installing GDS (to see if TB then crashes again)?
(Michael, do you also use GDS?)

Comment 11

[David :Bienvenu]

Peter, how long have you run without GDS, and not had a crash? And how long does
it usually take to crash when you have GDS running? If you pause indexing, does
the crash stop? What's your general account setup? Do you have your imap folders
configured for offline use? Do you have filters setup?

Comment 12

[Peter Tandler]

(In reply to comment #11)
> Peter, how long have you run without GDS, and not had a crash? And how long does
> it usually take to crash when you have GDS running? If you pause indexing, does
> the crash stop? What's your general account setup? Do you have your imap folders
> configured for offline use? Do you have filters setup?

I re-installed it (without GDS) about 4 days ago. Before, it crashed (or hung)
about 2-3 times each day. Since then, it didn't crash at all.

I didn't try to pause GDS indexing (yet).

I have two IMAP accounts and a couple of RSS feeds.
I have offline support installed, but I don't use it often (I'm online most of
the time).
I have a lot of filters (>20), I use the SPAM filter.

Anything else you need to know?

Comment 13

[David :Bienvenu]

thx. During the period when the crash was happening, did you ever see tbird
re-download all the headers for an imap folder, i.e., downloading headers it had
previously downloaded before? Re the offline question, it really has to do with
whether you have some imap folders configured for offline use, not so much if
you ever use the product offline. The former is all that's needed for GDS to pay
attention to the imap folders.

My theory is that .msf files are getting corrupted somehow, and though we handle
the error and rebuild the .msf file, we leave a partially formed db in memory,
and in some cases, we end up using that db. If an imap folder's msf file gets
corrupted, we should end up redownloading all the headers.

Comment 14

[Peter Tandler]

(In reply to comment #13)
> thx. During the period when the crash was happening, did you ever see tbird
> re-download all the headers for an imap folder, i.e., downloading headers it had
> previously downloaded before? Re the offline question, it really has to do with
> whether you have some imap folders configured for offline use, not so much if
> you ever use the product offline. The former is all that's needed for GDS to pay
> attention to the imap folders.

Yes, many of my folder are configured for offline use, and yes, it has happened
a couple of times (actually quite often) that I noticed that TB downloads all
message headers again although they have been downloaded before. (Let me add
that offline folders don't seem to be too reliable anyway ...)
I'm not sure if TB has downloaded any headers since I re-installed it. I can let
you know if I notice it again.
I'm not sure if the re-dowanload happened "during" the crash, I'd rather assume
it happened /after/ a crash, but I'm not sure.
I'm also not sure if I ever noticed this re-download of headers before I first
installed GDS.
Anything else? ;-) I'm really happy you started taking care of this bug!

Comment 15

[David :Bienvenu]

> Let me add that offline folders don't seem to be too reliable anyway

I've fixed a few problems with playing back offline events for 1.1a so you might
give that a try.

>I'm not sure if the re-dowanload happened "during" the crash, I'd rather assume
>it happened /after/ a crash, but I'm not sure.

I suspect it would happen after the crash - the sequence of events would be:

1. a folder DB gets corrupted somehow
2. you try to copy a message to the folder.
3. We notice the db is corrupt and delete it, but still crash, (perhaps it's
even the second copy that causes the crash)
4. Next time you open the folder, we download all the headers.

I don't know if GDS is making the db corruption more likely, or if it just
causes a problem in our handling of corrupt db's, because it tends to keep all
db's open...

Comment 16

[David :Bienvenu]

Attachment: possible fix

if we get an OK ret from mork, but no store, set ret to an error. I don't know
if this is possible, but I can't think of any other way to get a null store.

Comment 17

[David :Bienvenu]

potential fix checked in.

Comment 18

[David :Bienvenu]

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

Comment 19

[David :Bienvenu]

I'm going to mark this fixed, and look at talback for new reports

Comment 20

[Stephen Donner [:stephend] Not actively reading bugmail]

According to Talkback, it still occurred in:

nsMsgDatabase::GetTableCreateIfMissing d0d8b3b3	2005-06-20 07:38:08.0  	 with
build ID: 

MozillaOrgThunderbirdTrunkWin322005061908  	

Comment 21

[rts]

This is still happening - see talkback 14228551.  I'm using Thunderbird 1.5 (20051201) on Win32.  Just as in the other messages associated with this bug, I've got a number of IMAP accounts, and am running Google Desktop.  Sometimes when I move messages, it simply crashes.  Other times it's fine.  It typically crashes about 1 in 10 times I move messages.