Closed Bug 71024 Opened 24 years ago Closed 24 years ago

crash on MSGNEWS.DLL when you rapidly select different messages

Categories

(SeaMonkey :: MailNews: Message Display, defect)

x86
All
defect
Not set
blocker

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: kcha-ns-yka, Assigned: bryner)

References

Details

(Keywords: crash)

Attachments

(5 files)

win32 build 2001030505, win98SE, but have seen this on other recent builds, too. I don't have Talkback, so figured I'd better file a bug. Crash: MSGNEWS.DLL attempted to use a null data pointer variable. Had been reading newsgroups on secnews.netscape.com for a while when this occurred out of the blue. Was reading a recent post in n.p.m.mail-news when this one happened. Dr Watson attached. The other times this has happened also appeared to be random acts. If I find a pattern, I'll certainly post it.
Attached file Dr Watson report (deleted) —
This is certainly valid. I haven't crashed in this dll lately, but we have a few crashers, confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: esther → stephend
*** Bug 71040 has been marked as a duplicate of this bug. ***
I'm seeing this problem on linux as well with both local builds and the 2001-03-06-08-Mtrunk nightly. The problem was a bit harder to reproduce with the nightly but I usually hit it within the first 10 messages I click on with my local builds. Bumping severity to blocker.
Severity: normal → blocker
Keywords: smoketest
OS: Windows 98 → All
*** Bug 71061 has been marked as a duplicate of this bug. ***
Added crash keyword and internal nomination for fix.
Keywords: crash, nsbeta1
Laurel's easy to reproduce steps from bug 71061: 1. Open a newsgroup. I used various groups on news.mozilla.org. 2. Select a news message in the thread pane, message pane is open. 3. Click 3 or 4 times on the selected message --> crashes either before or sometimes as the standalone message window opens.
Summary: crash on MSGNEWS.DLL → crash on MSGNEWS.DLL when you rapidly select different messages
CC:ing Doug Turner and Darin Fisher, who might know something about this (since mail/news hasn't been checking into the trunk much lately.)
I don't think so. The build that is being report as crashing is 2001030505, produced one day before I checked in.
Patrick, could it be any of your checkins on the 4th?
stephend@netscape.com, how about getting a stack trace?
I can't get a stack on dlls (if you show me how, I'll do so)
Here is the stack crawl: nsNNTPProtocol::Initialize(nsNNTPProtocol * const 0x04bcbae0, nsIURI * 0x04bcd9d4, nsIMsgWindow * 0x00000000) line 593 + 30 bytes nsNntpService::NewChannel(nsNntpService * const 0x08b62dd8, nsIURI * 0x04bcd9d4, nsIChannel * * 0x0012abdc) line 1339 + 29 bytes nsIOService::NewChannelFromURI(nsIOService * const 0x0177ed10, nsIURI * 0x04bcd9d4, nsIChannel * * 0x0012abdc) line 312 + 31 bytes NS_OpenURI(nsIChannel * * 0x0012adcc, nsIURI * 0x04bcd9d4, nsIIOService * 0x0177ed10, nsILoadGroup * 0x08402aa0, nsIInterfaceRequestor * 0x084040a4, unsigned int 0x00000000) line 110 + 20 bytes nsDocShell::DoURILoad(nsDocShell * const 0x08404080, nsIURI * 0x04bcd9d4, nsIURI * 0x00000000, nsISupports * 0x00000000, int 0x00000000, int 0x00000000, const char * 0x00000000, nsIInputStream * 0x00000000, nsIInputStream * 0x00000000) line 3197 + 58 bytes nsDocShell::InternalLoad(nsDocShell * const 0x08404080, nsIURI * 0x04bcd9d4, nsIURI * 0x00000000, nsISupports * 0x00000000, int 0x00000000, int 0x00000000, const char * 0x00000000, nsIInputStream * 0x00000000, nsIInputStream * 0x00000000, unsigned int 0x00000001, nsISHEntry * 0x00000000) line 3046 + 47 bytes nsDocShell::LoadURI(nsDocShell * const 0x08404080, nsIURI * 0x04bcd9d4, nsIDocShellLoadInfo * 0x00000000, unsigned int 0x00000000) line 440 + 65 bytes nsNntpService::DisplayMessage(nsNntpService * const 0x08b62dd4, const char * 0x04bbb0d0, nsISupports * 0x084041a4, nsIMsgWindow * 0x08b515c0, nsIUrlListener * 0x00000000, const unsigned short * 0x00000000, nsIURI * * 0x00000000) line 253 + 58 bytes nsMessenger::OpenURL(nsMessenger * const 0x08ab66a0, const char * 0x04bbb0d0) line 511 XPTC_InvokeByIndex(nsISupports * 0x08ab66a0, unsigned int 0x0000000b, unsigned int 0x00000001, nsXPTCVariant * 0x0012b410) line 139 nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x05f1ee70, nsXPCWrappedNative * 0x08ab4e40, const XPCNativeMemberDescriptor * 0x08ab522c, nsXPCWrappedNativeClass::CallMode CALL_METHOD, unsigned int 0x00000001, long * 0x00e029a4, long * 0x0012b5f8) line 940 + 42 bytes WrappedNative_CallMethod(JSContext * 0x05f1ee70, JSObject * 0x00ef6cd0, unsigned int 0x00000001, long * 0x00e029a4, long * 0x0012b5f8) line 250 + 34 bytes js_Invoke(JSContext * 0x05f1ee70, unsigned int 0x00000001, unsigned int 0x00000000) line 777 + 23 bytes js_Interpret(JSContext * 0x05f1ee70, long * 0x0012c378) line 2670 + 15 bytes js_Invoke(JSContext * 0x05f1ee70, unsigned int 0x00000001, unsigned int 0x00000002) line 794 + 13 bytes js_InternalInvoke(JSContext * 0x05f1ee70, JSObject * 0x00ef6c38, long 0x00ef7970, unsigned int 0x00000000, unsigned int 0x00000001, long * 0x0012c510, long * 0x0012c4a0) line 866 + 20 bytes JS_CallFunctionValue(JSContext * 0x05f1ee70, JSObject * 0x00ef6c38, long 0x00ef7970, unsigned int 0x00000001, long * 0x0012c510, long * 0x0012c4a0) line 3268 + 31 bytes nsJSContext::CallEventHandler(nsJSContext * const 0x05f19310, void * 0x00ef6c38, void * 0x00ef7970, unsigned int 0x00000001, void * 0x0012c510, int * 0x0012c50c, int 0x00000000) line 940 + 33 bytes nsJSEventListener::HandleEvent(nsIDOMEvent * 0x04bbabb4) line 154 + 64 bytes nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x082dc690, nsIDOMEvent * 0x04bbabb4, nsIDOMEventTarget * 0x07db9e18, unsigned int 0x00000008, unsigned int 0x00000007) line 838 + 19 bytes nsEventListenerManager::HandleEvent(nsIPresContext * 0x04bea920, nsEvent * 0x0012cdb8, nsIDOMEvent * * 0x0012cd48, nsIDOMEventTarget * 0x07db9e18, unsigned int 0x00000007, nsEventStatus * 0x0012cddc) line 1343 + 39 bytes nsXULElement::HandleDOMEvent(nsXULElement * const 0x07db9e10, nsIPresContext * 0x04bea920, nsEvent * 0x0012cdb8, nsIDOMEvent * * 0x0012cd48, unsigned int 0x00000001, nsEventStatus * 0x0012cddc) line 3574 nsXULTreeElement::FireOnSelectHandler(nsXULTreeElement * const 0x08b3475c) line 455 nsXULTreeElement::SetSuppressOnSelect(nsXULTreeElement * const 0x08b34758, int 0x00000000) line 152 nsXULTreeElement::SelectItem(nsXULTreeElement * const 0x08b34758, nsIDOMXULElement * 0x0a573db4) line 187 XULTreeElementSelectItem(JSContext * 0x05f1ee70, JSObject * 0x00ef6c38, unsigned int 0x00000001, long * 0x00e027e8, long * 0x0012d090) line 272 + 24 bytes js_Invoke(JSContext * 0x05f1ee70, unsigned int 0x00000001, unsigned int 0x00000000) line 777 + 23 bytes js_Interpret(JSContext * 0x05f1ee70, long * 0x0012de10) line 2670 + 15 bytes js_Invoke(JSContext * 0x05f1ee70, unsigned int 0x00000001, unsigned int 0x00000002) line 794 + 13 bytes js_InternalInvoke(JSContext * 0x05f1ee70, JSObject * 0x00e89808, long 0x00cf3c58, unsigned int 0x00000000, unsigned int 0x00000001, long * 0x0012dfa8, long * 0x0012df38) line 866 + 20 bytes JS_CallFunctionValue(JSContext * 0x05f1ee70, JSObject * 0x00e89808, long 0x00cf3c58, unsigned int 0x00000001, long * 0x0012dfa8, long * 0x0012df38) line 3268 + 31 bytes nsJSContext::CallEventHandler(nsJSContext * const 0x05f19310, void * 0x00e89808, void * 0x00cf3c58, unsigned int 0x00000001, void * 0x0012dfa8, int * 0x0012dfa4, int 0x00000000) line 940 + 33 bytes nsJSEventListener::HandleEvent(nsIDOMEvent * 0x04bbeed4) line 154 + 64 bytes nsXBLPrototypeHandler::ExecuteHandler(nsXBLPrototypeHandler * const 0x08af27b0, nsIDOMEventReceiver * 0x0a56a0d8, nsIDOMEvent * 0x04bbeed4) line 353 DoMouse(nsIAtom * 0x02a717e0, nsIXBLPrototypeHandler * 0x08af27b0, nsIDOMEvent * 0x04bbeed4, nsIDOMEventReceiver * 0x0a56a0d8) line 103 nsXBLMouseHandler::MouseDown(nsIDOMEvent * 0x04bbeed4) line 108 + 34 bytes nsEventListenerManager::HandleEvent(nsIPresContext * 0x04bea920, nsEvent * 0x0012f804, nsIDOMEvent * * 0x0012f4c4, nsIDOMEventTarget * 0x0a56a0d8, unsigned int 0x00000002, nsEventStatus * 0x0012f6f8) line 905 + 23 bytes nsXULElement::HandleDOMEvent(nsXULElement * const 0x0a56a0d0, nsIPresContext * 0x04bea920, nsEvent * 0x0012f804, nsIDOMEvent * * 0x0012f4c4, unsigned int 0x00000002, nsEventStatus * 0x0012f6f8) line 3574 nsXULElement::HandleDOMEvent(nsXULElement * const 0x0a573db0, nsIPresContext * 0x04bea920, nsEvent * 0x0012f804, nsIDOMEvent * * 0x0012f4c4, unsigned int 0x00000002, nsEventStatus * 0x0012f6f8) line 3591 + 39 bytes nsXULElement::HandleDOMEvent(nsXULElement * const 0x0a5d1540, nsIPresContext * 0x04bea920, nsEvent * 0x0012f804, nsIDOMEvent * * 0x0012f4c4, unsigned int 0x00000002, nsEventStatus * 0x0012f6f8) line 3591 + 39 bytes nsXULElement::HandleDOMEvent(nsXULElement * const 0x0a6727d0, nsIPresContext * 0x04bea920, nsEvent * 0x0012f804, nsIDOMEvent * * 0x0012f4c4, unsigned int 0x00000001, nsEventStatus * 0x0012f6f8) line 3591 + 39 bytes PresShell::HandleEventInternal(nsEvent * 0x0012f804, nsIView * 0x0a5ac240, unsigned int 0x00000001, nsEventStatus * 0x0012f6f8) line 4876 + 41 bytes PresShell::HandleEvent(PresShell * const 0x04beca64, nsIView * 0x0a5ac240, nsGUIEvent * 0x0012f804, nsEventStatus * 0x0012f6f8, int 0x00000000, int & 0x00000001) line 4805 + 25 bytes nsView::HandleEvent(nsView * const 0x0a5ac240, nsGUIEvent * 0x0012f804, unsigned int 0x00000008, nsEventStatus * 0x0012f6f8, int 0x00000000, int & 0x00000001) line 372 nsView::HandleEvent(nsView * const 0x0a5acb00, nsGUIEvent * 0x0012f804, unsigned int 0x00000008, nsEventStatus * 0x0012f6f8, int 0x00000000, int & 0x00000001) line 345 nsView::HandleEvent(nsView * const 0x04bec670, nsGUIEvent * 0x0012f804, unsigned int 0x0000001c, nsEventStatus * 0x0012f6f8, int 0x00000001, int & 0x00000001) line 345 nsViewManager2::DispatchEvent(nsViewManager2 * const 0x04beab00, nsGUIEvent * 0x0012f804, nsEventStatus * 0x0012f6f8) line 1424 HandleEvent(nsGUIEvent * 0x0012f804) line 68 nsWindow::DispatchEvent(nsWindow * const 0x0a5ac9c4, nsGUIEvent * 0x0012f804, nsEventStatus & nsEventStatus_eIgnore) line 687 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f804) line 708 nsWindow::DispatchMouseEvent(unsigned int 0x0000012e, nsPoint * 0x00000000) line 3956 + 21 bytes ChildWindow::DispatchMouseEvent(unsigned int 0x0000012e, nsPoint * 0x00000000) line 4166 nsWindow::ProcessMessage(unsigned int 0x00000201, unsigned int 0x00000001, long 0x004c0098, long * 0x0012fbbc) line 2961 + 24 bytes nsWindow::WindowProc(HWND__ * 0x0013040a, unsigned int 0x00000201, unsigned int 0x00000001, long 0x004c0098) line 923 + 27 bytes USER32! 77e13eb0() USER32! 77e1401a() USER32! 77e192da() nsAppShellService::Run(nsAppShellService * const 0x005c56f0) line 408 main1(int 0x00000003, char * * 0x005054f0, nsISupports * 0x00000000) line 1004 + 32 bytes main(int 0x00000003, char * * 0x005054f0) line 1298 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32!
Bug was caused by bryner. in this check in: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&su bdir=mozilla/mailnews/news/src&command=DIFF_FRAMESET&file=nsNNTPProtocol.cpp&rev 1=1.241&rev2=1.242&root=/cvsroot A simple test for aMsgWindow == NULL will correct this problem.
I think I can fix the original problem (hint: bienvenu helped me :) patch coming up soon...
Attached patch proposed (temp?) fix (deleted) — Splinter Review
I'm not sure if this patch fixes it. The patch only inits /ir/ if we have a /aMsgWindow/. Sometimes we don't get a /aMsgWindow/, for example from biff checking code. So ir is passed as null to OpenNetworkSocket() if there's a biff check going on. The downside of this, according to bryner, is that it disables secure NNTP for biff :( So this is probably just temporary.
*** Bug 71072 has been marked as a duplicate of this bug. ***
I have a patch that I think addresses both issues. We need to do a null check, as hwaara points out, but we also need to get a notificationCallbacks object to set on the transport. Given that it's perfectly valid to get a null message window (for biff processes, for example), I've added a workaround to nsMsgProtocol that uses the docshell of the most recent window. Adding danm to cc since he knows about this stuff.
Assignee: sspitzer → bryner
Attached patch patch (deleted) — Splinter Review
Um, since I'm the one who reported this, I though I should mention that I crashed on MSGNEWS.DLL twice today. In neither case was I rapidly clicking on messages or anything else. I was just sitting there reading a message that I only clicked on once. The crash occurred several seconds after the message was displayed. Both times, I was in n.p.m.mail-news. The first time, I had no browser window open. The second time, I had just switched to a browser window and got the crash a couple seconds later. I have a Dr Watson for the second crash if you need it.
sspitzer, looking at this stack trace, is it normal to not have a msgwindow there? I understand how this could happen in the biff case, but I'm not sure what is going on with this particular stack trace.
Status: NEW → ASSIGNED
*** Bug 71120 has been marked as a duplicate of this bug. ***
*** Bug 71084 has been marked as a duplicate of this bug. ***
I think the code path when using the subscribe dialog doesn't have a msg window when it creates a nntp protocol.
K Chayka, thanks for offering a second Dr. Watson but I think the engineer working on this already got the problem nailed down. The problem is, that sometimes when the email client checks for new email, and you're looking at news faulty code is executed. This will hopefully get fixed soon.
taking off the smoketest blocker list... this problem seems to be well known and there are Top People looking at it, so there's no need to hold the tree for it.
Keywords: smoketest
This seems to be part of the problem, we weren't propagating the nsIMsgWindow in NewChannel.
Attached patch Patch to nsNNTPService (deleted) — Splinter Review
A quick and simple way to reproduce this crash is to click on news://forums.macromedia.com/macromedia.open-swf the crash that results yeilds the same talkback as this bug.
*** Bug 71232 has been marked as a duplicate of this bug. ***
*** Bug 71277 has been marked as a duplicate of this bug. ***
*** Bug 71277 has been marked as a duplicate of this bug. ***
r=bryner on hwaara's patch... let's try to stop this from crashing and then worry about getting the right msgwindow/callbacks.
I like it (and I've crashed from it): sr=shaver.
Checked in. The issue of setting the right notification callbacks on the socket transport even when we have no msgwindow is now covered in bug 71351.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
I just crashed in MSGNEWS.DLL. I was reading a news article and hit 'n' to go to the next one. Talkback ID is TB27521937W. Mozilla 2001030904 on Win2000.
I think that's a different bug, the stack trace appears different (although the talkback report doesn't seem to contain line numbers).
I stress-tested news.mcom.com using the newsgroup comp.lang.javascript using the following criteria: Using N to advance to the next message Using B to step back to the previous message I clicked on a message, didn't allow it to load and then selected a new message, doing this multiple times. Didn't crash on build 2001030904 on Windows 2000.
*** Bug 71453 has been marked as a duplicate of this bug. ***
Verified fixed in build 2001032304 Mac OS 9.1, build 2001032308 on Mandrake 7.2 with KDE 2.0 and build 200103204 on Windows 2000.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: