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)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: kcha-ns-yka, Assigned: bryner)
References
Details
(Keywords: crash)
Attachments
(5 files)
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
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.
*** Bug 71061 has been marked as a duplicate of this bug. ***
Added crash keyword and internal nomination for fix.
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.)
Doug, could it be your checkin for bug 68483?
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=26801
Comment 10•24 years ago
|
||
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?
Comment 12•24 years ago
|
||
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)
Comment 15•24 years ago
|
||
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!
Comment 16•24 years ago
|
||
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.
Thanks Doug, sorry about that.
Comment 18•24 years ago
|
||
I think I can fix the original problem (hint: bienvenu helped me :)
patch coming up soon...
Comment 19•24 years ago
|
||
Comment 20•24 years ago
|
||
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.
Assignee | ||
Comment 21•24 years ago
|
||
*** Bug 71072 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 22•24 years ago
|
||
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
Assignee | ||
Comment 23•24 years ago
|
||
Reporter | ||
Comment 24•24 years ago
|
||
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.
Assignee | ||
Comment 25•24 years ago
|
||
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
Comment 26•24 years ago
|
||
*** Bug 71120 has been marked as a duplicate of this bug. ***
Comment 27•24 years ago
|
||
*** Bug 71084 has been marked as a duplicate of this bug. ***
Comment 28•24 years ago
|
||
I think the code path when using the subscribe dialog doesn't have a msg window
when it creates a nntp protocol.
Comment 29•24 years ago
|
||
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.
Comment 30•24 years ago
|
||
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
Assignee | ||
Comment 31•24 years ago
|
||
This seems to be part of the problem, we weren't propagating the nsIMsgWindow in
NewChannel.
Assignee | ||
Comment 32•24 years ago
|
||
Comment 33•24 years ago
|
||
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. ***
Comment 35•24 years ago
|
||
*** Bug 71277 has been marked as a duplicate of this bug. ***
Comment 36•24 years ago
|
||
*** Bug 71277 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 37•24 years ago
|
||
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.
Assignee | ||
Comment 39•24 years ago
|
||
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
Comment 40•24 years ago
|
||
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.
Assignee | ||
Comment 41•24 years ago
|
||
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
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•