**** 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

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

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.

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.

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.

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

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.

Taking bugs from bhuvan.

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.

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.

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

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

Discussed in Mail News bug meeting. Decided to [ADT3] this bug.

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

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.

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.

changing back. If we had a fix for this we'd take it.

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...

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.

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).

Navin, can I get an r=? thx.

Comment on attachment 80806 [details] [diff] [review] proposed fix sr=sspitzer thanks for fixing this, david.

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.

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...

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"); + }

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.

Comment on attachment 80869 [details] [diff] [review] patch addressing Navin's comments r=naving

Comment on attachment 80869 [details] [diff] [review] patch addressing Navin's comments sr=sspitzer

adding adt1.0.0 nomination.

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.

fixed on trunk, waiting for driver approval.

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

fixed on branch

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

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.

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)

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.

removing the adt1.0.0+. Let's try to get this for rtm.

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.

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?

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.

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 #.

the fix in bug 138217 is required to fix this on the branch. I'll submit the patch in a minute.

this last patch is also required.

removing verified1.0.0 and renominating.

Removing adt1.0.0, as this has been reopened.

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.

adding the adt1.0.0 back. The new patch was already checked in. We just need this on the branch now.

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.

adding adt1.0.0+. Please get drivers approval and then check into the 1.0 branch.

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.

changing to adt1.0.1+ for checkin to the 1.0 branch. Please get drivers approval before checking in.

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.

fixed on 1.01 branch

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.