315091 - Thunderbird crashes when using filter to forward mail [@ msg_pick_real_name]

Status: RESOLVED FIXED

(Thunderbird :: General, defect)

Description

[chris-moz]

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8) Gecko/20051025 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8) Gecko/20051025 Firefox/1.5

I tried setting up a filter on a mailbox to forward mail to a Gmail account, then used the "Run now" button. If the filter criteria found only a few matching mails, it went as expected. If more than 10 (approx) mails were found by the filter, Thunderbird crash and the Feedback Agent appear. The filter log show all mails that matched the filter criteria.

Reproducible: Always

Steps to Reproduce:
1. Set up a filter "IF Subject isn't <some nonsense> THEN forward to <some account>"
2. Run the filter on a folder
3.

Actual Results:  
Crash, Dr. Watson, and the Feedback Agent

Expected Results:  
Mails meeting the filter criteria should have been forwarded to the target address

Comment 1

[Ray Booysen]

Can you please post the talkback incident ID?

Comment 2

[chris-moz]

(In reply to comment #1)
> Can you please post the talkback incident ID?

TB11441144E 

Comment 3

[David :Bienvenu]

Here's the stack trace. Most likely, either attachment or attachment->mURL is null. I suspect the latter. In either case, proposedName is empty, which means we have an attachment w/o a proposed name. I don't know if the attachment is a forwarded message, or if it's an attachment in a message getting forwarded (which I don't think is considered an attachment in this context)

 Stack Trace  	
msg_pick_real_name  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/compose/src/nsMsgCompUtils.cpp, line 1667]
nsMsgComposeAndSend::AddCompFieldRemoteAttachments  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/compose/src/nsMsgSend.cpp, line 2466]
nsMsgComposeAndSend::HackAttachments  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/compose/src/nsMsgSend.cpp, line 2639]
nsMsgComposeAndSend::Init  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/compose/src/nsMsgSend.cpp, line 3244]
nsMsgComposeAndSend::CreateAndSendMessage  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/compose/src/nsMsgSend.cpp, line 4087]
nsMsgCompose::_SendMsg  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/compose/src/nsMsgCompose.cpp, line 941]
nsMsgCompose::SendMsg  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/compose/src/nsMsgCompose.cpp, line 1121]
nsMsgComposeService::ForwardMessage  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/compose/src/nsMsgComposeService.cpp, line 1181]
nsMsgFilterAfterTheFact::ApplyFilter  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/base/search/src/nsMsgFilterService.cpp, line 680]
nsMsgFilterAfterTheFact::OnSearchDone  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/base/search/src/nsMsgFilterService.cpp, line 471]
nsMsgSearchSession::NotifyListenersDone  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/base/search/src/nsMsgSearchSession.cpp, line 597]
nsMsgSearchSession::OnStopRunningUrl  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/base/search/src/nsMsgSearchSession.cpp, line 386]
nsUrlListenerManager::BroadcastChange  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/base/src/nsUrlListenerManager.cpp, line 97]
nsUrlListenerManager::OnStopRunningUrl  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/base/src/nsUrlListenerManager.cpp, line 123]
nsImapMailFolder::SetUrlState  [e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/mailnews/imap/src/nsImapMailFolder.cpp, line 6228]

Comment 4

[Ahmet Serkan Tıratacı]

I think this crash occurs whatever the criteria is for forwarding. Replying should also be investigated. I saw the same crash when I applied a filter that is expected to forward messages in a folder depending on their importance. The large number of messages should be the main problem.

Comment 5

[Scott MacGregor]

This is a new top crash most folks seem to be seeing when using a filter rule to forward messages (based on the top crash data I see in talkback). 

Comment 6

[Adam Guthrie]

*** Bug 323587 has been marked as a duplicate of this bug. ***

Comment 7

[Adam Guthrie]

*** Bug 314471 has been marked as a duplicate of this bug. ***

Comment 8

[Jean-Michel Reghem]

Maybe there is more information in the bug 301808 

Comment 9

[Yevgeny Barkovsky]

I have same problem, but I think on other reasons. I have reseaved every day mail with zip attachment sized from 1 to 6 Mb, and I have filter on these messages to redirect to other recipients. And I have crash with Access Violation. 
Also, I have many filters, and sometimes many messages arrived, but crashes only on specified case.
My OS is Windows 2000, thunderbird version 1.5.0.5 (20060719)

Comment 10

[Wayne Mery (:wsmwk)]

also linux (no surprise)

