Closed Bug 134624 Opened 22 years ago Closed 22 years ago

crash in mail by selecting "send unsent messages" while already sending

Categories

(MailNews Core :: Networking: SMTP, defect)

Product:
MailNews Core
Component:
Networking: SMTP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: mozillazine, Assigned: Bienvenu)

References

Details

(Keywords: crash, Whiteboard: [ADT2])

Attachments

(1 file)

proposed fix to display progress and status for send later
6.85 KB, patch
bugzilla
: review+
sspitzer
: superreview+
asa
: approval+
Details | Diff | Splinter Review 
browser :
---------
using official 0.9.9 for Mac OS X release.


description:
-------------
the subject may look silly but here's what happened :

i had 3 big messages to send. i prepared them by selecting "send later". then i
connected to the net and selected "send unsent messages". but i got no feedback
telling me that any message were being sent... so, i figured nothing was
happening... and as i am a "stupid normal user" (grin), i selected again "send
unsent messages" --> crash.

well, that's two problems in fact :
- no feedback to the user for telling him that her messages are being sent
- crash on selecting "send unsent messages" instead of having some alert windows
with a message "your messages are already being sent, you fool !"

i cannot tell at the moment if this is reproducible as i *am* sending those bigh
messages right now and then i must leave... sorry.

stack trace :
-------------
Date/Time:  2002-04-01 14:07:57 +0200
OS Version: 10.1.2 (Build 5P48)

Command:    Mozilla
PID:        241

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x0000002c

Thread 0:
 #0   0x03c66680 in CutRow__9morkTableFP9nsIMdbEnvP9nsIMdbRow
 #1   0x03c66664 in CutRow__9morkTableFP9nsIMdbEnvP9nsIMdbRow
 #2   0x03ca33ac in RemoveHeaderFromDB__13nsMsgDatabaseFP8nsMsgHdr
 #3   0x03ca2fc4 in 0x3ca2fc4
 #4   0x03baa16c in DeleteMessage__20nsMsgLocalMailFolderFP11nsISupportsP12nsIMsgW
 #5   0x03ba756c in DeleteMessages__20nsMsgLocalMailFolderFP16nsISupportsArrayP12n
 #6   0x03b29138 in DeleteCurrentMessage__14nsMsgSendLaterFv
 #7   0x03b27a48 in OnStopSending__21SendOperationListenerFPCcUiPCwP11nsIFileSpec
 #8   0x03b0dbc4 in NotifyListenerOnStopSending__19nsMsgComposeAndSendFPCcUiPCwP11
 #9   0x03b0d210 in DoDeliveryExitProcessing__19nsMsgComposeAndSendFP6nsIURIUii
 #10  0x03b0d2a4 in DeliverAsMailExit__19nsMsgComposeAndSendFP6nsIURIUi
 #11  0x03b0b340 in SendDeliveryCallback__FP6nsIURIUi17nsMsgDeliveryTypeP11nsISupp
 #12  0x03b2ade8 in OnStopRunningUrl__21nsMsgDeliveryListenerFP6nsIURIUi
 #13  0x0362f8c8 in BroadcastChange__20nsUrlListenerManagerFP6nsIURI15nsUrlNotifyT
 #14  0x0362fa20 in OnStopRunningUrl__20nsUrlListenerManagerFP17nsIMsgMailNewsUrlU
 #15  0x03b6a728 in SetUrlState__16nsMsgMailNewsUrlFiUi
 #16  0x03b172a0 in ProcessProtocolState__14nsSmtpProtocolFP6nsIURIP14nsIInputStre
 #17  0x03b65fac in OnDataAvailable__13nsMsgProtocolFP10nsIRequestP11nsISupportsP1
 #18  0x01cd1f40 in HandleEvent__22nsOnDataAvailableEventFv
 #19  0x01cdfae0 in HandlePLEvent__23nsARequestObserverEventFP7PLEvent
 #20  0x005f0db0 in PL_HandleEvent
 #21  0x005f0c1c in PL_ProcessPendingEvents
 #22  0x00596abc in ProcessPendingEvents__16nsEventQueueImplFv
 #23  0x0254388c in ProcessPLEventQueue__26nsMacNSPREventQueueHandlerFv
 #24  0x02543650 in RepeatAction__26nsMacNSPREventQueueHandlerFRC11EventRecord
 #25  0x01f70b14 in DoRepeaters__8RepeaterFRC11EventRecord
 #26  0x025578f8 in DispatchEvent__16nsMacMessagePumpFiP11EventRecord
 #27  0x025574d0 in DoMessagePump__16nsMacMessagePumpFv
 #28  0x02556e4c in Run__10nsAppShellFv
 #29  0x0250b28c in Run__17nsAppShellServiceFv
 #30  0x004c8bb4 in main1__FiPPcP11nsISupports
 #31  0x004c968c in main

Thread 1:
 #0   0x7000497c in syscall
 #1   0x70557600 in BSD_waitevent
 #2   0x70554b80 in CarbonSelectThreadFunc
 #3   0x7002054c in _pthread_body

Thread 2:
 #0   0x7003f4c8 in semaphore_wait_signal_trap
 #1   0x7003f2c8 in _pthread_cond_wait
 #2   0x705593ec in CarbonOperationThreadFunc
 #3   0x7002054c in _pthread_body

Thread 3:
 #0   0x70044cf8 in semaphore_timedwait_signal_trap
 #1   0x70044cd8 in semaphore_timedwait_signal
 #2   0x7003f2b8 in _pthread_cond_wait
 #3   0x70283ea4 in TSWaitOnConditionTimedRelative
 #4   0x7027d748 in TSWaitOnSemaphoreCommon
 #5   0x702c2078 in TimerThread
 #6   0x7002054c in _pthread_body

Thread 4:
 #0   0x7003f4c8 in semaphore_wait_signal_trap
 #1   0x7003f2c8 in _pthread_cond_wait
 #2   0x70250ab0 in TSWaitOnCondition
 #3   0x7027d730 in TSWaitOnSemaphoreCommon
 #4   0x70243d14 in AsyncFileThread
 #5   0x7002054c in _pthread_body

Thread 5:
 #0   0x7003f4c8 in semaphore_wait_signal_trap
 #1   0x7003f2c8 in _pthread_cond_wait
 #2   0x7055b884 in CarbonInetOperThreadFunc
 #3   0x7002054c in _pthread_body

Thread 6:
 #0   0x70000978 in mach_msg_overwrite_trap
 #1   0x70005a04 in mach_msg
 #2   0x7017bf98 in __CFRunLoopRun
 #3   0x701b7100 in CFRunLoopRunSpecific
 #4   0x7017b8e0 in CFRunLoopRunInMode
 #5   0x7061be08 in NotificationThread__21XIOAudioDeviceManagerPB0
 #6   0x706141c0 in Entry__9CAPThreadPB0
 #7   0x7002054c in _pthread_body

Thread 7:
 #0   0x70000978 in mach_msg_overwrite_trap
 #1   0x70005a04 in mach_msg
 #2   0x70026a2c in _pthread_become_available
 #3   0x70026724 in pthread_exit
 #4   0x70020550 in _pthread_body


PPC Thread State:
  srr0: 0x03c66680 srr1: 0x0200f030                vrsave: 0x00000000
   xer: 0x20000020   lr: 0x03c66664  ctr: 0x03c688f0   mq: 0x00000000
    r0: 0x03c66664   r1: 0xbfffec50   r2: 0x039bf000   r3: 0x00000000
    r4: 0x00000001   r5: 0x03c6af04   r6: 0x00000062   r7: 0x00000190
    r8: 0x04eb8af8   r9: 0x85e39ff0  r10: 0xe0c493d1  r11: 0x03bff038
   r12: 0x039c06f0  r13: 0x00000000  r14: 0x00000036  r15: 0x0005d850
   r16: 0x00000001  r17: 0x80160fa8  r18: 0x000586a8  r19: 0x00001707
   r20: 0x00000000  r21: 0x0000001c  r22: 0x70004234  r23: 0x700042c8
   r24: 0x7016b0dc  r25: 0x006bac3c  r26: 0x8081ab5c  r27: 0x40bc2000
   r28: 0x00000000  r29: 0xbfffef00  r30: 0xe7560000  r31: 0x00000001

