19166 - [DOGFOOD]:Problem saving copy of email to sent folder, leads to crash

Status: VERIFIED FIXED

(MailNews Core :: Networking, defect, P3)

Description

[Jim Roskind]

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.

Comment 1

[Scott MacGregor]

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.

Comment 2

[lchiang]

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

[chris hofmann]

jar sez, has used seamonkey before, and observed this problem
using a recent build.

Comment 4

[lchiang]

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)

Comment 5

[Scott MacGregor]

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

Comment 6

[Scott MacGregor]

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.

Comment 7

[Scott MacGregor]

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

[rhp (gone)]

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

Comment 9

[rickg]

Putting on PDT radar.

Comment 10

[Scott MacGregor]

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.

Comment 11

[Scott MacGregor]

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

Comment 12

[Scott MacGregor]

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

[esther]

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.

Comment 14

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/75e83654d487
[fenix] For https://github.com/mozilla-mobile/fenix/issues/19166: Increases tab_tray_list bottom padding