Deleting news account doesn't remove newsgroups/eventually crash [@ nsMsgKeySet::IsMember]

VERIFIED FIXED in mozilla1.0

Status

--
major
VERIFIED FIXED
17 years ago
14 years ago

People

(Reporter: marina, Assigned: Bienvenu)

Tracking

({crash})

Trunk
mozilla1.0
crash

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ADT2 rtm], crash signature)

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

17 years ago
**** observed with 2002-02-25 build ***
Steps to reproduce:
- go to the Account manager (Edit|Mail/Newsgroup settings)
- select a news account;
- remove it, ok the prompt whether you want to remove it;
- now create a new news account;
//note: when the account is in the left pane you see the old newsgroups under
the tree, would you select one of them you would be asked whether you want to
subscribe,trying to subscribe loops indefinetely on Mac and crashes on WinNT
(Reporter)

Comment 1

17 years ago
i crash when i am trying to select a message that shows as if you are subscribed
, here is a stack ( btw; i can reproduce the crash on Mac as well):
Stack Trace
nsMsgKeySet::IsMember
[d:\builds\seamonkey\mozilla\mailnews\base\util\nsMsgKeySet.cpp, line 632]
nsNewsDatabase::IsRead
[d:\builds\seamonkey\mozilla\mailnews\db\msgdb\src\nsNewsDatabase.cpp, line 214]
nsNewsDatabase::IsHeaderRead
[d:\builds\seamonkey\mozilla\mailnews\db\msgdb\src\nsNewsDatabase.cpp, line 228]
nsMsgDatabase::GetStatusFlags
[d:\builds\seamonkey\mozilla\mailnews\db\msgdb\src\nsMsgDatabase.cpp, line 1598]
nsMsgHdr::GetFlags
[d:\builds\seamonkey\mozilla\mailnews\db\msgdb\src\nsMsgHdr.cpp, line 208]
nsMsgDBFolder::HasMsgOffline
[d:\builds\seamonkey\mozilla\mailnews\base\util\nsMsgDBFolder.cpp, line 922]
nsNntpService::DisplayMessage
[d:\builds\seamonkey\mozilla\mailnews\news\src\nsNntpService.cpp, line 295]
nsMessenger::OpenURL
[d:\builds\seamonkey\mozilla\mailnews\base\src\nsMessenger.cpp, line 587]
nsMsgDBView::LoadMessageByMsgKey
[d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 891]
nsMsgDBView::SelectionChanged
[d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 930]
XPTC_InvokeByIndex
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp,
line 106]
XPCWrappedNative::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 2000]
XPC_WN_CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp,
line 1267]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 834]
js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2803]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 850]
js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 925]
JS_CallFunctionValue [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 3417]
nsJSContext::CallEventHandler
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 1019]
nsJSEventListener::HandleEvent
[d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 182]
nsEventListenerManager::HandleEventSubType
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1218]
nsEventListenerManager::HandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1821]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3383]
nsOutlinerSelection::FireOnSelectHandler
[d:\builds\seamonkey\mozilla\layout\xul\base\src\outliner\src\nsOutlinerSelection.cpp,
line 738]
nsOutlinerSelection::Select
[d:\builds\seamonkey\mozilla\layout\xul\base\src\outliner\src\nsOutlinerSelection.cpp,
line 369]
XPTC_InvokeByIndex
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp,
line 106]
XPCWrappedNative::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 2000]
XPC_WN_CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp,
line 1267]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 834]
js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2803]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 850]
js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 925]
JS_CallFunctionValue [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 3417]
nsJSContext::CallEventHandler
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 1019]
nsJSEventListener::HandleEvent
[d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 182]
nsXBLPrototypeHandler::ExecuteHandler
[d:\builds\seamonkey\mozilla\content\xbl\src\nsXBLPrototypeHandler.cpp, line 442]
DoMouse [d:\builds\seamonkey\mozilla\content\xbl\src\nsXBLDragHandler.cpp, line 115]
nsXBLMouseHandler::MouseDown
[d:\builds\seamonkey\mozilla\content\xbl\src\nsXBLMouseHandler.cpp, line 124]
nsEventListenerManager::HandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1307]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3383]
PresShell::HandleEventInternal
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6010]
PresShell::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5928]
nsViewManager::HandleEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 2010]
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 301]
nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1849]
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 83]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 858]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 875]
nsWindow::DispatchMouseEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4579]
ChildWindow::DispatchMouseEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4829]
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3504]
nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1120]
USER32.dll + 0x1820 (0x77e71820)
0x015f0053 
(Reporter)

