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)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: acraigwest, Assigned: Bienvenu)
References
()
Details
(Keywords: crash, Whiteboard: [rtm++])
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
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"
Comment 1•24 years ago
|
||
does not crash on 092708 mozilla trunk build running on NT.
Comment 2•24 years ago
|
||
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
Reporter | ||
Comment 3•24 years ago
|
||
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 → ---
Reporter | ||
Comment 4•24 years ago
|
||
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...
Reporter | ||
Comment 5•24 years ago
|
||
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... :-)
Comment 6•24 years ago
|
||
setting bug status to New and reassigning to default owners.
Assignee: asa → bienvenu
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: doronr → esther
Assignee | ||
Comment 7•24 years ago
|
||
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
Assignee | ||
Comment 8•24 years ago
|
||
well, I'll nominate this for RTM, but I doubt it'll be accepted.
Reporter | ||
Comment 9•24 years ago
|
||
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()
Assignee | ||
Comment 10•24 years ago
|
||
Scott, as acting Steve, is this worth looking into?
Comment 11•24 years ago
|
||
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]
Assignee | ||
Comment 12•24 years ago
|
||
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.
Assignee | ||
Comment 13•24 years ago
|
||
Assignee | ||
Comment 14•24 years ago
|
||
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.
Comment 15•24 years ago
|
||
r=scottip
Comment 16•24 years ago
|
||
sr=mscott
Assignee | ||
Comment 17•24 years ago
|
||
changing to rtm+, just need ptd approval.
Whiteboard: [rtm need info] → [rtm+]
Assignee | ||
Comment 19•24 years ago
|
||
fix checked in this weekend.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 20•24 years ago
|
||
QA contact to huang, Karen can you please test this on the branch?
QA Contact: esther → huang
Comment 21•24 years ago
|
||
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.
Comment 22•24 years ago
|
||
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
Comment 23•24 years ago
|
||
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.
Comment 24•24 years ago
|
||
Reopening to Resolve as Fixed. Bugs stay resolved until verified on both the
branch and the trunk.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 25•24 years ago
|
||
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 ago → 24 years ago
Resolution: --- → FIXED
Comment 26•24 years ago
|
||
No crash on WinNT 11-15-10-Mtrunk build anymore.
Remove vtrunk on the keywords and Marking as verified.
Status: RESOLVED → VERIFIED
Keywords: vtrunk
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•