IMAP: Quit with unsaved draft, save to draft crashes.

VERIFIED WORKSFORME

Status

MailNews Core
Backend
P1
critical
VERIFIED WORKSFORME
19 years ago
10 years ago

People

(Reporter: laurel, Assigned: jefft)

Tracking

({crash})

Trunk
x86
Linux
crash

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3+][nsbeta2-][pdtp1)

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
Using 2000-03-30-09m15 commercial build linux rh6.0
Haven't been able to reproduce on NT or mac.


When using Quit while an unsaved message composition window is open, the mail
and/or browser windows close first then the "save to draft" warning appears
(with compose window still open).  If you Save to Draft at this point, a crash
will occur if your drafts pref points to folder on the IMAP server.  Does not
happen if POP account or IMAP drafts pref points to drafts folder on local
folders hierarchy.

1.  Open mail window, login to IMAP account.
2.  Account settings Copies & Folders pref should be pointing to Drafts folder
on the IMAP server. 
3.  Click New Msg. Type addressee, subject and body.
4.  File|Quit with new message window open.
5.  Mail window (and browser if opened) closes. Save to Draft warning displays
over the open composition window.  Click Save to Draft in the warning dialog.

Result:  crash occurs. 

Talkback incident #7708485.
(Reporter)

Comment 1

19 years ago
Created attachment 7113 [details]
talkback incident 7708485
(Reporter)

Comment 2

19 years ago
Not sure who this would ultimately be assigned to...
Assignee: selmer → ducarroz
QA Contact: lchiang → laurel

Updated

19 years ago
Severity: normal → critical
Keywords: beta2, crash

Comment 3

19 years ago
bulk move to M16.  
Target Milestone: --- → M16
Accepting
Status: NEW → ASSIGNED

Comment 5

18 years ago
Putting on [beta2+] radar.
Whiteboard: [beta2+]

Updated

18 years ago
Keywords: nsbeta2

Comment 6

18 years ago
Updating [beta2+] in Status Summary to [nsbeta2+]
Keywords: beta2
Whiteboard: [beta2+] → [nsbeta2+]

Comment 7

18 years ago
Mass moving M16 to M17 - look for nsbeta2 before anything else.
Target Milestone: M16 → M17

Comment 8

18 years ago
marking P1
Priority: P3 → P1
Reassign to Seth as I don't have a Linux box at home. Thanks Seth.
Assignee: ducarroz → sspitzer
Status: ASSIGNED → NEW
accepting.

I love New York in June, how about you?
Status: NEW → ASSIGNED
got a stack trace:

#0  0x414d8f88 in nsFrameList::DestroyFrames (this=0x8289ea0,
aPresContext=0x81ea808) at nsFrameList.cpp:34
#1  0x41471c67 in nsBoxFrame::Destroy (this=0x8289ea0, aPresContext=0x81ea808)
at nsBoxFrame.cpp:829
#2  0x414d8fa3 in nsFrameList::DestroyFrames (this=0x8289e34,
aPresContext=0x81ea808) at nsFrameList.cpp:35
#3  0x4120564d in nsContainerFrame::Destroy (this=0x8289e00,
aPresContext=0x81ea808) at nsContainerFrame.cpp:95
#4  0x41471c67 in nsBoxFrame::Destroy (this=0x8289e00, aPresContext=0x81ea808)
at nsBoxFrame.cpp:829
#5  0x4125f599 in nsGfxScrollFrame::Destroy (this=0x8289dfc,
aPresContext=0x81ea808) at nsGfxScrollFrame.cpp:426
#6  0x414d8fa3 in nsFrameList::DestroyFrames (this=0x8289dbc,
aPresContext=0x81ea808) at nsFrameList.cpp:35
#7  0x4120564d in nsContainerFrame::Destroy (this=0x8289d88,
aPresContext=0x81ea808) at nsContainerFrame.cpp:95
#8  0x4125d586 in ViewportFrame::Destroy (this=0x8289d88,
aPresContext=0x81ea808) at nsViewportFrame.cpp:143
#9  0x4121404b in FrameManager::~FrameManager (this=0x8251400, __in_chrg=3) at
nsFrameManager.cpp:382
#10 0x41213f84 in FrameManager::Release (this=0x8251400) at
nsFrameManager.cpp:362
#11 0x4123cae5 in PresShell::~PresShell (this=0x8251178, __in_chrg=3) at
nsPresShell.cpp:1054
#12 0x4123c756 in PresShell::Release (this=0x8251178) at nsPresShell.cpp:968
#13 0x402e8e6c in nsCOMPtr<nsIPresShell>::~nsCOMPtr (this=0x8212b98,
__in_chrg=2) at ../../dist/include/nsCOMPtr.h:489
#14 0x414cd68f in DocumentViewerImpl::~DocumentViewerImpl (this=0x8212b60,
__in_chrg=3) at nsDocumentViewer.cpp:432
#15 0x414ccf52 in DocumentViewerImpl::Release (this=0x8212b60) at
nsDocumentViewer.cpp:344
#16 0x402e02f6 in nsCOMPtr<nsIContentViewer>::assign_assuming_AddRef
(this=0x81d1cc8, newPtr=0x0) at ../../dist/include/nsCOMPtr.h:471
#17 0x402e0344 in nsCOMPtr<nsIContentViewer>::assign_with_AddRef
(this=0x81d1cc8, rawPtr=0x0) at ../../dist/include/nsCOMPtr.h:848
#18 0x402e9a5b in nsCOMPtr<nsIContentViewer>::operator= (this=0x81d1cc8,
rhs=0x0) at ../../dist/include/nsCOMPtr.h:583
#19 0x4031fdb0 in nsDocShell::Destroy (this=0x81d1c40) at nsDocShell.cpp:1322
#20 0x402da9dd in nsWebShell::Destroy (this=0x81d1c40) at nsWebShell.cpp:1589
#21 0x407167e8 in nsXULWindow::Destroy (this=0x81bddf8) at nsXULWindow.cpp:422
#22 0x40722aee in nsWebShellWindow::Destroy (this=0x81bddf8) at
nsWebShellWindow.cpp:1731
#23 0x4071f757 in nsWebShellWindow::Close (this=0x81bddf8) at
nsWebShellWindow.cpp:358
#24 0x4071b95c in nsAppShellService::~nsAppShellService (this=0x80f47c0,
__in_chrg=3) at nsAppShellService.cpp:96
#25 0x4071bb04 in nsAppShellService::Release (this=0x80f47c0) at
nsAppShellService.cpp:109
#26 0x406aff09 in nsXPCWrappedNative::~nsXPCWrappedNative (this=0x8e912b0,
__in_chrg=3) at xpcwrappednative.cpp:390
#27 0x406af2c5 in nsXPCWrappedNative::Release (this=0x8e912b0) at
xpcwrappednative.cpp:71
#28 0x406af3a1 in nsXPCWrappedNative::JSObjectFinalized (this=0x8e912b0,
cx=0x8448190, obj=0x8d6e740) at xpcwrappednative.cpp:95
#29 0x406b6ec0 in WrappedNative_Finalize (cx=0x8448190, obj=0x8d6e740) at
xpcwrappednativejsops.cpp:695
#30 0x401f0e8a in js_FinalizeObject (cx=0x8448190, obj=0x8d6e740) at
jsobj.c:1483
#31 0x401ce127 in js_GC (cx=0x8448190) at jsgc.c:1035
#32 0x401cd815 in js_ForceGC (cx=0x8448190) at jsgc.c:770
#33 0x401aa67f in js_DestroyContext (cx=0x8448190, gcmode=JS_FORCE_GC) at
jscntxt.c:205
#34 0x4019f693 in JS_DestroyContext (cx=0x8448190) at jsapi.c:789
#35 0x407f1ebf in mozJSComponentLoader::~mozJSComponentLoader (this=0x811ea18,
__in_chrg=3) at mozJSComponentLoader.cpp:174
#36 0x407f2050 in mozJSComponentLoader::Release (this=0x811ea18) at
mozJSComponentLoader.cpp:181
#37 0x400cd51c in nsSupportsHashtable::ReleaseElement (aKey=0x8125420,
aData=0x811ea18, closure=0x0) at nsHashtable.cpp:392
#38 0x400cc9b6 in _hashEnumerate (he=0x80662b0, i=0, arg=0xbffff82c) at
nsHashtable.cpp:99
#39 0x40255b71 in PL_HashTableEnumerateEntries (ht=0x80685e8, f=0x400cc980
<_hashEnumerate(PLHashEntry *, int, void *)>, arg=0xbffff82c) at plhash.c:413
#40 0x400ccef8 in nsHashtable::Enumerate (this=0x80685d8, aEnumFunc=0x400cd4ec
<nsSupportsHashtable::ReleaseElement(nsHashKey *, void *, void *)>, closure=0x0)
at nsHashtable.cpp:237
#41 0x400cda03 in nsSupportsHashtable::Enumerate (this=0x80685d8,
aEnumFunc=0x400cd4ec <nsSupportsHashtable::ReleaseElement(nsHashKey *, void *,
void *)>, closure=0x0) at nsHashtable.h:135
#42 0x400cd570 in nsSupportsHashtable::~nsSupportsHashtable (this=0x80685d8,
__in_chrg=3) at nsHashtable.cpp:398
#43 0x4010294d in nsComponentManagerImpl::Shutdown (this=0x8065248) at
nsComponentManager.cpp:363
#44 0x400c5fde in NS_ShutdownXPCOM (servMgr=0x0) at nsXPComInit.cpp:626
#45 0x805440b in main (argc=2, argv=0xbffff9f4) at nsAppRunner.cpp:1097
#46 0x4056bcb3 in __libc_start_main (main=0x805420c <main>, argc=2,
argv=0xbffff9f4, init=0x804f418 <_init>, fini=0x805f1a0 <_fini>,
rtld_fini=0x4000a350, stack_end=0xbffff9ec) at
../sysdeps/generic/libc-start.c:78
(Assignee)

Comment 12

18 years ago
I'll take this one. I think this happens on all platform. The problem is similar
to the empty trash on exit. We cannot shutdown any components prior we finish
saving draft. This needs to be monitor/semaphor quarded.
Assignee: sspitzer → jefft
Status: ASSIGNED → NEW
(Assignee)

Comment 13

18 years ago
This bug depends on bug 44203 to be fixed.
Depends on: 44203
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 14

18 years ago
changing qa assigned to myself since I'll be verifying the related bug.
QA Contact: laurel → pmock
(Assignee)

Comment 15

18 years ago
fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 16

18 years ago
Verified as fixed on win32, linux, and macos using the following builds:
 win32 commercial seamonkey build 2000-070609-m17 installed on P500 Win98 and on 
a P200 Winnt 4.0
 linux commercial seamonkey build 2000-070608-m17 installed on P200 RedHat 6.1
 macos commercial seamonkey build 2000-070608-m17 installed on G3/400 OS 9.04

I could not reproduce original problem. I tested using the plain text and html 
editor.
Status: RESOLVED → VERIFIED

Comment 17

18 years ago
Oops. I meant to verify bug 44203.
http://bugzilla.mozilla.org/show_bug.cgi?id=44203

I can reproduce this bug following Laurels steps.
One thing to be aware.  I used File|Quit from the Messenger window.  The Quit 
option was grayed out in the compose window.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

Comment 18

18 years ago
Talkback Incident 13733992
http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=8&cp=1&ck1=S
User+email+address&cd1=%25pmock%40netscape%2Ecom%25&co1=like&bbid=13733992

Talkback Incident 13733592
http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=8&cp=2&ck1=S
User+email+address&cd1=%25pmock%40netscape%2Ecom%25&co1=like&bbid=13733592

Talkback Incident 13291475
http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=8&cp=4&ck1=S
User+email+address&cd1=%25pmock%40netscape%2Ecom%25&co1=like&bbid=13291475

Talkback Incident 13734678
http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=9&cp=1&ck1=S
User+email+address&cd1=%25pmock%40netscape%2Ecom%25&co1=like&bbid=13734678
(Assignee)

Comment 19

18 years ago
Any ideas how to get the stack trace from the talkback report? The saving part 
of the bug should be fixed. We shouldn't have the data loss problem.
(Assignee)

Comment 20

18 years ago
Never mind. I got the call stack.

 Call Stack:    (Signature = nsContainerFrame::Destroy() 35fefdca) 

nsContainerFrame::Destroy() 
ViewportFrame::Destroy() 
FrameManager::~FrameManager() 
FrameManager::Release() 
PresShell::~PresShell() 
PresShell::Release() 
nsCOMPtr_base::~nsCOMPtr_base() 
DocumentViewerImpl::~DocumentViewerImpl() 
DocumentViewerImpl::Release() 
nsCOMPtr_base::assign_with_AddRef() 
nsDocShell::Destroy() 
nsWebShell::Destroy() 
nsXULWindow::Destroy() 
nsWebShellWindow::Destroy() 
nsWebShellWindow::Close() 
nsAppShellService::~nsAppShellService() 
nsAppShellService::Release() 
nsXPCWrappedNative::~nsXPCWrappedNative() 
nsXPCWrappedNative::Release() 
nsXPCWrappedNative::JSObjectFinalized() 
WrappedNative_Finalize() 
js_FinalizeObject() 
js_GC() 
js_ForceGC() 
js_DestroyContext() 
JS_DestroyContext() 
mozJSComponentLoader::~mozJSComponentLoader() 
mozJSComponentLoader::Release() 
nsSupportsHashtable::ReleaseElement() 
_hashEnumerate__FP11PLHashEntryiPv() 
libplds4.so + 0x1410 (0x4015d410) 
nsHashtable::Enumerate() 
nsSupportsHashtable::~nsSupportsHashtable() 
nsComponentManagerImpl::Shutdown() 
NS_ShutdownXPCOM() 
main() 
libc.so.6 + 0x181eb (0x402451eb) 

Comment 21

18 years ago
marking nsbeta2- as decided by mail triage.
Whiteboard: [nsbeta2+] → [nsbeta2-]

Comment 22

18 years ago
mark nsbeta3.
Keywords: nsbeta3
Target Milestone: M17 → M18
(Reporter)

Comment 23

18 years ago
possible beta 2 release note item
Keywords: relnote2

Updated

18 years ago
Keywords: mail2

Comment 24

18 years ago
+ per mail triage
Whiteboard: [nsbeta2-] → [nsbeta3+][nsbeta2-]

Comment 25

18 years ago
to PDT: P1 because of data loss.  It looks rather silly for the user to exit the 
application and then we prompt them to save their compose window's contents as a 
draft, only to crash and lose their contents.

Comment 26

18 years ago
PDT agrees P1
(Assignee)

Comment 27

18 years ago
There is no data loss here although it crashes. I believe that I checked in 
fixes to make sure we did save the draft. Laurel could you verify that we did 
save the draft? Thanks. As far as my test went, I did successfully save the 
draft.
Status: REOPENED → ASSIGNED
(Reporter)

Comment 28

18 years ago
I'm not seeing this crash using sep6 commercial build linux rh6.0. My draft is
indeed being saved.  I'm seeing the mail window stay open until I choose Save
Draft, which is unlike the effects when I originally saw the bug.

I'll leave this for Peter to confirm.
(Assignee)

Comment 29

18 years ago
Sorry, Laurel I thought you are the QA contact person. Peter, do you still see 
the crash? Thanks,

Comment 30

18 years ago
Putting [pdtp1] in whiteboard
Whiteboard: [nsbeta3+][nsbeta2-] → [nsbeta3+][nsbeta2-][pdtp1
(Assignee)

Comment 31

18 years ago
Win32 and Linux are working fine with me. I am marking this bug as fixed. All 
work as expected.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 32

18 years ago
Reopen the bug.. Wrong resolution.. 
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 33

18 years ago
Should be WORKSFORME...
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → WORKSFORME

Comment 34

18 years ago
Verified as worksforme using Linux commercial seammonkey build 2000-091906-m18.

It does not crash using described scenario.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.