Updated

17 years ago
OS: MacOS X → All
Summary: Deleting news account doesn't get read of newsgroups → Deleting news account doesn't remove newsgroups/eventually crash

Comment 2

17 years ago
Trunk build 2002-03-01: Mac OS/X
I reproduced the crash.

- I had many mail accounts so collapsed all of them so there was plenty of room
for the news account and its news groups (alt.surfing)to display.
- removed the news account and without closing Account Settings
- added the same news account back in
- Closed Account Settings

Actual Results: The newsgroups that I had been subscribed to earlier
(alt.surfing) was there. I was able to subscribe to a different newsgroup but
when I select alt.surfing then it crashed immediately.

Note: I wasn't able to reproduce this earlier because my mail accounts were
expanded so the news account was off screen at the bottom. Once I maximized the
area for the news account then I saw the problems.

I will try the 2002-03-07 build once it installs.

Marking nsbeta1 since it's crashing.
Keywords: crash, nsbeta1

Comment 3

17 years ago
Trunk build 2002-03-07: Mac 10.1.3
Reproduced using Marina's steps so that after the account is readded the old
newsgroup appears (alt.surfing), select the newsgroup and it asks if you want to
subscribe, ok, then select a message in the thread pane and it crashes.

Comment 4

17 years ago
Discussed at Mail News bug mtg with Mktng, Eng, PjM.  Decided to plus this bug.
 Also to mark bug 123038 a dupe of this bug, which has move info in it.
Keywords: nsbeta1 → nsbeta1+
Summary: Deleting news account doesn't remove newsgroups/eventually crash → Deleting news account doesn't remove newsgroups/eventually crash [@ nsMsgKeySet::IsMember]
Target Milestone: --- → mozilla1.0

Comment 5

17 years ago
*** Bug 123038 has been marked as a duplicate of this bug. ***

Comment 6

17 years ago
I tried the steps that both marina and ninoschka had mentioned with my build as
well as a release build.
The chosen newsgroup( I stuck to alt.surfing:-) ) did show up with the message.
When I clicked on the newsgroup there was a dialog box that asked whether I
wanted to subscribe to the newsgroup. Irregardless of what I chose( CANCEL or
OK) and then clicked on a message it didnt crash. Though in the case of cancel -
there was this appearance of something going on (mouse turning into hourglass)
but that didnt prevent me from going to other accounts or reading other mail,
news or otherwise.

Suggest we either find another way of reproducing the crash or we can probably
minus this one or leave it as a major bug because we dont want previously
subscribed newsgroups to show up after deleting the news server.

Updated

17 years ago
Whiteboard: Not able to reproduce - wfm?

Comment 7

17 years ago
Taking bugs from bhuvan.
Assignee: racham → varada

Comment 8

17 years ago
I couldn't reproduce this bug either using the steps.  But, the stack for this
crash is still showing up in talkback as of 3/22.
(Reporter)

Comment 9

17 years ago
i am able to reproduce this bug (meaning crash) with 03-26 build with a
different profile. The problem that when we remove an account (news in this
case) and then add it again without exiting the application shows newsgroups
that you were previosly subscribed to. We have to fix this problem but to crash
with 03-26 build all you have to do is to "OK" the prompt whether you want to
subscribe to the following newsgroups.
Same here, 2002-03-26-03, Win2k using secnews.netscape.com.
(Reporter)

Comment 11

17 years ago
it might be win2k problem ( i am as Stephen on win2k) but i doubt that...

Comment 12

17 years ago
I reproduced the crash on my WinMe system.
Incident# 4530315.

Comment 13

17 years ago
Discussed in Mail News bug meeting. Decided to [ADT3] this bug.
Whiteboard: Not able to reproduce - wfm? → Not able to reproduce - wfm?,[ADT3]

Comment 14

17 years ago
Trunk build 2002-03-27: WinMe
More incident numbers (4573692, 4573306)  

Comment 15

17 years ago
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1-

Comment 16

17 years ago
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1+

Comment 17

17 years ago
changing back.  If we had a fix for this we'd take it.
Keywords: nsbeta1- → nsbeta1+
Whiteboard: Not able to reproduce - wfm?,[ADT3] → Not able to reproduce - wfm?,[ADT2]
(Assignee)

Comment 18

17 years ago
I can reproduce this - not sure why Varada couldn't...I'll fix it. The problem
is almost certainly that m_keySet is not valid anymore. I wonder if we're not
closing down the nntp connections when we remove the server and running into a
problem using a cached connection...
Assignee: varada → bienvenu
(Assignee)

Comment 19

17 years ago
updating status whiteboard. The problem is that there's a circular reference
between the nntp protocol object and the nntp incoming server (the protocol
object points to the server, and the server has a list of protocol objects). We
can either use a weak reference in the protocol object (but that would involve
changing a lot of code), or we can break the link when removing the account.
Whiteboard: Not able to reproduce - wfm?,[ADT2] → [ADT2]
(Assignee)

Comment 20

17 years ago
Created attachment 80806 [details] [diff] [review]
proposed fix

fix is basically to shutdown the folders on the removed account - I needed to
move up the forgetting of the passwords because it needs the server to be still
set on the folder (shutdown clears the server).
(Assignee)

Comment 21

17 years ago
Navin, can I get an r=? thx.
Comment on attachment 80806 [details] [diff] [review]
proposed fix

sr=sspitzer

thanks for fixing this, david.
Attachment #80806 - Flags: superreview+

Comment 23

17 years ago
Comment on attachment 80806 [details] [diff] [review]
proposed fix

we do something similar in 
hashLogoutOfServer, probably 
we could add a helper method

+    server->CloseCachedConnections();
+    // need to forget pasword before we shutdown folders.
+    rv = server->ForgetPassword();
+    NS_ASSERTION(NS_SUCCEEDED(rv), "failed to remove the password associated
with server");
+

Also if we call shutdown(PR_TRUE); you can
remove that ForceDBClosed() call just  
below it because folder's
db will already have been
nulled out.
(Assignee)

Comment 24

17 years ago
ForceDBClosed actually forces the db closed; nulling out the db is no guarantee
that the db will get closed, so that comment is wrong.

I'm not inclined to add yet another interface to nsIMsgIncomingServer for these
two lines of code...

Comment 25

17 years ago
folder->ForceDBClosed() will check for mDatabase (so that it can do
mDatabase->ForceClosed()) which will be nulled out by
folder->Shutdown(PR_TRUE)

I was suggesting adding a helper function to nsMsgAccountManager.h

nsresult
nsMsgAccountManager::LogoutOfServer(nsIMsgIncomingServer *aServer)
{
+    server->CloseCachedConnections();
+    // need to forget pasword before we shutdown folders.
+    rv = server->ForgetPassword();
+    NS_ASSERTION(NS_SUCCEEDED(rv), "failed to remove the password associated
with server");
+
}
(Assignee)

Comment 26

17 years ago
so, what you meant to say is that the force closed should be called before the
shutdown call? Good catch, that's true; I'll fix that.
(Assignee)

Comment 27

17 years ago
Created attachment 80869 [details] [diff] [review]
patch addressing Navin's comments

Comment 28

17 years ago
Comment on attachment 80869 [details] [diff] [review]
patch addressing Navin's comments

r=naving
Attachment #80869 - Flags: review+
Comment on attachment 80869 [details] [diff] [review]
patch addressing Navin's comments

sr=sspitzer
Attachment #80869 - Flags: superreview+

Comment 30

17 years ago
adding adt1.0.0 nomination.
Keywords: adt1.0.0
adt1.0.0+ (on ADT's behalf) for checkin to 1.0. Pls check this in today, after
you receive Drivers approval. Then, add the fixed1.0.0 keyword.
Keywords: adt1.0.0 → adt1.0.0+, approval
Whiteboard: [ADT2] → [ADT2] [Needs a=]
(Assignee)

Comment 32

17 years ago
fixed on trunk, waiting for driver approval.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Comment on attachment 80869 [details] [diff] [review]
patch addressing Navin's comments

a=asa (on behalf of drivers) for checkin to the 1.0 branch
Attachment #80869 - Flags: approval+
(Assignee)

Comment 34

17 years ago
fixed on branch
Keywords: fixed1.0.0
Whiteboard: [ADT2] [Needs a=] → [ADT2]
*** Bug 140181 has been marked as a duplicate of this bug. ***
QA Contact: nbaca → stephend
I'm thinking that I'll probably have to spin off a separate bug for the problem
I'll describe below:

1) Have a news server selected (choose one with a subscribed newsgroup), bring
up Account Manager.
2) Remove the account, then re-add it.
3) Once you've re-added it, the same group re-appears and once you click on it,
no messages are populated (it's like our cache is empty, but happy).

Could this be a result of http://bugzilla.mozilla.org/show_bug.cgi?id=94967#c1

If so, I'll just file the above scenario.  I don't crash on builds 2002-04-26 on:

Mac OS X 10.1.4
Windows 2000
Mandrake 8.1

But, I had a very similar but slightly different stack that I'll investigate in
this area (it starts with nsMsgKeySet::Output(), then
nsMsgNewsFolder::UpdateSummaryFromNNTPInfo()).

David, that crash stack is shown in
http://climate.netscape.com/reports/SingleIncidentInfo.cfm?dynamicBBID=5657942

Verified for the BRANCH, trunk is next. 
Keywords: fixed1.0.0 → verified1.0.0
Hardware: PC → All
Okay, this doesn't appear to be fixed, either on the trunk or the branch.

Although I'm not seeing the nsMsgKeySet::IsMember stack, others do:
5803791  2002043010   MozillaTrunk   Windows NT 5.0 build 2195   2002-04-30
23:49:54   nsMsgKeySet::IsMember 7e853fff   2038   3640   google.com

I *do* see nsMsgKeySet::Output() (doing the same steps), here's my full stack:

Stack Signature nsMsgKeySet::Output 65781b7b
Email Address stephend@netscape.com
Product ID NetscapeXXX
Build ID 2002050108
Trigger Time 2002-05-01 10:43:10
Platform Win32
Operating System Windows NT 5.0 build 2195
Module msgbsutl.dll
URL visited http://bugzilla.mozilla.org/show_bug.cgi?id=127707
User Comments Crashed trying to reproduce bug 127707
http://bugzilla.mozilla.org/show_bug.cgi?id=127707
Trigger Reason Access violation
Source File Name d:uildsseamonkeymozillamailnewsaseutil
sMsgKeySet.cpp
Trigger Line No. 315
Stack Trace
nsMsgKeySet::Output
[d:uildsseamonkeymozillamailnewsaseutil
sMsgKeySet.cpp, line 315]
nsMsgNewsFolder::UpdateSummaryFromNNTPInfo
[d:uildsseamonkeymozillamailnews
ewssrc
sNewsFolder.cpp, line 797]
nsNntpIncomingServer::DisplaySubscribedGroup
[d:uildsseamonkeymozillamailnews
ewssrc
sNntpIncomingServer.cpp, line 705]
nsNNTPProtocol::DisplayNewsRCResponse
[d:uildsseamonkeymozillamailnews
ewssrc
sNNTPProtocol.cpp, line 4172]
nsNNTPProtocol::ProcessProtocolState
[d:uildsseamonkeymozillamailnews
ewssrc
sNNTPProtocol.cpp, line 5266]
nsMsgProtocol::OnDataAvailable
[d:uildsseamonkeymozillamailnewsaseutil
sMsgProtocol.cpp, line 306]
nsOnDataAvailableEvent::HandleEvent
[d:uildsseamonkeymozilla
etwerkasesrc
sStreamListenerProxy.cpp, line 202]
PL_HandleEvent [d:uildsseamonkeymozillaxpcom	hreadsplevent.c, line 597]
PL_ProcessPendingEvents [d:uildsseamonkeymozillaxpcom	hreadsplevent.c,
line 530]
_md_EventReceiverProc [d:uildsseamonkeymozillaxpcom	hreadsplevent.c, line
1078]
nsAppShellService::Run
[d:uildsseamonkeymozillaxpfeappshellsrc
sAppShellService.cpp, line 309]
main1 [d:uildsseamonkeymozillaxpfeootstrap
sAppRunner.cpp, line 1434]
main [d:uildsseamonkeymozillaxpfeootstrap
sAppRunner.cpp, line 1769]
WinMain [d:uildsseamonkeymozillaxpfeootstrap
sAppRunner.cpp, line 1787]
WinMainCRTStartup()
KERNEL32.DLL + 0xd326 (0x77e8d326)

Re-opening. Removing verified1.0.0, adding the new related stack to the summary
(nsMsgKeySet::Output)
Severity: normal → major
Status: RESOLVED → REOPENED
Keywords: verified1.0.0
Resolution: FIXED → ---
Summary: Deleting news account doesn't remove newsgroups/eventually crash [@ nsMsgKeySet::IsMember] → Deleting news account doesn't remove newsgroups/eventually crash [@ nsMsgKeySet::IsMember nsMsgKeySet::Output]
(Assignee)

Comment 38

17 years ago
Stephen, I think we need new reproducible steps to recreate this bug. I believe
the steps we used to have work fine now (though you can verify that if you
like...) and it follows that there is some other scenario that can lead to this
crash.

Comment 39

17 years ago
removing the adt1.0.0+.  Let's try to get this for rtm.
Keywords: adt1.0.0+
Whiteboard: [ADT2] → [ADT2 rtm]
(Reporter)

Comment 40

17 years ago
Stephen, i used the steps of my initial bug report to reproduce the problem and
i wasn't able to with 2002-05-01 trunk build. It seems to be fixed ( the news
account got removed). What are the steps you used to get a crash?
Okay, I've failed to reproduce the nsMsgKeySet::IsMember crash, and lately I'm
having problems (on a new profile) reproducing the nsMsgKetSet::Output crash - I
need to whittle away the steps to reproduce before I file a new bug.

Although, someone has still crashed in nsMsgKeySet::IsMember with the
2002-04-30-10  Windows 2000 build - no steps to reproduce, either.

I'm not sure what to do about this bug - sorry for the snafu, but for 4 times
straight the crash in nsMsgKeySet::Output was reproducible 100%, using the same
steps:

1.  Add a news server, subscribe to a group.
2.  Go to the Account Manager, remove the account.
3.  In the same session, re-add the account.
4.  It'll populate that group, click on it and you'll be prompted to confirm
subscription to the account, which you say "OK" to.
5.  This is where I crashed in the global Output() method.

Since I can no longer reproduce either crash, I'll remove the output stack from
the bug, and leave it open for us to decide what to do about the single crash in
nsMsgKeySet::IsMember on the 30th...

Also, I see that re-adding the server and having it populate the newsgroups that
you had before, is probably a result of
http://bugzilla.mozilla.org/show_bug.cgi?id=94967#c1

Re-adding verified1.0.0, for the time being, since like I said I can't reproduce
using Marina's steps...  Sorry.
Keywords: verified1.0.0
Summary: Deleting news account doesn't remove newsgroups/eventually crash [@ nsMsgKeySet::IsMember nsMsgKeySet::Output] → Deleting news account doesn't remove newsgroups/eventually crash [@ nsMsgKeySet::IsMember]
(Assignee)

Comment 42

