259434 - TB09 crash with "Mark Newsgroup Read" [@ nsMsgKeySet::AddRange]

Status: RESOLVED FIXED

(Thunderbird :: General, defect)

Description

[Lachlan Hunt]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Build Identifier: Thunderbird version 0.8 (20040913)

I recently upgraded from Thunderbird 0.7.3 to 0.8, and now (even after
completely uninstalling and reinstalling) thunderbird crashes when I select
"Mark Newsgroup Read".

Reproducible: Always
Steps to Reproduce:
1. Subscribe to a newsgroup. eg. comp.infosystems.www.authoring.html
2. From the context menu, select "Mark Newsgroup Read"

Actual Results:  
Thunderbird crahsed

Expected Results:  
Birds should be more careful when flying, to avoid crashing. :-)

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Can you provide a talkback id? That's would be very helpful.

Comment 2

[Lachlan Hunt]

Ok, here's the talkback incident ID's with their date and time:

TB817213H  2004-09-15 13:26+10:00
TB817217K  2004-09-15 13:28+10:00
TB817261G  2004-09-15 13:34:10:00
TB819536M  2004-09-15 19:12+10:00

Comment 3

[Lachlan Hunt]

After some further investigation, the problem was only occuring for
comp.infosystems.www.authoring.html, and not c.i.w.a.stylesheets which I am also
subscribed to.  I was able to solve the problem by unsubscribing from
c.i.w.a.html and re-subscribing.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

There are 54 other crash reports:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsMsgKeySet%3A%3AAddRange&vendor=All&product=All&platform=All&buildid=&sdate=&stime=&edate=&etime=

Lachlan, how many unread messages were in this newsgroup?

Comment 5

[Lachlan Hunt]

Initially, I believe, it was saying over 400 before the first crash (sorry, I
don't have exact numbers), then after each crash the number would increase. 
First to over 600, then over 1000, and then, I believe, the last time (after
several more crashes) was over 3000.  I probably should have put that in before,
but wasn't thinking at the time, and completely forgot.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Subscribing to comp.infosystems.www.authoring.html and marking all read works
for me. Do you use any extension? Please try to confirm it with a fresh profile.

Comment 7

[Lachlan Hunt]

The only extension I have installed is View Headers Toggle Button 1.2

I tried everything I could think of to replicate this again, including creating
a new profile, restoring my back up profile from before I upgraded, uninstalling
and downgrading back to 0.7.3, and then upgrading again to 0.8, and various
combinations and methods of each; but was unsuccessful with every attempt to
cause the crash again.  I'll keep trying when I have more time, and let you know
if I find anything

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Strange behavior. The crash occurs in following file at line 253:

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/mailnews/base/util/nsMsgKeySet.cpp&mark=953&rev=AVIARY_1_0_20040515_BRANCH#953

952 NS_ASSERTION(start <= end, "invalid range");
953 if (start > end) return -1;

I don't see any reason why it's happen here. Anyone who can take a look at this?

Comment 9

[David :Bienvenu]

my guess is that m_readSet isn't valid for some reason, and we're really
crashing because of that.

Comment 10

[Olivier Cahagne]

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

Comment 11

[Cheng Yuk Pong]

I have the same crash with  "version 0.6+ (20040912)"  (btw, why 20040912 is
0.6+ ?)...

It crash only on news://news.gmane.org/gmane.linux.kernel which have some 4x,xxx
post unread out of a few hundred thousands post unread..

deleteing all files in \Profiles\default\26wqh13q.slt\News\news.gmane.org and
restart thunderbird seems to fix this problem..

Comment 12

[Cheng Yuk Pong]

Profiles\default\26wqh13q.slt\News\news.gmane.org.rc contains a line
  gmane.linux.kernel: 
with no numbers after it..  could this be a problem too?

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+1]]

We should miss to fix this bug. So asking for blocker. We already have 632
incident ids!

Comment 14

[David :Bienvenu]

I believe the m_readSet is invalid, which is why we're crashing. It could be the
newsrc file has an invalid line for that group, which causes some sort of
failure to create the m_readSet...

Comment 15

[Nicholas Sherlock]

I'm having the same problem here, but only with a newsgroup containing >32k
messages. I get "The instruction at '0x00942eee' referenced memory at
"0x0000000c". The memory could not be 'written'". Very annoying.

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Nicholas, please provide the information from that newsgroup out of the
%newsserver%.rc. 

Comment 17

[Nicholas Sherlock]

Here's the line from the .rc for that group.

glscene.general: 1-33616

Comment 18

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I can't find this newsgroup on my server. Which newsserver you are using?

Comment 19

[Nicholas Sherlock]

forums.talkto.net

Comment 20

[Asa Dotzler [:asa]]

restoring nomination.

Comment 21

[Jay Patel [:jay]]

This is a topcrasher for Thunderbird 0.9:

Count   Offset    Real Signature
[ 26   nsMsgKeySet::AddRange 9793d5ad - nsMsgKeySet::AddRange ]
 
     Crash date range: 04-NOV-04 to 10-NOV-04
     Min/Max Seconds since last crash: 9 - 57668
     Min/Max Runtime: 35 - 190966
 
     Count   Platform List 
     26   Windows XP [Windows NT 5.1 build 2600] 
 
     Count   Build Id List 
     26   2004110312
 
     No of Unique Users        11
 
 Stack trace(Frame) 

	 nsMsgKeySet::AddRange
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/mailnews/base/util/nsMsgKeySet.cpp
 line 953] 
	 nsNewsDatabase::MarkAllRead
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/mailnews/db/msgdb/src/nsNewsDatabase.cpp
 line 297] 
	 nsMsgDBFolder::MarkAllMessagesRead
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/mailnews/base/util/nsMsgDBFolder.cpp
 line 1274] 
	 CompositeDataSourceImpl::DoCommand
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/rdf/base/src/nsCompositeDataSource.cpp
 line 1340] 
	 XPCWrappedNative::CallMethod
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp
 line 2034] 
	 XPC_WN_CallMethod
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp
 line 1287] 
	 js_Invoke
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c
 line 941] 
	 js_Interpret
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c
 line 2972] 
	 js_Invoke
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c
 line 958] 
	 js_InternalInvoke
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c
 line 1035] 
	 JS_CallFunctionValue
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/js/src/jsapi.c
 line 3698] 
	 nsJSContext::CallEventHandler
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/dom/src/base/nsJSEnvironment.cpp
 line 1297] 
	 nsJSEventListener::HandleEvent
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/dom/src/events/nsJSEventListener.cpp
 line 184] 
	 nsEventListenerManager::HandleEventSubType
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp
 line 1436] 
	 nsEventListenerManager::HandleEvent
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp
 line 1516] 
	 nsXULElement::HandleDOMEvent
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp
 line 2841] 
	 PresShell::HandleDOMEventWithTarget
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp
 line 6139] 
	 nsMenuFrame::Execute
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsMenuFrame.cpp
 line 1671] 
	 nsMenuFrame::HandleEvent
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsMenuFrame.cpp
 line 454] 
	 PresShell::HandleEventInternal
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp
 line 6103] 
	 PresShell::HandleEvent
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp
 line 5921] 
	 nsViewManager::HandleEvent
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp
 line 2326] 
	 nsViewManager::DispatchEvent
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp
 line 2066] 
	 HandleEvent
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/view/src/nsView.cpp
 line 77] 
	 nsWindow::DispatchEvent
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp
 line 1067] 
	 nsWindow::DispatchMouseEvent
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp
 line 5261] 
	 ChildWindow::DispatchMouseEvent
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp
 line 5511] 
	 nsWindow::WindowProc
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp
 line 1349] 
	 USER32.dll + 0x8709 (0x77d18709)  
	 USER32.dll + 0x87eb (0x77d187eb)  
	 USER32.dll + 0x89a5 (0x77d189a5)  
	 USER32.dll + 0x89e8 (0x77d189e8)  
	 nsAppShell::Run
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsAppShell.cpp
 line 159] 
	 nsAppShellService::Run
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/xpfe/appshell/src/nsAppShellService.cpp
 line 495] 
	 main
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/mail/app/nsMailApp.cpp
 line 58] 
	 kernel32.dll + 0x16d4f (0x7c816d4f)   
 
     (1849487)	Comments: Tried to mark newsgroup (comp.lang.smalltalk) as read.
     (1814009)	Comments: on try to mark the virtual messages marked as read the
client faild again  so i will delete the newsgroup complete and try to re create it
     (1813772)	Comments: I donwload news from newsserver for offline reading and
one group count for every click 25 more message as new. The download was actual
on a other group. In this group the virus scanner delete before two times the
crash.trojan in the news file so it is
     (1813772)	Comments:  possible that the file is corupted trough virus clean.
     (1771145)	Comments: news server gmale (mailing lists via news). Crash on
context menue "marks newsgroup as read" with a maven mailing list.
 
====================================================================================================
     Count   Offset    Real Signature
[ 20   nsMsgKeySet::AddRange e37f0959 - nsMsgKeySet::AddRange ]
 
     Crash date range: 03-NOV-04 to 09-NOV-04
     Min/Max Seconds since last crash: 14 - 71525
     Min/Max Runtime: 36 - 100446
 
     Count   Platform List 
     20   Windows XP [Windows NT 5.1 build 2600] 
 
     Count   Build Id List 
     20   2004110312
 
     No of Unique Users        15
 
 Stack trace(Frame) 

	 nsMsgKeySet::AddRange
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/mailnews/base/util/nsMsgKeySet.cpp
 line 953] 
	 nsNewsDatabase::MarkAllRead
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/mailnews/db/msgdb/src/nsNewsDatabase.cpp
 line 297] 
	 nsMsgDBFolder::MarkAllMessagesRead
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/mailnews/base/util/nsMsgDBFolder.cpp
 line 1274] 
	 CompositeDataSourceImpl::DoCommand
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/rdf/base/src/nsCompositeDataSource.cpp
 line 1340] 
	 XPCWrappedNative::CallMethod
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp
 line 2034] 
	 XPC_WN_CallMethod
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp
 line 1287] 
	 js_Invoke
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c
 line 941] 
	 js_Interpret
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c
 line 2972] 
	 js_Invoke
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c
 line 958] 
	 js_InternalInvoke
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c
 line 1035] 
	 JS_CallFunctionValue
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/js/src/jsapi.c
 line 3698] 
	 nsJSContext::CallEventHandler
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/dom/src/base/nsJSEnvironment.cpp
 line 1297] 
	 nsJSEventListener::HandleEvent
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/dom/src/events/nsJSEventListener.cpp
 line 184] 
	 nsEventListenerManager::HandleEventSubType
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp
 line 1436] 
	 nsEventListenerManager::HandleEvent
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp
 line 1516] 
	 nsXULElement::HandleDOMEvent
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp
 line 2841] 
	 PresShell::HandleDOMEventWithTarget
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp
 line 6139] 
	 nsMenuFrame::Execute
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsMenuFrame.cpp
 line 1671] 
	 nsMenuFrame::HandleEvent
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsMenuFrame.cpp
 line 454] 
	 PresShell::HandleEventInternal
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp
 line 6103] 
	 PresShell::HandleEvent
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp
 line 5921] 
	 nsViewManager::HandleEvent
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp
 line 2326] 
	 nsViewManager::DispatchEvent
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp
 line 2066] 
	 HandleEvent
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/view/src/nsView.cpp
 line 77] 
	 nsWindow::DispatchEvent
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp
 line 1067] 
	 nsWindow::DispatchMouseEvent
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp
 line 5261] 
	 ChildWindow::DispatchMouseEvent
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp
 line 5511] 
	 nsWindow::WindowProc
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp
 line 1349] 
	 USER32.dll + 0x8709 (0x77d48709)  
	 USER32.dll + 0x87eb (0x77d487eb)  
	 USER32.dll + 0x89a5 (0x77d489a5)  
	 USER32.dll + 0x89e8 (0x77d489e8)  
	 nsAppShell::Run
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsAppShell.cpp
 line 159] 
	 nsAppShellService::Run
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/xpfe/appshell/src/nsAppShellService.cpp
 line 495] 
	 main
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/mail/app/nsMailApp.cpp
 line 58] 
	 kernel32.dll + 0x16d4f (0x7c816d4f)   
 
     (1840256)	Comments: reader a large newsgroup  thunderbird crashed
     (1820109)	Comments: looking at a newsgroup and trying to bring it up to date
     (1801878)	Comments: marking a whole newsgroup read
     (1787725)	Comments: Marking a news group as read.  The news group had over
6000 unread items
     (1771330)	Comments: swithed to TB 0.8 after yet another Newsgroup failure
in 0.8  had the same thing happen again.  looks like the software is not
handeling the read v. unread counts correctly as it dispalys the entire
newsgroup (one that causes a failure and this isn't
     (1771330)	Comments:  always the same one) as unread  when I have read it
earlier and marked it read.  there should only be a small number of unreads. 
Once I see thie big number of unreads  I know that marking that group unread
will crash Thunderbird..  This has happende
     (1771330)	Comments:  with more than i news group so I doubt it is a
particular news group or data that is causing the probelm.
     (1741761)	URL: news.grc.com - newsgroup "Techtalk"
     (1741761)	Comments: Marking all newsgroup messages as "Read".  Very large
number of msgs - over 100 000.
     (1739892)	Comments: Clicked on "mark all newgroup read" on newsgroup
nl.markt.freelance. This happens every time in said newsgroup  but only these
past couple of weeks.
     (1730995)	Comments: marking a newsgroup read
     (1714465)	Comments: I marked my newsgroup as read. My prefs.js file is
probably corrupt - at least it behaves strangely.

Comment 22

[Jay Patel [:jay]]

As Bienvenu said in comment #14, this might be the result of bad newsrc files. 
If that is the case, is there anything we can do on our end to prevent the crash
(since we have no control over the content of newsrc files for these newsgroups)?

Comment 23

[David :Bienvenu]

I tried munging my newsrc in all sorts of ways and couldn't reproduce the crash.
But maybe I'm not corrupting it in the right sort of way. Maybe someone could
attach their newsrc if they have one that reliably reproduces the problem.

Comment 24

[Olivier Cahagne]

not sure if it helps, I captured a NNTP log available as attachment 160313 [details] from
bug 261896.

Comment 25

[Marcia Knous [:marcia]]

Need a patch at this point for 1.0. Feel free to renominate when that happens.

Comment 26

[greg.bugnon]

Systematic crashes here as well: 

I suscribed to 8 newsgroup in TB some time ago, and for some reason _all_ the
subjects in two of them of them are bold as if they weren't read. I usually mark
all of them as read before quitting the prog.

More precisely,

-When TB is opening, I can see on the newsgroup server on the left column with
all the groups within expanded. The number in the parentheses for those 2
specific group is big,  like 32900 and 14500, and shouldn't be because they were
indicated as read in previous sessions.

-Then as usual while TB is opening it automaticaly checks the ng server and
updates this nubmer in the parentheses, and it seems like it reports the
appropriate number of non-read messages, like 220 and 140.

-But, when I click on them on the left column to select them, this number
changes again to return the previous huge value, and as expected then list all
subjects as non-read.

-Then CTRL+SHIFT+C --> Crash

Note1: When instead of doing the CTRL+SHIFT+C I select another group and then
return to one of the affected one, the huge number is updated again with
systematic 6331 more non-read messages (82303->886634->etc.). the increment
changes with each new TB session.

I also did a sort of diff (i did that w examdiff since I don't know other win
diff command) between 2 increments on the msf file to see if I could figure
something, but I didn't. I just noticed that what was wrongly added is somthing
shorter:

{B579:^80 {(k^98:c)(s=9)471:m } B579 B611 B5B9 }
{AA79:^80 {(k^98:c)(s=9)273:m } AA79 AA88 AA91 AA8E AA9B AAE6 AA8F }
{A4F9:^80 {(k^98:c)(s=9)168:m } A4F9 A520 A51F A521 }
{9F79:^80 {(k^98:c)(s=9)70:m } 9F82 9F79 9F8B }
{AFFC:^80 {(k^98:c)(s=9)384:m } B0AD AFFC }
{AA7C:^80 {(k^98:c)(s=9)274:m } AA7C AA80 AA7E AAC5 }
{AA7F:^80 {(k^98:c)(s=9)275:m } AA7F AA85 AA84 AAAF AA9D }
{FFFFFFFD:^9A {(k^99:c)(s=9)} [9C4A(^94^83)]

then this is what is wrongly appended:

  [9C4B(^94^8C)]
  [9C4D(^94^9C)]
  [9C4E(^94^A5)]
  [9C4F(^94^AC)]
  [9C50(^94^B4)]
  [9C51(^94^BD)]
  [9C52(^94^C7)]
  [9C54(^94^D4)]

Don't know if it helps though..

Note2: unsuscribing within TB and then suscribing again the same group does not
fix the wrong huge number of non-read messages, its always the last wrong huge
number that was there before unsuscribing. You have to manually delete the .dat
and .msf affected files in local user TB directory after unsuscribing to solve
the pb.

TB2349910W
TB2348575Y
TB2349557Q
+ others associated w my mail address

Comment 27

[Philip Pawley]

Greg's description ([e-mail] - comment #26)fits my problem very closely.
His solution of unsubscribing from the affected groups and deleting the .dat and
.msf files, then re-subscribing worked for me.

I wonder whether this is any clue: when I first subscribed, I was a bit
impatient and started downloading headers on more newsgroups before the first
had finished. (Some of the groups were quite large, the largest had 120,000-plus
headers). These were goups at news.grc.com BTW.

If you folks have any tests you would like me to do, just ask. 

Comment 28

[greg.bugnon]

I kept one of those affected newsgroup to test some things on it. 
I realized when browsing it that almost all threads have duplicates (~90%). I
took snapshots of the problem: 

http://greg.bugnon.free.fr/TB_1.0RC1_1.png
http://greg.bugnon.free.fr/TB_1.0RC1_2.png 

When I click on one of the thread: 
it always mark it as read (lose bold attribute) but also mark the initial thread
it sometimes mark all duplicate threads as read.

Another "good" reproductible bug is I that i can manually duplicate threads with
expanding and collapsing (not really working) thread when clicking on parent
cross. Snapshots here:

each new image corresponds to previous state plus one click over the cross to
expand or collapse thread

http://greg.bugnon.free.fr/test1.png
http://greg.bugnon.free.fr/test2.png
http://greg.bugnon.free.fr/test3.png
http://greg.bugnon.free.fr/test4.png
http://greg.bugnon.free.fr/test5.png
http://greg.bugnon.free.fr/test6.png
etc..
http://greg.bugnon.free.fr/testn.png
http://greg.bugnon.free.fr/testn+1.png

Hope it helps :)

Comment 29

[greg.bugnon]

I've been able to corrupt a previously working newsgroup so that all previously
described bugs work on it.

Steps:
-Start TB session and suscribe to a new newsgroup.
-Left click on it to select it, it will automaticaly start downloading subjects.
-Quit _while_ it is still downloading the threads'subjects. 
-Restart TB and then you can see at first that the number in parentheses is
appropirate and matches the exact number of already downloaded subject titles.
-But then, select it with left click and you can see it will redownload all of
the subjects, as if you din't downloaded anything previously.
-All previously threads started with the first download will get filled of the
second fresh downloaded messages inside them thus starting the "corruption".
-The brand new ng can then crash TB, and the same bugs observed in previous pics
can be reproduced.

BTW i don't know if it is the correct behavior, but if I write two new messages
in a newsgroup with the exact same title (i.e. only using write not reply), then
the second message will be placed inside the previous thread started with the
first message. 

Comment 30

[David :Bienvenu]

Attachment: possible fix

we were not handling failures to open the news db. This code will delete the
invalid db and open an empty one to get repopulated.

Comment 31

[David :Bienvenu]

Comment on attachment 167966 [details] [diff] [review]
possible fix

I'm not 100% sure this will fix the crash, but lots of bad things could happen
if we ignore the error.

Comment 32

[David :Bienvenu]

Attachment: fix for imap case

imap needs to do something similar - I think this explains some of the
stopwatch problems people see clicking on imap folders.

Comment 33

[David :Bienvenu]

patch checked in.

Comment 34

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #30)
> Created an attachment (id=167966)
> possible fix
> 
> we were not handling failures to open the news db. This code will delete the
> invalid db and open an empty one to get repopulated.

David, the behavior of creating duplicates by aborting a download was described
by myself in bug 271537. I don't think that deleting and creating an empty db
file is a good solution. Do you also delete the .msf file? If yes, all labels
and watched threads will be deleted by this action. That's an bad idea if it
appears after weeks of reading the newsgroup. Should we discuss this here or in
the other bug?

Comment 35

[David :Bienvenu]

we have to delete invalid, corrupt db's, period. That's all we're doing. The db
shouldn't get corrupted when you do what you're doing (shutting down in the
middle of a download) but it is. I'll try to fix that as well, but we have to
throw away corrupt db's because we don't know how they're corrupt. Hopefully
there aren't too many ways of corrupting db's - that's the only one I know of
right now.