for example TB21742801 and TB22933785
Stack Signature	 msg_pick_real_name() 7a69a558
Product ID	Thunderbird15
Build ID	2006071913
Trigger Time	2006-08-03 09:48:36.0
Platform	LinuxIntel
Operating System	Linux 2.6.16.13-4-default
Module	thunderbird-bin + (00801421)
User Comments	Thunderbird 1.5.0.5 More than 130 emails in inbox. Clicked 'Run Now' on a new message filter for the whole inbox which should forward the message to another email. Then Tbird crashes out. Happened twice.
Trigger Reason	SIGSEGV: Segmentation Fault: (signal 11)
Source File, Line No.	/builds/tinderbox/Tb-Mozilla1.8.0/Linux_2.4.18-14_Depend/mozilla/mailnews/compose/src/nsMsgCompUtils.cpp, line 848
Stack Trace 	
msg_pick_real_name()  [mozilla/mailnews/compose/src/nsMsgCompUtils.cpp, line 848]
nsMsgComposeAndSend::AddCompFieldRemoteAttachments()  [mozilla/mailnews/compose/src/nsMsgSend.cpp, line 62]
nsMsgComposeAndSend::HackAttachments()  [mozilla/mailnews/compose/src/nsMsgSend.cpp, line 2638]
nsMsgComposeAndSend::Init()  [mozilla/mailnews/compose/src/nsMsgSend.cpp, line 3244]
nsMsgComposeAndSend::CreateAndSendMessage()  [mozilla/mailnews/compose/src/nsMsgSend.cpp, line 4089]
nsMsgCompose::_SendMsg()  [mozilla/mailnews/compose/src/nsMsgCompose.cpp, line 943]
nsMsgCompose::SendMsg()  [mozilla/mailnews/compose/src/nsMsgCompose.cpp, line 1122]
nsMsgComposeService::ForwardMessage()  [mozilla/mailnews/compose/src/nsMsgComposeService.cpp, line 848]
nsMsgFilterAfterTheFact::ApplyFilter()  [mozilla/mailnews/base/search/src/nsMsgFilterService.cpp, line 848]
nsMsgSearchSession::NotifyListenersDone()  [mozilla/mailnews/base/search/src/nsMsgSearchSession.cpp, line 256]
nsMsgSearchSession::TimerCallback()  [mozilla/mailnews/base/search/src/nsMsgSearchSession.cpp, line 530]
nsTimerImpl::Fire()  [mozilla/xpcom/threads/nsTimerImpl.cpp, line 395]
handleTimerEvent()  [mozilla/xpcom/threads/nsTimerImpl.cpp, line 462]
PL_HandleEvent()  [mozilla/xpcom/threads/plevent.c, line 688]
PL_ProcessPendingEvents()  [mozilla/xpcom/threads/plevent.c, line 623]
nsEventQueueImpl::ProcessPendingEvents()  [mozilla/xpcom/threads/nsEventQueue.cpp, line 421]
event_processor_callback()  [mozilla/widget/src/gtk2/nsAppShell.cpp, line 71]
libglib-2.0.so.0 + 0x5092d (0xb78f592d)
libglib-2.0.so.0 + 0x27abd (0xb78ccabd)
libglib-2.0.so.0 + 0x2acbf (0xb78cfcbf)
libglib-2.0.so.0 + 0x2b069 (0xb78d0069)
libgtk-x11-2.0.so.0 + 0x1319e4 (0xb7b939e4)
nsAppShell::Run()  [mozilla/widget/src/gtk2/nsAppShell.cpp, line 141]
nsAppStartup::Run()  [mozilla/toolkit/components/startup/src/nsAppStartup.cpp, line 151]
XRE_main()  [mozilla/toolkit/xre/nsAppRunner.cpp, line 848]
main()  [mozilla/mail/app/nsMailApp.cpp, line 63]
libc.so.6 + 0x1587c (0xb73ec87c)

Comment 11

[Scott MacGregor]

blocking on a top crash

Comment 12

[David :Bienvenu]

I can't reproduce this problem on the trunk, perhaps partly because my smtp server limits the number of messages I can send...I'll try 2.0, but I suspect I still won't be able to reproduce it.

Comment 13

[Stephanie Daugherty [:sdaugherty]]

*** Bug 362188 has been marked as a duplicate of this bug. ***

Comment 15

[David :Bienvenu]

there is a theory that forwarding messages with blank subjects causes this issue...I'm not able to reproduce that, but am investigating that theory.

Comment 16

[David :Bienvenu]

this is fixed in 2.0, I'm reasonably sure, but it's broken in 1.5.0.x - in fact, just trying to do an edit message as new on a message w/o a subject crashes in 1.5.0.x, with a similar stack trace (which I think explains why this is a top crash...). I'm trying to figure out why it's fixed in 2.0

Comment 17

[David :Bienvenu]

some combination of  patches in bug 154332 and bug 188108 fixed this.

Comment 18

[Henrik Skupin [:whimboo][⌚️UTC+2]]

David for the BRANCH_1_8_0 there is no checking if mURL is null:

http://lxr.mozilla.org/mozilla1.8.0/source/mailnews/compose/src/nsMsgSend.cpp#2464

The null check exists in BRANCH_1_8 and Trunk:
http://lxr.mozilla.org/mozilla1.8/source/mailnews/compose/src/nsMsgSend.cpp#2338
http://lxr.mozilla.org/seamonkey/source/mailnews/compose/src/nsMsgSend.cpp#2299

Could this be the cause?

Comment 19

[David :Bienvenu]

Henrik, I think you're comparing two different call sites to msg_pick_real_name - the null check you refer to on the 1_8 branch and trunk has been there for a long time. But the code is confusing enough that I could be wrong.

Comment 20

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Oh you are right. I was looking inside the wrong function.

If I look at TB28153142W now and click the link to msg_pick_real_name() at line 848 I see source which is 800 lines before the desired function. Is msg_pick_real_name() correct or what happens here? The code hasn't changed.

Comment 21

[David :Bienvenu]

the fix wasn't to change the code that crashed - the fix was to make it so there's always an attachment name when forwarding mail, so we don't have the crash condition of no name and no url.