Closed Bug 54444 Opened 24 years ago Closed 24 years ago

Send Page sends the page, but crashes the browser

Categories

(MailNews Core :: Backend, defect, P2)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: acraigwest, Assigned: Bienvenu)

References

()

Details

(Keywords: crash, Whiteboard: [rtm++])

Attachments

(1 file)

Using Send Page from the file menu appears to successfully send the page, but the browser gp faults. "The instruction at 0x605d834b referenced memory at 0x00000000"
does not crash on 092708 mozilla trunk build running on NT.
worksforme 2000092908 branch. if you still see this with the newest build after you deleted the old one, please reopen
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
I filed this in the wrong place, it turns out. Seeing as you were not able to duplicate the problem, I built the tree and ran in the debugger. What is Mork, anyways? Besides a guy who says "Nanoo, Nanoo" a lot... In any case, the problem is that my user folder has been partially cleaned out, and when the system was trying to save the e-mail to my 'sent messages' folder, the system crashed when the directory it was trying to write to did not exist. This isn't a very normal situation, but something a little less extreme than a GP fault appears to be in order... Call Stack of the crash: NTDLL! 77f7629c() nsDebug::Assertion(const char * 0x01d3cb90, const char * 0x01d3ca9c, const char * 0x01d3ca6c, int 0x0000004e) line 256 + 13 bytes mork_assertion_signal(const char * 0x01d3cb90) line 78 + 31 bytes morkEnv::NewError(const char * 0x0460d2b0) line 369 + 19 bytes morkFile::NewFileErrnoError(morkEnv * 0x0460c990) line 272 morkStdioFile::new_stdio_file_fault(morkEnv * 0x0460c990) line 668 morkStdioFile::OpenStdio(morkEnv * 0x0460c990, const char * 0x0460c818, const char * 0x01d3cddc) line 739 morkStdioFile::morkStdioFile(morkEnv * 0x0460c990, const morkUsage & {...}, nsIMdbHeap * 0x02d61748, nsIMdbHeap * 0x02d61748, const char * 0x0460c818, const char * 0x01d3cddc) line 693 morkStdioFile::CreateNewStdioFile(morkEnv * 0x0460c990, nsIMdbHeap * 0x02d61748, const char * 0x0460c818) line 393 + 61 bytes morkFile::CreateNewFile(morkEnv * 0x0460c990, nsIMdbHeap * 0x02d61748, const char * 0x0460c818) line 191 + 17 bytes orkinFactory::CreateNewFile(nsIMdbEnv * 0x0460bd38, nsIMdbHeap * 0x02d61748, const char * 0x0460c818, nsIMdbFile * * 0x0012f3b8) line 347 + 17 bytes nsMsgDatabase::OpenMDB(nsMsgDatabase * const 0x0460bf30, const char * 0x0460c818, int 0x00000001) line 892 + 30 bytes nsMailDatabase::Open(nsMailDatabase * const 0x0460f060, nsIFileSpec * 0x045d1c10, int 0x00000001, int 0x00000000, nsIMsgDatabase * * 0x045c0bc8) line 89 + 29 bytes nsMsgLocalMailFolder::GetDatabase(nsIMsgWindow * 0x00000000) line 755 + 66 bytes nsMsgDBFolder::GetMsgDatabase(nsMsgDBFolder * const 0x045c0b4c, nsIMsgWindow * 0x00000000, nsIMsgDatabase * * 0x0012f5d8) line 584 nsMsgLocalMailFolder::CopyFileMessage(nsMsgLocalMailFolder * const 0x045c0b4c, nsIFileSpec * 0x045c0500, nsIMessage * 0x00000000, int 0x00000000, nsIMsgWindow * 0x00000000, nsIMsgCopyServiceListener * 0x0460cfd0) line 1986 + 43 bytes nsMsgCopyService::DoNextCopy() line 246 + 78 bytes nsMsgCopyService::DoCopy(nsCopyRequest * 0x0460cf70) line 174 + 8 bytes nsMsgCopyService::CopyFileMessage(nsMsgCopyService * const 0x0460b860, nsIFileSpec * 0x045c0500, nsIMsgFolder * 0x045c0b4c, nsIMessage * 0x00000000, int 0x00000000, nsIMsgCopyServiceListener * 0x0460cfd0, nsIMsgWindow * 0x00000000) line 417 + 12 bytes nsMsgCopy::DoCopy(nsIFileSpec * 0x045c0500, nsIMsgFolder * 0x045c0b4c, nsIMessage * 0x00000000, int 0x00000000, nsIMsgWindow * 0x00000000, nsMsgComposeAndSend * 0x0460eb60) line 305 + 67 bytes nsMsgCopy::StartCopyOperation(nsIMsgIdentity * 0x0449fad0, nsIFileSpec * 0x045c0500, int 0x00000000, nsMsgComposeAndSend * 0x0460eb60, const char * 0x0012f864, nsIMessage * 0x00000000) line 236 + 35 bytes nsMsgComposeAndSend::StartMessageCopyOperation(nsIFileSpec * 0x045c0500, int 0x00000000, char * 0x045c04a0) line 4174 + 57 bytes The call to orkinFactory::CreateNewFile() in nsMsgDatabase::OpenMDB appears to be the root of the problem. The code to create the folder does not check that the destination directory actually exists. Not knowing the conventions in use here, I don't know whether it would be more appropriate to create the relevant directory before creating the file, or create the directory in the call to CreateNewFile, or just return an error...
Status: RESOLVED → UNCONFIRMED
Component: Browser-General → Mail Database
Product: Browser → MailNews
Resolution: WORKSFORME → ---
Me again. After deleting my user mail directory, I managed to convince it to properly create the folders in question. It is now asserting, though: ComposeUnload from XUL ###!!! ASSERTION: ~nsTextEditor: 'Not Reached', file m:\mozilla\mozilla\editor\base\nsHTMLEditor.cpp, line 347 ###!!! Break: at file m:\mozilla\mozilla\editor\base\nsHTMLEditor.cpp, line 347 This is likely another bug. I should probably file it as such, but I will hold off while I try to find a work-around. I suspect the real solution to my problem is to delete my identity and create a new one, but I would REALLY prefer to avoid that...
The assertion is unrelated. Back to the original problem, you can duplicate this by removing the directory that your sent mail folder is in, then try sending a page. I'll stop bothering you now... :-)
setting bug status to New and reassigning to default owners.
Assignee: asa → bienvenu
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: doronr → esther
this is not a database problem. The assert is not causing the crash (in fact, I have no idea where the crash is - presumably somewhere down the road). It's the responsibility of the caller to make sure the directory exists, I'm afraid.
Component: Mail Database → Mail Back End
well, I'll nominate this for RTM, but I doubt it'll be accepted.
Status: NEW → ASSIGNED
Keywords: crash, rtm
Priority: P3 → P2
I need to stop doing bug reports with not enough sleep. I've got the ACTUAL crash narrowed down, now, and it is related to the assertion... I would consider the nsOutputFileStream semantics to be somewhat broken, or at least its usage in the CopyMessage code. The entire message gets written to an invalid stream without any error messages until the call to EndCopy, where the code finally notices that there is no file... Other than a whack of assertions during EndCopy, things proceed somewhat normally, until EndCopy calls ClearCopyState. ClearCopyState deletes mCopyState, which closes and deletes the invalid nsOutputFileStream. nsOutputStream::Close() doesn't check if it has a valid pointer, and gp-faults. (nsFileStream.h line 244-247: void close() { mOutputStream->Close(); } The fix for this is simple enough, change it to: if (mOutputStream) mOutputStream->Close(); This will fix this, and probably other crashes Checking through the xpcom/io directory, however, I have found a number of similar cases in nsBinaryStream: nsBinaryStream.cpp line 60, 63, 68, 118, 236, 241, 273 These are probably acceptable, as the only source for mOutputStream is the argument to the constructor, and there appears to be an assumption of valid pointer arguments throughout this code. Being the paranoid type myself, I would check anyways... In any case, the crash itself is due to a bug in the xpcom io code, so I will file a bug over there with the fix. Bug# 55003 Sorry for taking so long to get this to the correct person (hopefully I have it now)... The real-and-for-true callstack: nsOutputStream::close() line 246 + 17 bytes nsLocalMailCopyState::~nsLocalMailCopyState() line 382 nsLocalMailCopyState::`scalar deleting destructor'(unsigned int 0x00000001) + 15 bytes nsMsgLocalMailFolder::ClearCopyState() line 1843 + 36 bytes nsMsgLocalMailFolder::EndCopy(nsMsgLocalMailFolder * const 0x0255bf74, int 0x00000001) line 2439 nsMsgLocalMailFolder::CopyFileMessage(nsMsgLocalMailFolder * const 0x0255becc, nsIFileSpec * 0x03eb7d30, nsIMessage * 0x00000000, int 0x00000000, nsIMsgWindow * 0x00000000, nsIMsgCopyServiceListener * 0x03ebd4c0) line 2010 + 23 bytes nsMsgCopyService::DoNextCopy() line 246 + 78 bytes nsMsgCopyService::DoCopy(nsCopyRequest * 0x03ebd460) line 174 + 8 bytes nsMsgCopyService::CopyFileMessage(nsMsgCopyService * const 0x03ebe100, nsIFileSpec * 0x03eb7d30, nsIMsgFolder * 0x0255becc, nsIMessage * 0x00000000, int 0x00000000, nsIMsgCopyServiceListener * 0x03ebd4c0, nsIMsgWindow * 0x00000000) line 417 + 12 bytes nsMsgCopy::DoCopy(nsIFileSpec * 0x03eb7d30, nsIMsgFolder * 0x0255becc, nsIMessage * 0x00000000, int 0x00000000, nsIMsgWindow * 0x00000000, nsMsgComposeAndSend * 0x03ed5b60) line 305 + 67 bytes nsMsgCopy::StartCopyOperation(nsIMsgIdentity * 0x03cc9de0, nsIFileSpec * 0x03eb7d30, int 0x00000000, nsMsgComposeAndSend * 0x03ed5b60, const char * 0x0012f864, nsIMessage * 0x00000000) line 236 + 35 bytes nsMsgComposeAndSend::StartMessageCopyOperation(nsIFileSpec * 0x03eb7d30, int 0x00000000, char * 0x03eb55b0) line 4174 + 57 bytes nsMsgComposeAndSend::MimeDoFCC(nsFileSpec * 0x03e9c240, int 0x00000000, const char * 0x03b6f90c, const char * 0x03ed5340, const char * 0x03ed5420) line 4142 + 29 bytes nsMsgComposeAndSend::DoFcc() line 3114 + 74 bytes nsMsgComposeAndSend::DoDeliveryExitProcessing(nsIURI * 0x03ec9a84, unsigned int 0x00000000, int 0x00000000) line 3055 + 8 bytes nsMsgComposeAndSend::DeliverAsMailExit(nsIURI * 0x03ec9a84, unsigned int 0x00000000) line 3076 MailDeliveryCallback(nsIURI * 0x03ec9a84, unsigned int 0x00000000, void * 0x03ed5b60) line 2639 nsMsgDeliveryListener::OnStopRunningUrl(nsMsgDeliveryListener * const 0x03ecaea0, nsIURI * 0x03ec9a84, unsigned int 0x00000000) line 82 + 21 bytes nsUrlListenerManager::BroadcastChange(nsIURI * 0x03ec9a84, nsUrlNotifyType nsUrlNotifyStopRunning, unsigned int 0x00000000) line 97 nsUrlListenerManager::OnStopRunningUrl(nsUrlListenerManager * const 0x03ec9970, nsIMsgMailNewsUrl * 0x03ec9a84, unsigned int 0x00000000) line 110 + 18 bytes nsMsgMailNewsUrl::SetUrlState(nsMsgMailNewsUrl * const 0x03ec9a84, int 0x00000000, unsigned int 0x00000000) line 107 nsSmtpProtocol::ProcessProtocolState(nsIURI * 0x03ec9a84, nsIInputStream * 0x03ec8c30, unsigned int 0x000000cf, unsigned int 0x0000000b) line 1526 nsMsgProtocol::OnDataAvailable(nsMsgProtocol * const 0x03ec95a0, nsIChannel * 0x03ec9264, nsISupports * 0x03ec9a84, nsIInputStream * 0x03ec8c30, unsigned int 0x000000cf, unsigned int 0x0000000b) line 192 + 32 bytes nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x03e9c070) line 400 + 47 bytes nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x03e9c470) line 97 + 12 bytes PL_HandleEvent(PLEvent * 0x03e9c470) line 575 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00ac1b80) line 508 + 9 bytes _md_EventReceiverProc(HWND__ * 0x002803dc, unsigned int 0x0000c0b7, unsigned int 0x00000000, long 0x00ac1b80) line 1044 + 9 bytes USER32! 77e71820() 00ac1b80()
Scott, as acting Steve, is this worth looking into?
adding rtm need info. I think we should fix the crash by checking for null but I don't think we should research why this isn't working since we aren't seeing tons of other send page crashes.
Whiteboard: [rtm need info]
I may not be the "correct" person, but I think I can handle it :-) I assume the reason this isn't working is because the sent mail folder doesn't exist, and can't be created, so I don't think any research is needed.
Attached patch proposed patch (deleted) — Splinter Review
Scott, can I get an r=? I think it would be nicer to catch this error up front, but this fix works and is easy.
r=scottip
sr=mscott
changing to rtm+, just need ptd approval.
Whiteboard: [rtm need info] → [rtm+]
PDT marking [rtm++]
Whiteboard: [rtm+] → [rtm++]
fix checked in this weekend.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
QA contact to huang, Karen can you please test this on the branch?
QA Contact: esther → huang
Linux (2000-10-10-10 MN6) Win32 (2000-10-10-09 MN6) Mac (2000-10-10-10 MN6) I do not see the problem in these builds.
Keywords: vtrunk
Send Page won't crash the browser any more. Verified on WinNT 10-10-09-MN6 Verified on Linux 10-10-10-MN6 Verified on Mac 10-10-08-MN6 Marking as verified.
Status: RESOLVED → VERIFIED
Oops! I shouldn't mark as verified until I verify on the trunk build. Since there is keyword vtrunk here, I will verify on trunk again after RTM.
Reopening to Resolve as Fixed. Bugs stay resolved until verified on both the branch and the trunk.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Resolving as Fixed. vtrunk keyword is in place requesting trunk verification before this bug changes state to Verified. When this is verified on the trunk vtrunk keyword should be removed and the bug Status should be set to Verified. Sorry for the spam, just trying to make sure we cover all of our bases here.
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
No crash on WinNT 11-15-10-Mtrunk build anymore. Remove vtrunk on the keywords and Marking as verified.
Status: RESOLVED → VERIFIED
Keywords: vtrunk
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: