Closed Bug 87923 Opened 23 years ago Closed 23 years ago

When in offline mode, reply causes crash

Categories

(SeaMonkey :: MailNews: Backend, defect, P2)

Product:
SeaMonkey
Component:
MailNews: Backend
Platform:
x86
Windows 98
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.5

People

(Reporter: grega, Assigned: pavlov)

Details

(Keywords: crash, Whiteboard: PDT)

Attachments

(4 files)

attaching crash info in text format
166.50 KB, text/plain
Details
screen shot of error message in windows from my latest crash
9.94 KB, image/gif
Details
screen capture of both error messages
5.77 KB, image/gif
Details
fugly hack
744 bytes, patch
Details | Diff | Splinter Review 
In offline mode

1. Select message
2. click on reply or reply all
3. Netscape crashes

It seems to happen on every other instance
works fine for me - what version are you running? Do you have the messages in
question downloaded for offline use or not? Are you talking about imap, local,
or news messages? Is there anything special about the messages in question? JF
has fixed a bunch of bugs in this area when the messages have links in them, but
that was weeks ago.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hey David. I walked over to Greg's cube.
I did see it. But didn't have enough time to investigate.
I think it had to do with maybe reply all (and having
lot's of people to reply to) and while offline. 

I haven't reproduced the bug as of yet. I'll work with
Greg and get more gritty details.

In mean time here are the talkback id's i found
http://climate.mcom.com/reports/incidenttemplate.cfm?bbid=32213270
http://cyclone.mcom.com/reports/incidenttemplate.cfm?bbid=32202121

other incident ids 32202118,32202115




unfortunately, there are no stack traces in those talkback reports. What's up
with that? Is talkback broken on the build greg is using?
It is highly unlikely that it has to do with the number of recipients. It is
much more likely it has to do with the contents of the message being replied to.
Perhaps Greg could attach a message that reply while offline crashes on. It
would also be interesting to know whether it's reproducible. Does reply or reply
all to the same message always crash? Sometimes crash?
investigating..will add more information when 
I get to talk to Greg..

Greg mentioned it's a url.. I've tried some urls
and no luck.. will have more tommorrow..
Ok I can recreate the crash. Not consistently..

steps I did:
1.Login to your imap account.
2.Send yourself a mail using 'send page' option from browser
3.Go offline. Don't download that particular email
5.Physically disconnect your network connection
6.Clean out cache
7.Do a reply or reply all to that message
  that you did a 'send page' with.
Result: Crash, I tried it couple of more times and it didn't crash
     but instead automatically 'quit'. No talkback or error messsages
     but netscape flat out quit.

it' definitly hard to reproduce. May have to try few times.
Hope some of this info helps.

using 2001062603 build on NT 4.0

Two more talkback ids
TB32262157M
http://climate.mcom.com/reports/incidenttemplate.cfm?bbid=32262157
TB32260237W
http://climate.mcom.com/reports/incidenttemplate.cfm?bbid=32260237

Error messages that I saw pop up in windows were:
"The instructions at 0x04151dd5 referenced memory at 0x00000003.
 The memory could not be written"
"Unhandled exception in netscp6.exe 0xC0000005: Access Violation"




Ok got the steps to reproduce.
Greg is using  2001062604 on win 98.
I am using 2001062604 on win nt 4.0.

1. Make sure you physically aren't connected to network (ie
   disconnect your network connection)
2. Start with at least 2 profiles so it brings up profile mgr.
3. Make sure that which ever profile you choose, there are
   messages already downloaded. (if not reconnect to
   network and setup the appropriate test account w/downloaded mesgs)
4. In profile mgr., select a profile and check the 'work offline' box
5. bring up messenger
6. randomly click on a downloaded message and click the
  'reply all' button.
7. If it doesn't crash, click on another message and try again
   repeat till crash.

result: crash happens. I've seen different error messages
  -'the instructions at blah referenced memory at blah'
  -'Net6 performed an illegal operation'

David here are couple more talkback ids.
http://climate.mcom.com/reports/incidenttemplate.cfm?bbid=32299137
 [with call stack on kernel32.dll]
http://climate.mcom.com/reports/incidenttemplate.cfm?bbid=32298752
 [with call stack on NKCACHE.DLL]
http://climate.mcom.com/reports/incidenttemplate.cfm?bbid=32299124
 [another crash on NKCACHE.DLL]

And the dumps from various crashes that windows provide:

