Closed
Bug 19166
Opened 25 years ago
Closed 25 years ago
[DOGFOOD]:Problem saving copy of email to sent folder, leads to crash
Categories
(MailNews Core :: Networking, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
M12
People
(Reporter: jar, Assigned: mscott)
Details
(Whiteboard: [PDT+] 11/26)
When I send email, I get notification that the save to the sent folder has failed, and I'm asked if I want to return to the composer window. First off, the save to the sent folder should not have failed :-(. If I say OK, then I go back to the compose folder. If I press CANCEL, then I crash. Note that the prefs for setting where I save messages are pretty messed up currently. When I view the pref, I'm shown an rdf:http://... URL, even though the pull-down box has the *real* set of possible places to save a copy. I checked my prefs file, and it does indeed have the correct Sent folder as a target. I was running on 11-17-17 build.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M12
Assignee | ||
Comment 1•25 years ago
|
||
Jar, have you sent mail using 5.0 before? I'm wondering if this was a new problem with your most recent build. Or if maybe we have a migration problem where we didn't properly migrate your Sent Folder back when you first migrated your 4.5 account to 5.0 I know we had a problem with migrating the Sent folder from 4.5 to 5.0 3 or 4 weeks ago. You only would have been bit by it if you migrated an account with a build during the time it was broken. Hmm.
Esther - pls check out. There are two issues here: 1) Copying to sent folder failing - need to find out why 2) Crash when clicking Cancel. I did that on an M11 build the other day and didn't have a problem. Will need to try.
Comment 3•25 years ago
|
||
jar sez, has used seamonkey before, and observed this problem using a recent build.
here is one of the talkback reports: http://cyclone/reports/incidenttemplate.CFM?reportID=1047&style=0&tc=1087&cp=36& bbid=1039871 I pasted the stack trace: GlobalWindowImpl::GetBrowserWindowInterface [d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 2627] GlobalWindowImpl::Focus [d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 1222] nsWebShellWindow::HandleEvent [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWebShellWindow.cpp, line 566] nsWindow::DispatchEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 441] nsWindow::DispatchWindowEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 458] nsWindow::DispatchFocus [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3616] nsWindow::ProcessMessage [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2823] nsWindow::WindowProc [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 625] USER32.dll + 0x19d0 (0x77e719d0) USER32.dll + 0x1982 (0x77e71982) ntdll.dll + 0x163a3 (0x77f763a3) nsWindow::~nsWindow [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 259] nsWindow::`scalar deleting destructor' nsTextWidget::Release [d:\builds\seamonkey\mozilla\widget\src\windows\nsTextWidget.cpp, line 51] nsWebShell::~nsWebShell [d:\builds\seamonkey\mozilla\webshell\src\nsWebShell.cpp, line 681] nsWebShell::`scalar deleting destructor' nsWebShell::Release [d:\builds\seamonkey\mozilla\webshell\src\nsWebShell.cpp, line 771] nsWebShellWindow::Close [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWebShellWindow.cpp, line 493] nsMsgCompose::CloseWindow [d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgCompose.cpp, line 568] nsMsgComposeSendListener::OnStopCopy [d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgCompose.cpp, line 1273] nsMsgComposeAndSend::NotifyListenersOnStopCopy [d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgSend.cpp, line 2911] nsMsgComposeAndSend::DoFcc [d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgSend.cpp, line 2689] nsMsgComposeAndSend::DoDeliveryExitProcessing [d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgSend.cpp, line 2627] nsMsgComposeAndSend::DeliverAsMailExit [d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgSend.cpp, line 2634] MailDeliveryCallback [d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgSend.cpp, line 2315] nsMsgDeliveryListener::OnStopRunningUrl [d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgDeliveryListener.cpp, line 82] nsUrlListenerManager::BroadcastChange [d:\builds\seamonkey\mozilla\mailnews\base\src\nsUrlListenerManager.cpp, line 89] nsUrlListenerManager::OnStopRunningUrl [d:\builds\seamonkey\mozilla\mailnews\base\src\nsUrlListenerManager.cpp, line 100] nsMsgMailNewsUrl::SetUrlState [d:\builds\seamonkey\mozilla\mailnews\base\util\nsMsgMailNewsUrl.cpp, line 136] nsSmtpProtocol::ProcessProtocolState [d:\builds\seamonkey\mozilla\mailnews\compose\src\nsSmtpProtocol.cpp, line 1480] nsMsgProtocol::OnDataAvailable [d:\builds\seamonkey\mozilla\mailnews\base\util\nsMsgProtocol.cpp, line 170] nsOnDataAvailableEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 417] nsStreamListenerEvent::HandlePLEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 174] PL_HandleEvent [plevent.c, line 538] [plevent.c, line 499] _md_EventReceiverProc [plevent.c, line 976] USER32.dll + 0x1820 (0x77e71820) nsAppShellService::Run [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 489] main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 586] main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 677] mainCRTStartup() KERNEL32.dll + 0x1ba06 (0x77f1ba06)
Assignee | ||
Comment 5•25 years ago
|
||
With the release builds, I'm crashing on about 10% of the messages I send and it's probably the same problem that jar is seeing. Just so we don't get confused, I'm going to file a new bug on the fact that editing the messaging prefs for your sent folder shows all these funky urls that start with rdf:// (as jar mentioned above).
Assignee | ||
Updated•25 years ago
|
Severity: critical → normal
Assignee | ||
Updated•25 years ago
|
Severity: normal → critical
Assignee | ||
Comment 6•25 years ago
|
||
Bug #19400 has been filed to track the rdf url problem in the account manager. Now about this crash with copying to the sent folder. It looks to me like maybe we have a race condition between focus and destroying the compose window. The stack trace shows us closing the compose window, the webshell is calling it's Destroy method, the nsWindow associated with that webshell is getting destroyed but while destroying the window, some focus code tries to get focus on the window that's being destroyed. That's my initial guess anyway. Adding Chris Saari to the cc list.
Assignee | ||
Comment 7•25 years ago
|
||
Found it! (At least I think I did). The stack trace Lisa posted may be another problem but it's not the problem that Jar and I are seeing I think. I finally triggered this crash on a debug build. We were crashing in a mailnews uri method which was broadcasting to all listeners of the uri that we were about to start processing this mailbox url. One of these listeners had already been deleted. Theoretically, someone in compose intiated the save to sent folder operation and they list themselves as a url listener. I'm crashing because the url listener has already been deleted. And I looked and the compose window has already been deleted and shut down before waiting for the copy to sent folder operation to be completed. That's leaving a dangling pointer in the mailnewsurl for this listener. Adding jefft, ducarroz and rhp to the cc list. The compose window shouldn't be getting destroyed until after the copy to send folder has been completed.
Comment 8•25 years ago
|
||
Well, I know the way it was coded was to wait until all copies are completed before deleting the compose window. Not sure why this would be happening early, without debugging. - rhp
Assignee | ||
Comment 10•25 years ago
|
||
I'm in the zone today =). On a whim...I decided to see if effecting the state of the Sent folder could make this crash reproducible. Turns out the answer is yes. If the mail summary file for the Sent folder is out of date we crash when the compose / copy service code tries to copy the sent message to the folder. So touching my Sent folder before I run allows me to reproduce this every time now.
Assignee | ||
Comment 11•25 years ago
|
||
Okay I have a fix for this bug. I changed the ref counting model for mailnews url listeners. However, I need to be careful to test against introducing new ref counting leaks by making this change. I'm going to play with it today and if I still like what I see I'll check it in today. One less dogfood bug to worry about...
Updated•25 years ago
|
Whiteboard: [PDT+] → [PDT+] 11/26
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 12•25 years ago
|
||
I've checked in my changes for this fix. In order to verify, you need to make sure your sent mail summary folder is out of date when you send a message. I did this by doing a "touch" on my Sent folder. i.e. go to the directory where your sent folder is and type: "touch Sent". Then run 5.0, bring up a compose window and send yourself a message. Before this fix, the message would be sent but we would crash when we wrote the message to the sent folder. Now we don't crash.
Comment 13•25 years ago
|
||
Update: I tried to reproduce this using mscott's scenario (however I had to replace the Sent folder with one from another profile in order to "touch" the folder because "touch" doesn't seem to work with in my win98 MSDOS window)using builds 11/18 and 11/22-09, I couldn't reproduce the crash. I then went back to the 11/17 build which was the build this was reported on. I did crash with the 11/17 build. I will verify this using mscott's scenario on todays builds 1999112309 on win98 and linux, build 1999112308 on mac and it doesn't crash. If this is still crashing for the reporter or anybody commenting on this bug please reopen it.
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
•