17 years ago
Stephen, I can't tell if were/are using a branch build or a trunk build. Also,
if when you add the server back, you're getting all the old subscribed groups
back, then that's the cause of the crash. Those subscribed groups should have
been cleared out when we unload the server...
I was using today's commercial Mozilla 1.0 branch build - the person who crashed
on 4-30 with Windows 2000 in nsMsgKeySet::IsMember was using MozillaTrunk.

Yes, I'm still getting my previously subscribed newsgroups returned on addition
of my previously removed account - I thought this might be a separate bug -
since the summary state 'Deleting news account doesn't remove newsgroups' - it
has no mention of what happens when we add it back.

Your fix was to clear the news cache in general?  
(Reporter)

Comment 44

17 years ago
in today's branch build i see same as Stephen does: the first impression is that
the news account(news.mcom.com is removed after you select the Remove option on
the Account wizard) because it doesn't show up in the account central, then if
you add this account again it'll show up with all prevviously existing
newsgroups, they have no articles though and do not crash.
(Assignee)

Comment 45

17 years ago
for the branch, it turns out this relies on getting another fix in, adding
mSubFolders->Clear() to nsMsgFolder::Shutdown. I thought that was going to get
checked in but it doesn't seem to have been. I'll go look for the bug #.
(Assignee)

Comment 46

17 years ago
the fix in bug 138217 is required to fix this on the branch. I'll submit the
patch in a minute.
(Assignee)

Comment 47

17 years ago
Created attachment 84308 [details] [diff] [review]
patch required from trunk

this last patch is also required.
Attachment #80806 - Attachment is obsolete: true
Attachment #80869 - Attachment is obsolete: true

Comment 48

17 years ago
removing verified1.0.0 and renominating.
Keywords: verified1.0.0 → adt1.0.0
Removing adt1.0.0, as this has been reopened.
Keywords: adt1.0.0, approval
(Assignee)

Comment 50

17 years ago
this is fixed on the trunk - deleting the account and re-adding it doesn't
result in the newsgroups reappearing, right, Stephen? There might be other
instances of that stack trace crash, but case of it is fixed on the trunk.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 51

17 years ago
adding the adt1.0.0 back.  The new patch was already checked in.  We just need
this on the branch now.
Keywords: adt1.0.0
David, correct - deleting a news account via the Account Manager and readding it
in the same session does not repopulate the server with newsgroups you had
subscribed to before.  There are a few other stacks in nsMsgKeySet::, but I
haven't nailed down the steps to see those global methods crash.

Comment 53

17 years ago
adding adt1.0.0+.  Please get drivers approval and then check into the 1.0 branch.
Keywords: adt1.0.0 → adt1.0.0+
Verified FIXED on the trunk with builds:

Windows 2000 - latest trunk (self-built)
Redhat 7.3 - 2002-05-25-07
Mac OS X 10.1.14 - 2002-05-24-08

David/Putterman/ADT - this is fine on the trunk.
Status: RESOLVED → VERIFIED

Comment 55

17 years ago
changing to adt1.0.1+ for checkin to the 1.0 branch.  Please get drivers
approval before checking in.
Keywords: adt1.0.0+ → adt1.0.1+

Comment 56

17 years ago
please checkin to the 1.0.1 branch ASAP. once there please remove the
mozilla1.0.1+ keyword and add the fixed1.0.1 keyword.
Keywords: mozilla1.0.1+
(Assignee)

Comment 57

17 years ago
fixed on 1.01 branch
Keywords: mozilla1.0.1+ → fixed1.0.1
This fix is working fine now on all 2002-05-31 Mozilla1.0.1 Branch builds
(commercial):

Mac OS X 10.1.4, Mac OS 9.2.2, Windows 2000, RedHat Linux 7.3

Verified FIXED on branch, replacing fixed1.0.1 with verified1.0.1.
Keywords: fixed1.0.1 → verified1.0.1

Updated

16 years ago
Blocks: 149110
Product: Browser → Seamonkey
Crash Signature: [@ nsMsgKeySet::IsMember]
You need to log in before you can comment on or make changes to this bug.