NETSCP6 caused an invalid page fault in
module <unknown> at 0000:03d8d444.
Registers:
EAX=049aa6b4 CS=0167 EIP=03d8d444 EFLGS=00010216
EBX=04944550 SS=016f ESP=0068fbdc EBP=0068fc18
ECX=049a6cdc DS=016f ESI=049aa5d0 FS=4127
EDX=007b4490 ES=016f EDI=049287b0 GS=0000
Bytes at CS:EIP:
10 1d 81 03 13 00 00 00 c0 1c 81 03 c0 3f 70 04 
Stack dump:
007b0167 049287b0 049aa5d0 0068fc18 0068fc00 04944550
007b4490 049ae3dc 049aa650 605e2ba9 049aa650 00000000
049aa5d0 034d8bd0 60e12680 0068fc38 
-------------------------------
NETSCP6 caused an invalid page fault in
module <unknown> at 0000:006870cb.
Registers:
EAX=03a11d80 CS=0167 EIP=006870cb EFLGS=00010286
EBX=60e12680 SS=016f ESP=0068faac EBP=60e12710
ECX=024495b0 DS=016f ESI=03aa1940 FS=3cc7
EDX=817ac0b4 ES=016f EDI=00000003 GS=0000
Bytes at CS:EIP:
02 98 e7 68 00 aa 03 00 00 98 e7 68 00 00 00 00 
Stack dump:
0068fab0 60823ba4 03a11d80 60eeae49 03aa1940 00000003
00829860 60eeadb7 03aa1940 0068faf4 0068faec 00829860
0068fb40 60eeb013 00829860 00008b64 
------------------------------
NETSCP6 caused an invalid page fault in
module <unknown> at 0000:fbd9a42a.
Registers:
EAX=03d761f0 CS=0167 EIP=fbd9a42a EFLGS=00010287
EBX=60e12680 SS=016f ESP=0068faac EBP=60e12710
ECX=024235f8 DS=016f ESI=04062ee0 FS=0f1f
EDX=817ae484 ES=016f EDI=00000007 GS=0000
Bytes at CS:EIP:

Stack dump:
03d761f5 60823ba4 03d761f0 60eeae49 04062ee0 00000007
00829860 60eeadb7 04062ee0 0068faf4 
0068faec 00829860 0068fb40 60eeb013 00829860 00008b64 
-------------------------------
NETSCP6 caused an invalid page fault in
module <unknown> at 0000:03f45843.
Registers:
EAX=03f45840 CS=0167 EIP=03f45843 EFLGS=00010206
EBX=60e12680 SS=016f ESP=0068fab4 EBP=60e12710
ECX=60823ba4 DS=016f ESI=042119f0 FS=34af
EDX=817ac0b4 ES=016f EDI=00000004 GS=0000
Bytes at CS:EIP:
03 8c 78 f4 03 ec 53 4d 60 28 cf ef 60 00 00 00 
Stack dump:
03f45840 60eeae49 042119f0 00000004 008296e0 60eeadb7
042119f0 0068faf4 0068faec 008296e0 0068fb40 60eeb013
008296e0 00008b64 0068fb0c bff7363b 
-------------------------
NETSCP6 caused an invalid page fault in
module NKCACHE.DLL at 0167:60823ba1.
Registers:
EAX=030ba5d0 CS=0167 EIP=60823ba1 EFLGS=00010206
EBX=60e12680 SS=016f ESP=0068fab4 EBP=60e12710
ECX=00530049 DS=016f ESI=043906a0 FS=2f07
EDX=81807a08 ES=016f EDI=00000004 GS=0000
Bytes at CS:EIP:
ff 51 08 33 c0 c3 ff 74 24 04 e8 da 43 00 00 59 
Stack dump:
030ba5d0 60eeae49 043906a0 00000004 00829860 60eeadb7
043906a0 0068faf4 0068faec 00829860 0068fb40 60eeb013
00829860 00008b64 0068fb0c bff7363b 


Hope this helps.
what web pages did you do a send page on? I haven't had any luck reproducing this.
Using Commercial build
2001-07-03-11-trunk/ WinNT 4.0

Hmm I thought it crashed regardless of whether it was
url in the mail or not? Anyways I reproduced the crash
again. 

The send page url I used was www.cnet.com (make sure
you have at least addressed the mail to 2 mail ids)
Replying all to that email (with cnet web page) crashed
Netscape.

I repeated steps from my comments on 6/28 and it
crashed again.

Talkback id:
http://climate.mcom.com/reports/incidenttemplate.cfm?bbid=32493537


Using same build, I crashed when doing a reply all to 
a message with out a url in it (maybe it was a
consequence of crashing earlier to a message that had url
in it?).

The message had 3 people in the 2 field and body of
the message was just text.
Talkback id: TB32494183E
http://climate.mcom.com/reports/incidenttemplate.cfm?bbid=32494183

OK, I can reproduce this crash with www.cnet.com - I'm crashing in the imglib in
imgRequestProxy::Cancel when it sets   mOwner = nsnull; but the comptr mOwner is
invalid (as is probably the whole request object).
Gary (and Greg), could you try this with a recent trunk build? I can no longer
reproduce this crash.
Severity: blocker → major
Status: NEW → ASSIGNED
David,
I am using 2001-07-17-10-trunk on Nt 4.0.

I reproduced the crash. my test case was downloaded message
with netscape home page in it. First time I tried to
test, it crashed as soon as I clicked on the message (didn't
get chance to do a reply all). Next test, i tried replying
all to another message. Worked fine. Then did just a reply
to the same message and it crashed. (that message just had cnet url only).

When I crashed the first time, the error message was totally brand new.
Second crash the error message was similar to rest of them.

My two talkback ids
TB33015616X -1st crash
TB33015847Y - 2nd crash.

Will enclose screen capture.


ps I used my steps on June 28th to reproduce the crash
*** Bug 92368 has been marked as a duplicate of this bug. ***
Adding another note.

Check comments in the dupe bug 92368

As it appears it will crash without being physcially
disconnected to the network. All you need to do
is double click on the message and I think it has
to do with embedded web page in the message?

Think my June 28 steps or steps in dupe bug 92368 are
the ones to reproduce.
I can reproduce it and I got a fugly hack to utilityOverlay.js that has made it 
go away for me.  but it is fugly.
gary - pls add this to the release notes tracking bug for jatin.  Thanks.
Keywords: crash
pavlov, this looks right up your alley.

here's stack from the other bug:

if you want to debug with me on my machine, come on up.

nsCOMPtr<imgIRequest>::assign_assuming_AddRef(imgIRequest * 0x00000000) line 
471 + 3 bytes
nsCOMPtr<imgIRequest>::assign_with_AddRef(nsISupports * 0x00000000) line 964
nsCOMPtr<imgIRequest>::operator=(imgIRequest * 0x00000000) line 584
imgRequestProxy::Cancel(imgRequestProxy * const 0x05d304a0, unsigned int 
0x80004005) line 172
nsImageBoxFrame::UpdateImage(nsIPresContext * 0x04e38a90, int & 0x00000000) 
line 280
nsImageBoxFrame::DidSetStyleContext(nsImageBoxFrame * const 0x0534f0dc, 
nsIPresContext * 0x04e38a90) line 403
nsFrame::SetStyleContext(nsFrame * const 0x0534f0dc, nsIPresContext * 
0x04e38a90, nsIStyleContext * 0x053511f0) line 502
FrameManager::ReResolveStyleContext(nsIPresContext * 0x04e38a90, nsIFrame * 
0x0534f0dc, nsIStyleContext * 0x05350e38, nsIContent * 0x05c43380, int 
0x00000000, nsIAtom * 0x00000000, nsStyleChangeList & {...}, int 0x00000005, 
int & 0x0012bd74) line 1693
FrameManager::ReResolveStyleContext(nsIPresContext * 0x04e38a90, nsIFrame * 
0x0534f02c, nsIStyleContext * 0x0534c394, nsIContent * 0x00000000, int 
0x00000000, nsIAtom * 0x024dbe80, nsStyleChangeList & {...}, int 0x00000005, 
int & 0x00000005) line 1837
FrameManager::ComputeStyleChangeFor(FrameManager * const 0x04e4ba50, 
nsIPresContext * 0x04e38a90, nsIFrame * 0x0534f02c, int 0x00000000, nsIAtom * 
0x024dbe80, nsStyleChangeList & {...}, int 0x00000003, int & 0x00000000) line 
2082
nsCSSFrameConstructor::AttributeChanged(nsCSSFrameConstructor * const 
0x04e4c7f0, nsIPresContext * 0x04e38a90, nsIContent * 0x05c43380, int 
0x00000000, nsIAtom * 0x024dbe80, int 0x00000003) line 10050
StyleSetImpl::AttributeChanged(StyleSetImpl * const 0x04e49c50, nsIPresContext 
* 0x04e38a90, nsIContent * 0x05c43380, int 0x00000000, nsIAtom * 0x024dbe80, 
int 0xffffffff) line 1204
PresShell::AttributeChanged(PresShell * const 0x04e4dd38, nsIDocument * 
0x05a25770, nsIContent * 0x05c43380, int 0x00000000, nsIAtom * 0x024dbe80, int 
0xffffffff) line 4941 + 57 bytes
nsXULDocument::AttributeChanged(nsXULDocument * const 0x05a25770, nsIContent * 
0x05c43380, int 0x00000000, nsIAtom * 0x024dbe80, int 0xffffffff) line 1634
nsXULElement::SetAttribute(nsXULElement * const 0x05c43380, nsINodeInfo * 
0x04e6e690, const nsAString & {...}, int 0x00000001) line 3047
nsXULElement::SetAttribute(nsXULElement * const 0x05c43384, const nsAString &
{...}, const nsAString & {...}) line 1394 + 31 bytes
nsXULElement::SetAttribute(nsXULElement * const 0x05c1f5b0, nsINodeInfo * 
0x04e6e690, const nsAString & {...}, int 0x00000001) line 2998
nsXULElement::SetAttribute(nsXULElement * const 0x05c1f5b4, const nsAString &
{...}, const nsAString & {...}) line 1394 + 31 bytes
XPTC_InvokeByIndex(nsISupports * 0x05c1f5b4, unsigned int 0x0000001e, unsigned 
int 0x00000002, nsXPTCVariant * 0x0012c8f4) line 139
XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode 
CALL_METHOD) line 1882 + 42 bytes
XPC_WN_CallMethod(JSContext * 0x059fc180, JSObject * 0x0532a008, unsigned int 
0x00000002, long * 0x0535b1e0, long * 0x0012cb28) line 1252 + 11 bytes
js_Invoke(JSContext * 0x059fc180, unsigned int 0x00000002, unsigned int 
0x00000000) line 807 + 23 bytes
js_Interpret(JSContext * 0x059fc180, long * 0x0012d8c8) line 2697 + 15 bytes
js_Invoke(JSContext * 0x059fc180, unsigned int 0x00000001, unsigned int 
0x00000002) line 824 + 13 bytes
nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJSClass * const 0x02eefb50, 
nsXPCWrappedJS * 0x05ac9ee0, unsigned short 0x0003, const nsXPTMethodInfo * 
0x00d30ce0, nsXPTCMiniVariant * 0x0012de0c) line 1019 + 21 bytes
nsXPCWrappedJS::CallMethod(nsXPCWrappedJS * const 0x05ac9ee0, unsigned short 
0x0003, const nsXPTMethodInfo * 0x00d30ce0, nsXPTCMiniVariant * 0x0012de0c) 
line 427
PrepareAndDispatch(nsXPTCStubBase * 0x05ac9ee0, unsigned int 0x00000003, 
unsigned int * 0x0012debc, unsigned int * 0x0012deac) line 100 + 31 bytes
SharedStub() line 124
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x05ac9f40, 
nsIDOMEvent * 0x05d70504, nsIDOMEventTarget * 0x059fc340, unsigned int 
0x00000001, unsigned int 0x00000004) line 1161 + 20 bytes
nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x05a568b0, 
nsIPresContext * 0x05d45640, nsEvent * 0x0012f0cc, nsIDOMEvent * * 0x0012f084, 
nsIDOMEventTarget * 0x059fc340, unsigned int 0x00000004, nsEventStatus * 
0x0012f0f4) line 1834 + 36 bytes
GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x059fc330, 
nsIPresContext * 0x05d45640, nsEvent * 0x0012f0cc, nsIDOMEvent * * 0x0012f084, 
unsigned int 0x00000004, nsEventStatus * 0x0012f0f4) line 598
nsXULDocument::HandleDOMEvent(nsXULDocument * const 0x05a25770, nsIPresContext 
* 0x05d45640, nsEvent * 0x0012f0cc, nsIDOMEvent * * 0x0012f084, unsigned int 
0x00000004, nsEventStatus * 0x0012f0f4) line 2007
nsXULElement::HandleDOMEvent(nsXULElement * const 0x05a56910, nsIPresContext * 
0x05d45640, nsEvent * 0x0012f0cc, nsIDOMEvent * * 0x0012f084, unsigned int 
0x00000004, nsEventStatus * 0x0012f0f4) line 3605 + 39 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x05ac53c0, nsIPresContext * 
0x05d45640, nsEvent * 0x0012f0cc, nsIDOMEvent * * 0x0012f084, unsigned int 
0x00000004, nsEventStatus * 0x0012f0f4) line 3603
nsXULElement::HandleDOMEvent(nsXULElement * const 0x05ac51b0, nsIPresContext * 
0x05d45640, nsEvent * 0x0012f0cc, nsIDOMEvent * * 0x0012f084, unsigned int 
0x00000004, nsEventStatus * 0x0012f0f4) line 3603
nsXULElement::HandleChromeEvent(nsXULElement * const 0x05ac51c0, nsIPresContext 
* 0x05d45640, nsEvent * 0x0012f0cc, nsIDOMEvent * * 0x0012f084, unsigned int 
0x00000004, nsEventStatus * 0x0012f0f4) line 4594 + 39 bytes
GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x05d3d490, 
nsIPresContext * 0x05d45640, nsEvent * 0x0012f0cc, nsIDOMEvent * * 0x0012f084, 
unsigned int 0x00000001, nsEventStatus * 0x0012f0f4) line 594
DocumentViewerImpl::LoadComplete(DocumentViewerImpl * const 0x05d3c4f0, 
unsigned int 0x00000000) line 1101 + 47 bytes
nsDocShell::EndPageLoad(nsIWebProgress * 0x05d381c4, nsIChannel * 0x05d39930, 
unsigned int 0x00000000) line 3743
nsWebShell::EndPageLoad(nsIWebProgress * 0x05d381c4, nsIChannel * 0x05d39930, 
unsigned int 0x00000000) line 894
nsDocShell::OnStateChange(nsDocShell * const 0x05d38b24, nsIWebProgress * 
0x05d381c4, nsIRequest * 0x05d39930, int 0x00020010, unsigned int 0x00000000) 
line 3664
nsDocLoaderImpl::FireOnStateChange(nsIWebProgress * 0x05d381c4, nsIRequest * 
0x05d39930, int 0x00020010, unsigned int 0x00000000) line 1095
nsDocLoaderImpl::doStopDocumentLoad(nsIRequest * 0x05d39930, unsigned int 
0x00000000) line 734
nsDocLoaderImpl::DocLoaderIsEmpty() line 632
nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x05d381b4, nsIRequest * 
0x05d39930, nsISupports * 0x00000000, unsigned int 0x00000000) line 563
nsLoadGroup::RemoveRequest(nsLoadGroup * const 0x05d38140, nsIRequest * 
0x05d39930, nsISupports * 0x00000000, unsigned int 0x00000000) line 512 + 44 
bytes
nsStreamIOChannel::OnStopRequest(nsStreamIOChannel * const 0x05d39934, 
nsIRequest * 0x05d39824, nsISupports * 0x00000000, unsigned int 0x00000000) 
line 466
nsOnStopRequestEvent::HandleEvent() line 161
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x05d39404) line 64
PL_HandleEvent(PLEvent * 0x05d39404) line 590 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00e85900) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x0048023e, unsigned int 0x0000c0e2, unsigned 
int 0x00000000, long 0x00e85900) line 1071 + 9 bytes
USER32! 77e13eb0()
USER32! 77e1401a()
USER32! 77e192da()
nsAppShellService::Run(nsAppShellService * const 0x00566b30) line 425
main1(int 0x00000002, char * * 0x00484190, nsISupports * 0x00000000) line 1290 
+ 32 bytes
main(int 0x00000002, char * * 0x00484190) line 1599 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e87903()


adding nsenterprise keyword
Keywords: nsenterprise
adding nsenterprise+
Keywords: nsenterprise → nsenterprise+
Priority: -- → P2
Target Milestone: --- → mozilla0.9.4
OK, since the bug I reassigned to pav was marked a dup, I'll reassign this one
to Pav. Pav, can you look at this? Thanks.
Assignee: bienvenu → pavlov
Status: ASSIGNED → NEW
Pav, this is going to be pretty important to us and the eMojo release. Can you
make sure this is on your .9.4 radar? Don't want any suprises =)
Nominating for PDT+
Whiteboard: PDT
0.9.4 is out the door
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Keywords: nsbranch+
Adding stack trace as tested Commercial branch build 
2001-09-19-05-0.9.4 on win nt 4.0. Not sure but looks
like stack trace different?

Crashed on a downloaded mesg that contained Cnet web page.
Did a reply to message. Couldn't make a crash by just opening
a mesg in stand alone window (bug 92368).

 Call Stack:    (Signature = 0x0555fd21 333b355d)   
   0x0555fd21 
   nsEditor::BeginTransaction 
     [d:\builds\seamonkey\mozilla\editor\base\nsEditor.cpp, line 655]
   nsHTMLEditorLog::BeginTransaction 
     [d:\builds\seamonkey\mozilla\editor\base\nsHTMLEditorLog.cpp, line 220]  
   nsEditorShell::BeginBatchChanges 
     [d:\builds\seamonkey\mozilla\editor\base\nsEditorShell.cpp, line 4806]    
   nsMsgCompose::ConvertAndLoadComposeWindow  
     [d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgCompose.cpp, 
     line 452]
   QuotingOutputStreamListener::OnStopRequest 
     [d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgCompose.cpp, 
      line 1739]
   nsStreamConverter::OnStopRequest 
     [d:\builds\seamonkey\mozilla\mailnews\mime\src\nsStreamConverter.cpp, 
      line 1038]
   nsImapCacheStreamListener::OnStopRequest 
     [d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, 
      line 6811]
   nsOnStopRequestEvent::HandleEvent 
     [d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp,       
line 162]
   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]