**********
Severity: major → critical
Keywords: crash
We should not allow Send Unsent Messages if we're already sending unsent
messages. JF, is it possible for you to prevent this? Looking at the code, I
suppose we could set a flag in the messenger object that we're doing a send
unsent and clear it when the send finishes, and then either disable or ignore
subsequent send unsent messages requests.
Status: NEW → ASSIGNED
Keywords: nsbeta1
I didn't crash, but I did get multiple copies of the messages, some assertions,
and no status/progress.  Is it because the send process status messages don't
work with an nsIMsgWindow?
I take it back - eventually, I did crash because the mMessage header in the
nsMsgSendLater object had been deleted. I didn't realize the send was still
going on, because there's no progress or status. So there's probably some sort
of ref-counting problem. I also had the copy to the sent folder failing multiple
times after the send succeeded.
This patch makes it so we can display progress and status when sending unsent
messages. This should help prevent people from doing this, and be helpful in
general!
QA Contact: gayatri → gchan
Bienvenu, thanks a lot for your quick response !
You're welcome - however, I don't know if I'll be allowed to check this in for
Moz 1.0 or not. I'm trying to get permission.
David, your patch seems ok but that won't prevent the user to press twice send
later! Why not adding a boolean in nsMessenger that you set to true in
nsMessenger::SendUnsentMessages and then later set it back to false when finish
(propably in the sendlater listener)?
JF, this bug fix will have two parts. I think displaying the status messages is
the most important part, because it will help all users of this command and will
also prevent real world users from crashing.
Comment on attachment 77119 [details] [diff] [review]
proposed fix to display progress and status for send later

R=ducarroz
Attachment #77119 - Flags: review+
Comment on attachment 77119 [details] [diff] [review]
proposed fix to display progress and status for send later

sr=sspitzer

can you go to interCaps before you check in?

sendUnsentMessages(), in the .idl and the .js
Attachment #77119 - Flags: superreview+
ok, thx, converted to intercaps in my tree.
Discussed in Mail News bug meeting.  Decided to ADT2 and plus this bug.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [ADT2]
Target Milestone: --- → mozilla1.0
Adding feedback will make it unlikely for soemone to do this twice and it will
benefit anyone who uses this feature.  nominating adt1.0.0
Keywords: adt1.0.0
I'm going to spin off a new bug for disabling this command while doing a send
unsent messages. bug 135454 filed.
updating platform, os's to ALL.
Component: Mail Database → Networking - SMTP
OS: MacOS X → All
Hardware: Macintosh → All
adt1.0.0+ (on ADT's behalf) for checkin approval into 1.0.
Keywords: adt1.0.0 → adt1.0.0+
Comment on attachment 77119 [details] [diff] [review]
proposed fix to display progress and status for send later

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #77119 - Flags: approval+
fix checked in to display status messages during send unsent messages.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Using
Commercial trunk
2002-04-08-09-trunk NT 4.0
2002-04-08-08-trunk linux 2.2
2002-04-07-08-trunk mac 9.2.2

Mozilla trunk
2002040809 on OS 10.1.3


I see in the bottom frame of Messenger(3 pane window) the following:
 -Sending unsent mesgs (only see this if you were offline when did the
                        send later)
 -Delivering mail
 -Mail sent successfully

Tried sending unsent mesgs via file menu, or by going offline then
going online and sending mesgs at the prompt or automatically and
they all worked. I saw the 3 display mesgs each time.

marking as verified for UI mesg. Tested both modern/classic.
Crash hasn't been fixed but that will be fixed by bug 135454.
Status: RESOLVED → VERIFIED
*** Bug 81625 has been marked as a duplicate of this bug. ***
This fix was checked/approved for trunk on 4-4.

We didn't branch for commercial until 4-10. So this
fix should be in the current branch builds.


Checked the following commercial branch builds:
2002042306 NT 4.0
2002042305 Mac 10.1.3
2002042308 linux 2.2

I see in the bottom frame of Messenger(3 pane window) the following:
 -Sending unsent mesgs (only see this if you were offline when did the
                        send later)
 -Delivering mail
 -Mail sent successfully

adding keyword verified1.0.0
Keywords: verified1.0.0
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

Creator:
Created:
Updated:
Size: