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)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

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

References

Details

(Keywords: crash)

Attachments

(5 files)

Dr Watson report
102.18 KB, text/plain
Details
Talkback 27372593
2.42 KB, text/plain
Details
proposed (temp?) fix
949 bytes, patch
Details | Diff | Splinter Review
patch
2.74 KB, patch
Details | Diff | Splinter Review
Patch to nsNNTPService
1.03 KB, 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.
Attached file Dr Watson report — 

    
    

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

    
    

    
  


  

    
    

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


    
    

    
  
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: