This is a topcrasher with Mozilla 0.9.4. It's happeing with all flavors of Windows. Here is the latest info from Talkback reports: A recent incident: Incident ID 35639793 Stack Signature nsMsgDBEnumerator::PrefetchNext 227d3256 Bug ID Trigger Time 2001-09-20 06:33:38 Email Address User Comments Build ID 2001091311 Product ID Netscape6.20 Platform ID Win32 Trigger Reason Access violation Stack Trace nsMsgDBEnumerator::PrefetchNext [d:\builds\seamonkey\mozilla\mailnews\db\msgdb\src\nsMsgDatabase.cpp, line 2240] nsMsgDBEnumerator::GetNext [d:\builds\seamonkey\mozilla\mailnews\db\msgdb\src\nsMsgDatabase.cpp, line 2210] nsNewsDatabase::GetLowWaterArticleNum [d:\builds\seamonkey\mozilla\mailnews\db\msgdb\src\nsNewsDatabase.cpp, line 250] nsNNTPNewsgroupList::GetRangeOfArtsToDownload [d:\builds\seamonkey\mozilla\mailnews\news\src\nsNNTPNewsgroupList.cpp, line 238] nsNNTPProtocol::FigureNextChunk [d:\builds\seamonkey\mozilla\mailnews\news\src\nsNNTPProtocol.cpp, line 3419] nsNNTPProtocol::ProcessProtocolState [d:\builds\seamonkey\mozilla\mailnews\news\src\nsNNTPProtocol.cpp, line 5136] nsMsgProtocol::OnDataAvailable [d:\builds\seamonkey\mozilla\mailnews\base\util\nsMsgProtocol.cpp, line 246] nsOnDataAvailableEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamListenerProxy.cpp, line 188] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 591] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 524] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1072] And some more user comments: (35567345) URL: es.comp.os.linux.misc (35567345) Comments: For once I know why/when this happened.I just set up a newsgroup account using news.terra.es and subscribed to a pair of newsgroups. I downloaded headers for the first group but decided it wasn't what I wanted and clicked on unsubscribe for that (35567345) Comments: group in the left menu (where your mail folders are listed). Then I right clicked on the second group and hit unsubscribe and confirmed. While I did this Mozilla was downloading the headers and just after confirming the unsubscribe it crashed. (35564769) URL: http://www.fileplanet.com (35564769) Comments: Unsubscribing from newsgroups by right-clicking on them and choosing "Unsbscribe" (35531304) Comments: unsubscribing from a couple of newsgroups (35531266) Comments: unsubscribing from a couple of newsgoups (35466564) Comments: 1) Upgraded to 0.9.4 the day before.2) in mail2news opened a news server folder. It started contemplating the subscribed groups some of which hadd 500+ message headers still to download across my 33K link.3) While it was doing this I unsubscribed (35466564) Comments: from ~3 of those groups.The unsubscription went ok but then a minute or so later it brought up the "how many headers to download" dialog. I cancelled the first two & then it crashed. I don't know if there were any other such groups it had yet to get (35466564) Comments: to. (35465846) Comments: Unsubscribing from last subscribed newsgroup on a nntp server
This is actually bug 87686, but I'll mark that a dup of this, and just add steps to reproduce here.
*** Bug 87686 has been marked as a duplicate of this bug. ***
Reproducible: Always Steps to Reproduce: 1. Subscribe to a large/active newsgroup with more than 300 new headers. 2. Right click on the group. Both the context menu and the dialog should appear. Do not click on anything else yet. 3. Unsubscribe from the group via the context menu. The group will be removed from the list, but the download dialog will remain visible and active. 4. Click "download" in the dialog.
I couldn't reproduce with stephend's steps, so here are the steps I used: 1. Subscribe to a large group, for example alt.politics 2. Click on alt.politics and hit "Delete" (to bring up the Unsubscribe dialog) quickly. 3. Now click OK in the unsubscribe dialog. Now you hopefully only have the "Download Headers" dialog, and clicking Download there will make us crash. We are crashing in |nsMsgDBEnumerator::PrefetchNext()| because |GetRowCursor()| returns a null mRowCursor. We only check for successful return values, no null-checls. I tried to null-check in |nsMsgDBEnumerator::PrefetchNext()|, and accordingly return a NS_ERROR_NULL_POINTER but that made mork crazy spitting out an inifinite number of assertions. This topcrash is a DB issue, so handing over to bienvenu. Hope this info is useful.
what's going on here, almost certainly, is that unsubscribe is deleting the database out from under the code that's downloading headers.
I'm having trouble accessing talkback right now to see if this is still occurring on recent builds. Since it's a topcrash I'm changing the milestone and the priority. If someone has new information on this on 0.9.5 and later builds, please update. It sounds like we should try to solve this through the UI. I'm sure we have other bugs about not allowing right click to load folders. If the newsgroup didn't start loading, then hitting unsubscribe would not have been an issue. I don't know if we can tell if we're in the middle of loading a folder. If we can, then maybe we should let items like delete and unsubscribe fail.
Putterman, I think that is bug 30560.
I got through to talkback. This was is still happening in 10/11 builds and is getting hit a lot.
*** Bug 105506 has been marked as a duplicate of this bug. ***
The most recent build with a crash is 10/12 and it's really only showing on the branch build. And, there were a lot of crashes happening. Could this have been fixed on the trunk since then?
i don't crash on the trunk( 2001-10-26 build), looks like it's gone (fixed:-)
This worksforme also.
I tried hwaara's testcase, and couldn't get my Win32 trunk to crash. Also, I ran a Talkback query for http://climate/reports/searchstacksignature.cfm? stacksig=nsMsgDBEnumerator%3A%3APrefetchNext, and found all of the crashers were either on the branch, or in the case of Marina's crash, 2001-10-12-05 Netscape6.20. I believe this to have gone away, based on all of the above information. Verified worksforme (why did this just go away??)
I doubt this is fixed - I'll try to reproduce it later. Re-opening so I don't forget.
jpatel, namachi, janc: is this still showing up in talkback for recent mozilla nightlies?
talkback hasn't seen this crash in a build newer than 10/22/01, assuming I'm using it correctly, which makes me think this is fixed. I could not reproduce this myself.
http://climate/reports/searchstacksignature.cfm?stacksig=nsMsgDBEnumerator%3A%3APrefetchNext This is FIXED. Talkback confirms it.