Talkback ids
 TB35709799X, TB35708032M
this is the same as the stack trace in bug 99354 - I'll try reproducing it with
an attached cnn page.
So the crash that you were seeing I fixed.  I don't know about the new crash
that is in bug 99354.  Should this bug be marked fixed and let the new crash
continue in 99354?
yes, great - I'll mark this one fixed.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Let me know when this has been verified in the trunk.  If not too risky we want 
this on the branch.  Thanks for the fix!
the fix for this is already on the branch.. it was checked in before 0.9.4 closed.
commercial branch build
2001-09-24-05-0.9.4 nt 4.0

This a windows only bug (did try it on mac branch build and couldn't
make it crash either).

Well tried replying to different type of mesgs to make it crash.
And when I did crash (reply to a mesg, quit the mesg, reply
to another mesg) it was the same stack trace found in the new
bug 99354. I disconnected my computer from network and started
in offline mode through profile manager.

So since it appears Pav fixed the initial crash problem. 

I did crash my very first time with a stack trace totally different
than 99354 and stack doesnt appear to be the same for this
bug or stand alone mesg bug (bug 92368). But i could not replicate
it again (tried 6 more times). I'll enclose the talkback id, link,
and paste of top of the stack trace in case one of you think
this is a problem. I think it must have been fluke.
TB35833285W
http://cyclone.mcom.com/reports/incidenttemplate.cfm?bbid=35833285
Call Stack:    (Signature = _hashEnumerate 17797d72) 
     
_hashEnumerate 
    [d:\builds\seamonkey\mozilla\xpcom\ds\nsHashtable.cpp, line 199]
     
PL_HashTableEnumerateEntries 
   [../../../lib/ds/plhash.c, line 430]
     
nsHashtable::Enumerate 
   [d:\builds\seamonkey\mozilla\xpcom\ds\nsHashtable.cpp, line 372]
     
nsXBLBinding::ChangeDocument 
   [d:\builds\seamonkey\mozilla\content\xbl\src\nsXBLBinding.cpp, line 1236]
     
nsBindingManager::ChangeDocumentFor 
    [d:\builds\seamonkey\mozilla\content\xbl\src\nsBindingManager.cpp, line 929]
     
nsXULElement::SetDocument 
    [d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, 
    line 2398]
     
nsXULElement::SetDocument 
    [d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, 
    line 2499]
     
nsXULElement::SetDocument 
    [d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, 
    line 2499]
     
nsXULElement::SetDocument 
    [d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, 
    line 2499]
....
...last few lines of stack
nsWindow::DefaultWindowProc 
   [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1023]    
USER32.dll + 0x27fe (0x77e727fe) 
USER32.dll + 0x2889 (0x77e72889)      
nsWindow::WindowProc 
   [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1008]     
USER32.dll + 0x1820 (0x77e71820) 
   0x00130274 

Going to mark verified on branch (since old crash was fixed) and
add key word vtrunk.
Keywords: vtrunk
commercial trunk
2001-10-08-09-trunk NT 4.0

tried reply, reply all to various type of messages
while offline. NO crash.

Marking as verified.

removing keyword vtrunk
Status: RESOLVED → VERIFIED
Keywords: vtrunk
removing link to this fixed bug from 0.9.6 release notes
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: