Thunderbird crashes when working with filters [@ iid] [@ nsHashtable::Reset]

RESOLVED WORKSFORME

Status

Thunderbird
General
--
critical
RESOLVED WORKSFORME
10 years ago
5 years ago

People

(Reporter: Worcester12345, Unassigned)

Tracking

({crash})

x86
Windows XP
crash

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [needs trunk test] closeme 2009-12-01, crash signature)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007080802 SeaMonkey/2.0a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7pre) Gecko/20070808 Thunderbird/2.0.0.7pre ID:2007080805

I am trying to add a new email address to one of my filters and then run it.

It crashes at various times during this process.

Reproducible: Always

Steps to Reproduce:
1.Open message filters.
2.Play around with different filters and their settings.
3.Run filters.
4.Crash!
Actual Results:  
Crash!

Expected Results:  
No crash and have filters work.
(Reporter)

Updated

10 years ago
Keywords: crash
Version: unspecified → 2.0
(Reporter)

Comment 1

10 years ago
P.S. Talkback reporter turned in several reports from this just recently.
Worksforme with Thunderbird version 3.0a1pre (2007080605) / MS Win-XP.
Similar phenomenon to Bug 390992?
Will "DEL %TEMP%\*.* /S /Q" at Command Prompt resolve your crash problem?
(See Bug 390992 Comment #1) 
(Reporter)

Comment 3

10 years ago
(In reply to comment #2)
> Worksforme with Thunderbird version 3.0a1pre (2007080605) / MS Win-XP.
> Similar phenomenon to Bug 390992?
> Will "DEL %TEMP%\*.* /S /Q" at Command Prompt resolve your crash problem?
> (See Bug 390992 Comment #1) 
> 
Thanks for that. So this shows that it isn't on the nightly trunk builds, which jives with the "Version: 2.0" field.

Can someone confirm this bug?
(Reporter)

Updated

10 years ago
Flags: blocking-thunderbird3?
(Reporter)

Updated

10 years ago
Blocks: 378635
A bug which according to the comments so far doesn't occur in Tb 3.0 is an unlikely candidate for a 3.0 blocker.
No longer blocks: 378635
Flags: blocking-thunderbird3?
(Reporter)

Comment 5

10 years ago
Well, how does it get marked then? Maybe for 2.0.0.7? Where is the flag for that? 

Can anyone confirm that this bug exists?

Comment 6

10 years ago
(In reply to comment #5)
> Well, how does it get marked then? Maybe for 2.0.0.7? Where is the flag for
> that? 

seriously - to consider a bug *that hasn't been confirmed* as blocking anything seems pointless


> Can anyone confirm that this bug exists?
 
Possible actions you can take...

What is your talkback id?
Have you done a query on talkback for crashes with "filter" in the comment string?
Have you checked bugzilla for crashes reported on version 2 that mention filter?

Comment 7

10 years ago
one other interesting bit, would be to determine if fails also with a trunk build.
given your ability to reproduce the crash, that should be an easy test.
(Reporter)

Comment 8

10 years ago
There is no talkback id.
Where do I do that query?
Yes, I check bugzilla for filter crashes.

I suppose I could try it with trunk, but it would take a while. 

Comment 9

10 years ago
Talkback ids are shown in the agent (http://kb.mozillazine.org/Talkback), but the Nightly Tester Tools extension gives you quick access to it. 

When reporting crashes, always give crash ids (talkback or now breakpad).
(Reporter)

Comment 10

10 years ago
Maybe:

http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB34776434H

and

http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB34776467H
(Reporter)

Comment 11

10 years ago
Can someone confirm those Talkback ID's and also this bug? Thanks.

Comment 12

10 years ago
(In reply to comment #11)
> Can someone confirm those Talkback ID's and also this bug? Thanks.

I don't know why others didn't confirm, but I didn't confirm (and won't still) because in comment 10 you said *maybe*.  I'd prefer to be accurate in citations.  If you get a crash, using http://kb.mozillazine.org/Talkback you should be able to easily cite with absolute certainty which talkback reports are yours.

p.s. it is sufficient to write a talkback id as "TBxxxxxxx", eg TB34776434H

Comment 13

10 years ago
p.p.s you also say "It crashes at various times during this process.".  Since there is variability, you probably should cite with each crash report what steps caused that crash, i.e. at what step it crashed. This will aid diagnosis and solution.
(Reporter)

Comment 14

10 years ago
OK, those are the ones. I said maybe because I didn't remember them but had to use an extension to find them. The dates coincide with my crashes also.

Comment 15

10 years ago
TBTB34776467H has nothing usefull, just ntdll.dll
on what folder are you doing the "run now"?  or doesn't it matter?
does it happen only if something is found by the filter?

TB34776434
Stack Signature	 iid 51b51189
Product ID	Thunderbird2
Build ID	2007080805
Trigger Time	2007-08-08 16:47:02.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	xpcom_core.dll + (000472ee)
User Comments	
Since Last Crash	8873 sec
Total Uptime	8873 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
iid
nsHashtable::Reset  [mozilla/xpcom/ds/nsHashtable.cpp, line 352]
nsObjectHashtable::Reset  [mozilla/xpcom/ds/nsHashtable.cpp, line 794]
nsTreeBodyFrame::`scalar deleting destructor'
nsTreeBodyFrame::Destroy  [mozilla/layout/xul/base/src/tree/src/nsTreeBodyFrame.cpp, line 354]
nsFrameList::DestroyFrames  [mozilla/layout/generic/nsFrameList.cpp, line 138]
nsBoxFrame::Destroy  [mozilla/layout/xul/base/src/nsBoxFrame.cpp, line 1122]
nsBoxFrame::Destroy  [mozilla/layout/xul/base/src/nsBoxFrame.cpp, line 1122]
nsBoxFrame::Destroy  [mozilla/layout/xul/base/src/nsBoxFrame.cpp, line 1122]
nsBoxFrame::Destroy  [mozilla/layout/xul/base/src/nsBoxFrame.cpp, line 1122]
nsBoxFrame::Destroy  [mozilla/layout/xul/base/src/nsBoxFrame.cpp, line 1122]
nsBoxFrame::Destroy  [mozilla/layout/xul/base/src/nsBoxFrame.cpp, line 1122]
nsBoxFrame::Destroy  [mozilla/layout/xul/base/src/nsBoxFrame.cpp, line 1122]
nsBoxFrame::Destroy  [mozilla/layout/xul/base/src/nsBoxFrame.cpp, line 1122]
nsBoxFrame::Destroy  [mozilla/layout/xul/base/src/nsBoxFrame.cpp, line 1122]
nsBoxFrame::Destroy  [mozilla/layout/xul/base/src/nsBoxFrame.cpp, line 1122]
ViewportFrame::Destroy  [mozilla/layout/generic/nsViewportFrame.cpp, line 67]
DocumentViewerImpl::Destroy  [mozilla/layout/base/nsDocumentViewer.cpp, line 1556]
nsDocShell::Destroy  [mozilla/docshell/base/nsDocShell.cpp, line 3539]
nsXULWindow::Destroy  [mozilla/xpfe/appshell/src/nsXULWindow.cpp, line 514]
nsWebShellWindow::Destroy  [mozilla/xpfe/appshell/src/nsWebShellWindow.cpp, line 850]
nsWebShellWindow::HandleEvent  [mozilla/xpfe/appshell/src/nsWebShellWindow.cpp, line 408]
nsWindow::DispatchEvent  [mozilla/widget/src/windows/nsWindow.cpp, line 1319]
nsWindow::DispatchStandardEvent  [mozilla/widget/src/windows/nsWindow.cpp, line 1359]
nsWindow::ProcessMessage  [mozilla/widget/src/windows/nsWindow.cpp, line 4509]
nsWindow::WindowProc  [mozilla/widget/src/windows/nsWindow.cpp, line 1507]
USER32.dll + 0x8734 (0x7e418734)
USER32.dll + 0x8816 (0x7e418816)
USER32.dll + 0xb4c0 (0x7e41b4c0)
USER32.dll + 0xb50c (0x7e41b50c)
ntdll.dll + 0xeae3 (0x7c90eae3)
USER32.dll + 0xb3f9 (0x7e41b3f9)
USER32.dll + 0xb393 (0x7e41b393)
nsWindow::DefaultWindowProc  [mozilla/widget/src/windows/nsWindow.cpp, line 1533]
USER32.dll + 0x8734 (0x7e418734)
USER32.dll + 0x8816 (0x7e418816)
USER32.dll + 0xc63f (0x7e41c63f)
USER32.dll + 0xc665 (0x7e41c665)
nsWindow::WindowProc  [mozilla/widget/src/windows/nsWindow.cpp, line 1514]
USER32.dll + 0x8734 (0x7e418734)
USER32.dll + 0x8816 (0x7e418816)
USER32.dll + 0xb4c0 (0x7e41b4c0)
USER32.dll + 0xb50c (0x7e41b50c)
ntdll.dll + 0xeae3 (0x7c90eae3)
USER32.dll + 0xb3f9 (0x7e41b3f9)
USER32.dll + 0xb393 (0x7e41b393)
nsWindow::DefaultWindowProc  [mozilla/widget/src/windows/nsWindow.cpp, line 1533]
USER32.dll + 0x8734 (0x7e418734)
USER32.dll + 0x8816 (0x7e418816)
USER32.dll + 0xc63f (0x7e41c63f)
USER32.dll + 0xc665 (0x7e41c665)
nsWindow::WindowProc  [mozilla/widget/src/windows/nsWindow.cpp, line 1514]
USER32.dll + 0x8734 (0x7e418734)
USER32.dll + 0x8816 (0x7e418816)
USER32.dll + 0x89cd (0x7e4189cd)
USER32.dll + 0x8a10 (0x7e418a10)
nsAppShell::Run  [mozilla/widget/src/windows/nsAppShell.cpp, line 159]
nsAppStartup::Run  [mozilla/toolkit/components/startup/src/nsAppStartup.cpp, line 152]
main  [mozilla/mail/app/nsMailApp.cpp, line 62]
kernel32.dll + 0x16fd7 (0x7c816fd7)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Thunderbird crashes when working with filters → Thunderbird crashes when working with filters [@ iid] [@ nsHashtable::Reset]

Comment 16

10 years ago
WFM with 
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.7pre) Gecko/20070911 Thunderbird/2.0.0.7pre ID:2007091103 (vista business)
(Reporter)

Comment 17

10 years ago
Was doing the "run now" on the Inbox.

Comment 18

10 years ago
I can confirm that this is a bug, that i can reproduce it on two machines.
running DEL %TEMP%\*.* /S /Q does nothing.
Both machines have vista home basic
Both machines have 1 gb of ram
One machine has a fresh install of thunderbird
Run Now crashes, runing filters automaticly when checking messages does it
This started imediately after the recent public update (2.0.0.12)
Running in -safe-mode does nothing

Comment 19

10 years ago
TB44253486K
TB44253153Z
TB44213083X
those are all crashes related to my machine, all at different times

Comment 20

10 years ago
all three are like this and belong to some other bug:

Stack Signature	 msvcrt.dll + 0x9b20 (0x773d9b20) d5920c95
Product ID	Thunderbird2
Build ID	2008021305
Trigger Time	2008-04-22 15:12:11.0
Platform	Win32
Operating System	Windows NT 6.0 build 6000
Module	msvcrt.dll + (00009b20)
URL visited	
User Comments	
Since Last Crash	329 sec
Total Uptime	428107 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
msvcrt.dll + 0x9b20 (0x773d9b20)
FileImpl::Write  [mozilla/xpcom/obsolete/nsIFileStream.cpp, line 453]
nsOutputStream::write  [mozilla/xpcom/obsolete/nsFileStream.cpp, line 131]
nsParseNewMailState::AppendMsgFromFile  [mozilla/mailnews/local/src/nsParseMailbox.cpp, line 2199]
nsParseNewMailState::MoveIncorporatedMessage  [mozilla/mailnews/local/src/nsParseMailbox.cpp, line 2304]
nsParseNewMailState::ApplyFilterHit  [mozilla/mailnews/local/src/nsParseMailbox.cpp, line 1892]
nsMsgFilterList::ApplyFiltersToHdr  [mozilla/mailnews/base/search/src/nsMsgFilterList.cpp, line 372]
nsParseNewMailState::ApplyFilters  [mozilla/mailnews/local/src/nsParseMailbox.cpp, line 1788]
nsParseNewMailState::PublishMsgHeader  [mozilla/mailnews/local/src/nsParseMailbox.cpp, line 1712]
nsPop3Sink::IncorporateComplete  [mozilla/mailnews/local/src/nsPop3Sink.cpp, line 895]
nsPop3Protocol::HandleLine  [mozilla/mailnews/local/src/nsPop3Protocol.cpp, line 3430]
nsPop3Protocol::RetrResponse  [mozilla/mailnews/local/src/nsPop3Protocol.cpp, line 3207]
nsPop3Protocol::ProcessProtocolState  [mozilla/mailnews/local/src/nsPop3Protocol.cpp, line 3861]
nsMsgProtocol::OnDataAvailable  [mozilla/mailnews/base/util/nsMsgProtocol.cpp, line 350]
nsInputStreamPump::OnStateTransfer  [mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 494]
nsInputStreamPump::OnInputStreamReady  [mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 398]
nsOutputStreamReadyEvent::EventHandler  [mozilla/xpcom/io/nsStreamUtils.cpp, line 121]
0x778b0c24

Comment 21

10 years ago
john's stacks match bug 428314, but not the step to reproduce

Comment 22

10 years ago
then something else, much bigger is happening on that client, when i disabled the filters it stopped crashing. if yall need me to reproduce the bug again, it wont take long, but i wont have access to that computer until Friday morning.
(Reporter)

Comment 23

10 years ago
(In reply to comment #22)
> then something else, much bigger is happening on that client, when i disabled
> the filters it stopped crashing. if yall need me to reproduce the bug again, it
> wont take long, but i wont have access to that computer until Friday morning.
> 
Please do.
(Reporter)

Comment 24

10 years ago
Silly question, but do the Coverity, Klocwork, and Valgrind tools all get automatically run against the entire code base, and if so, on what frequency/schedule? I see flags for these tools, how does one invoke them? Thanks.
(In reply to comment #24)
> Silly question, but do the Coverity, Klocwork, and Valgrind tools all get
> automatically run against the entire code base, and if so, on what
> frequency/schedule? I see flags for these tools, how does one invoke them?
> Thanks.

Not automatically. There are various leak gauge tools run automatically (although not on TB builds due to a variety of factors), but we don't run the tools you specified automatically.

That said, developers will occasionally run the tools on the code they write to find and fix leaks.

As for invoking them, the easiest way IMO is to do thunderbird (or relevant program) -g valgrind, or similar.

Comment 26

10 years ago
Klocwork and Coverity are theoretically run regularly, however, last I checked, Coverity got stuck with an invalid build configuration, rendering it useless. I'm investigating the status of Klocwork now. in practice, neither of them are checked regularly, however individual teams may check them more regularly (I think the NSS team checks one or both much more regularly than the rest of Mozilla).

wrt "invoking" these tools, you need special accounts, the tools are hosted by Klocwork and Coverity respectively.

Valgrind can be "invoked" with any Linux build for which you've built --enable-debug(ger-info-modules) using something like:

./run-mozilla.sh -g -d `which valgrind` ./something-bin

where something-bin could be firefox-bin, xpcshell, ...
(Reporter)

Comment 27

8 years ago
Has anyone checked to see if this is fixed in version 3? I tried 3 for a little while, but ran into the dataloss issue, and am not going back until it is released. It would be nice to have this behind us.
Flags: blocking-thunderbird3?
Priority: -- → P1

Comment 28

8 years ago
worcester12345

please stop requesting random bugs to block thunderbird 3.  This is not a top crash, nor does it have a solution at hand. And we are only a few days to building version 3, which doesn't mean "see how many bugs can be jammed in the last few hours".  (removing the request)

Also you know that priority is not be set by us mortals.
Flags: blocking-thunderbird3?
Priority: P1 → --
(Reporter)

Comment 29

8 years ago
(In reply to comment #28)
> worcester12345
> 
> please stop requesting random bugs to block thunderbird 3.  This is not a top
> crash, nor does it have a solution at hand. 

It is a top crasher for me.

> And we are only a few days to
> building version 3, which doesn't mean "see how many bugs can be jammed in the
> last few hours".  (removing the request)

I did not know this.

> 
> Also you know that priority is not be set by us mortals.

Nor did I know this. Does this imply you consider someone "immortal" on here? I thought that we do set this according to our own priority. Still seeing this as a top crashing bug in the current shipping product makes it a top priority to get it fixed for the next released product, period.

Comment 30

8 years ago
(In reply to comment #29)
> (In reply to comment #28)
> > worcester12345
> > 
> > please stop requesting random bugs to block thunderbird 3.  This is not a top
> > crash, nor does it have a solution at hand. 
> 
> It is a top crasher for me.

the definition is very clear at "topcrash" in https://bugzilla.mozilla.org/describekeywords.cgi

nsHashtable::Reset doesn't appear in the top 100 of 3.0b4, nor in fact do I find it at all in 3.0b4 http://crash-stats.mozilla.com/query/query?product=Thunderbird&version=Thunderbird%3A3.0b4&date=&range_value=4&range_unit=weeks&query_search=signature&query_type=exact&query=&do_query=1# nor any crashes of the last 30days for any release http://crash-stats.mozilla.com/query/query?product=Thunderbird&version=ALL%3AALL&date=&range_value=4&range_unit=weeks&query_search=signature&query_type=contains&query=nsHashtable%3A%3AReset&do_query=1

Nor, I am sure, is it a topcrash in v2.x


> > And we are only a few days to
> > building version 3, which doesn't mean "see how many bugs can be jammed in the
> > last few hours".  (removing the request)
> 
> I did not know this.

see recent postings at http://planet.mozillamessaging.com/ about 3.0 RC


> > Also you know that priority is not be set by us mortals.
> 
> Nor did I know this. Does this imply you consider someone "immortal" on here? I
> thought that we do set this according to our own priority. Still seeing this as
> a top crashing bug in the current shipping product makes it a top priority to
> get it fixed for the next released product, period.

Not at all. This it is very clear at "priority" in https://bugzilla.mozilla.org/page.cgi?id=fields.html#importance


generally speaking, "blocking" is not an appropriate tool for a bug that merely needs triage or QA.

A more productive line of inquiry would be a) assist in the resolution of the dataloss bug that you indicate is blocking your usage of v3, and b) to cite a thunderbird 3 crashid, which would be most helpful.  Leaving bug open until 3.0 is widely available.
Whiteboard: [needs trunk test] closeme 2009-12-01
RESO INCO due to lack of response to last question. If you feel this change was in error, please respond to this bug with your reasosn why.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INCOMPLETE
(Assignee)

Updated

7 years ago
Crash Signature: [@ iid] [@ nsHashtable::Reset]
(Reporter)

Comment 32

6 years ago
I have not seen this bug in quite a while. It could go down as WONTFIX, WORKSFORME, or leave as is.
Crash Signature: [@ iid] [@ nsHashtable::Reset] → [@ iid] [@ nsHashtable::Reset]

Updated

5 years ago
Resolution: INCOMPLETE → WORKSFORME
You need to log in before you can comment on or make changes to this bug.