Closed Bug 23442 Opened 25 years ago Closed 25 years ago

[DOGFOOD] Empty trash of Inbox on Cyrus IMAP account causes crash

Categories

(MailNews Core :: Backend, defect, P3)

Product:
MailNews Core
Component:
Backend
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: rzach, Assigned: jefft)

Details

(Whiteboard: [PDT+])

Attachments

(1 file)

Fix in hand. Ready for review and check in.
1.36 KB, patch
Details | Diff | Splinter Review 
One of my IMAP account produces this behavior:

1. Select account in account pane
2. File | Empty Trash

Result: Trash not emptied.  Console outputs:

imap://rzach@uclink4.berkeley.edu
GetSelectTrashUri
0
JavaScript Error: TypeError: result has no properties
URL: chrome://messenger/content/commandglue.js
LineNo: 505

On another account I get this, after just selecting the account:

imap://zach@mail.math.berkeley.edu
GetSelectTrashUri
1
imap://zach@mail.math.berkeley.edu/Trash
found trash folder
JavaScript Error: TypeError: result has no properties
URL: chrome://messenger/content/commandglue.js
LineNo: 505

Once a folder on the first account is opened, a subsequent
File | Empty Trash causes a crash.  This happens regardless of
Empty Trash is called when the folder is open, or--after selecting
a folder on a different account--only the account in the
account pane is selected.  Stack trace:

in showthreads
imap://rzach@uclink4.berkeley.edu/INBOX
GetSelectTrashUri
0

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1994]

Program received signal SIGSEGV, Segmentation fault.
0x41072422 in NSGetModule ()
(gdb) where
#0  0x41072422 in NSGetModule ()
#1  0x40ee4cd8 in NSGetModule ()
#2  0x40d26da6 in NSGetModule ()
#3  0x40ed5cf0 in NSGetModule ()
#4  0x40ed6811 in NSGetModule ()
#5  0x400fd555 in XPTC_InvokeByIndex ()
#6  0x4059f716 in NSGetModule ()
#7  0x405a07a0 in NSGetModule ()
#8  0x4005f6c8 in js_Invoke ()
#9  0x400656ca in js_Interpret ()
#10 0x4005f71d in js_Invoke ()
#11 0x400656ca in js_Interpret ()
#12 0x4005f71d in js_Invoke ()
#13 0x4005f8e8 in js_InternalCall ()
#14 0x400482cd in JS_CallFunctionValue ()
#15 0x4033e7ae in nsJSContext::CallEventHandler ()
#16 0x4036b80f in nsJSEventListener::HandleEvent ()
#17 0x40a74aff in NSGetModule ()
#18 0x40a75dae in NSGetModule ()
#19 0x40d40240 in NSGetModule ()
#20 0x40bed916 in NSGetModule ()
#21 0x40beb0d7 in NSGetModule ()
#22 0x40aa8ae2 in NSGetModule ()
---Type <return> to continue, or q <return> to quit---
#23 0x408fb524 in NSGetModule ()
#24 0x408fb4d0 in NSGetModule ()
#25 0x4090436a in NSGetModule ()
#26 0x408fa01d in NSGetModule ()
#27 0x41237c8a in nsWidget::DispatchEvent ()
#28 0x41237bb5 in nsWidget::DispatchWindowEvent ()
#29 0x41237d10 in nsWidget::DispatchMouseEvent ()
#30 0x41238901 in nsWidget::OnButtonReleaseSignal ()
#31 0x4123b7ec in nsWindow::HandleGDKEvent ()
#32 0x4122e65a in handle_gdk_event ()
#33 0x407b95cb in gdk_event_dispatch ()
#34 0x407e7be6 in g_main_dispatch ()
#35 0x407e81a1 in g_main_iterate ()
#36 0x407e8341 in g_main_run ()
#37 0x4070d859 in gtk_main ()
#38 0x41226c7a in nsAppShell::Run ()
#39 0x411e9692 in nsAppShellService::Run ()
#40 0x804a585 in JS_PushArguments ()
#41 0x804a8f4 in JS_PushArguments ()
#42 0x40210cb3 in __libc_start_main (main=0x804a718 <JS_PushArguments+5156>,
    argc=1, argv=0xbffff884, init=0x8049064 <_init>, fini=0x804bce0 <_fini>,
    rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffff87c)
    at ../sysdeps/generic/libc-start.c:78

The second account behaves as expected after a folder
is opened: Empty Trash works there.  Note that the
IMAP account where it doesn't work outputs "0" in the
console, the one where it works "1".

imap://zach@mail.math.berkeley.edu
GetSelectTrashUri
1
imap://zach@mail.math.berkeley.edu/Trash
found trash folder
Document: Done (1.253 secs)
QA Contact: lchiang → huang
Summary: Empty trash on IMAP account causes crash → [DOGFOOD] Empty trash on IMAP account causes crash
Assignee: phil → jefft
Reassign to jefft
Status: NEW → ASSIGNED
Target Milestone: M13
Looks like we have JavaScript error in commandglue.js.

JavaScript Error: TypeError: result has no properties
URL: chrome://messenger/content/commandglue.js
LineNo: 505
Whiteboard: [PDT+]
Crashing is bad.

    
  
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED

    
    

    
  
Fix checked in. commandglue.js modified.

    
  
Status: RESOLVED → VERIFIED

    
    

    
  
Verified on WinNT 2000-01-13-15-M13 & Linux 2000-01-11-10-M13
commercial build:

There is no crash for emptying trash anymore. Marking as verified!!
Whiteboard: [PDT+] → [PDT+] Verified

    
  
Status: VERIFIED → REOPENED

    
    

    
  
I'm still getting this, but only on the account where the Trash folder is a
subfolder of the Inbox folder.  It works fine on an account where both Inbox and
Trash are side-to-side.  I filed bug 23588 regarding Mozilla not finding the
Trash folder if it's hidden inside the Inbox, and maybe fixing that bug will fix
this.  It still crashes, however, and the stack trace is the same.

Linux build 2000.01.14.13

In OnFolderLoaded for imap://rzach@uclink4.berkeley.edu/INBOX/Trash
No next message
imap://rzach@uclink4.berkeley.edu/INBOX/Trash
GetSelectTrashUri
0

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1388]

Program received signal SIGSEGV, Segmentation fault.
0x41086032 in NSGetModule ()

    
    

    
  
I know that today's build is not good & I used the 01-11-10-M13 latest better
Linux commercial build for verifying this bug. But I will check above problem
again....

    
    

    
  
Note that in my original bug report I observed the same crash behavior.  While
on both accounts I got the JavaScript error on the console, only the first one
(where the Trash folder is a subfolder of Inbox) crashed, while the second
(where it's not) didn't.  It had not occurred to me that the location of the
Trash folder would make the difference until I noticed that in the first case
deleting a message also didn't work.  Filed that as bug 23588.

    
    

    
  
What kind of the IMAP server are you using...
I know that the Netscape Messaging IMAP server won't allow to create any
subfolders under Inbox.

    
    

    
  
No. 1 (Trash a subfolder of Inbox)
uclink4.berkeley.edu Execmail IMAP4rev1 (2.1.3/199909291709)
No. 2
yuban-c.math.berkeley.edu IMAP4rev1 v12.254 server

    
    

    
  
Thanks. Sounds like you are using UW IMAP.

    
  
Summary: [DOGFOOD] Empty trash on IMAP account causes crash → [DOGFOOD] Empty trash of Inbox on UW IMAP account causes crash

    
    

    
  
Adding Inbox & UW on the summary for narrowing down this problem!!

    
  
Resolution: FIXED → ---
Target Milestone: M13 → M14

    
    

    
  
M14 ... only on UW server

    
    

    
  
I cannot reproduce this problem by using our internal UW IMAP4rel v12.250, 
either.
I also tried 4.7 -- still not allow me to create subfolder under Inbox.
zach is using 12.254 UW IMAP and ours UW IMAP is 12.250.
Any differences between these UW IMAP servers?
Cc: David & Scott.
Whiteboard: [PDT+] Verified → [PDT+]

    
    

    
  
Cc:jgmyers -- John, can you provide more info for us? Thanks.

    
    

    
  
Zach, do you think your servers have test accounts that we could use to test 
with? Thanks much. Meanwhile, I'll try to download one from UW and run it on my 
linux box.

    
    

    
  
Execmail is a Cyrus derivative, not a UW derivative.
The Cyrus server normally puts all user mailboxes underneath INBOX.


    
    

    
  
Thanks. John -- I asked the right person!!
Jeff, Sorry, I should point to zach's comments: No. 1 server!!
Updating the summary for changing to Cyrus.
And it's reproducible for using Cyrus IMAP server. Talkback is available.
Summary: [DOGFOOD] Empty trash of Inbox on UW IMAP account causes crash → [DOGFOOD] Empty trash of Inbox on Cyrus IMAP account causes crash

    
    

    
  
Talkback ID#4192199:

Execution Time
191 milliseconds

    
    

    
  
Karen, which Cyrus server I can use? Thanks,

    
    

    
  
server name: buggy.mcom.com
user name: test01~test10 (please do not use test06 since I am using test06)
I will e-mail password to you.

    
    

    
  
Jeff, ignore the talkback report....actually the stack trace is empty even I got 
the talkback ID.

    
    

    
  
This is fixed along fixing bug 23447. We are no longer crashing. However, we
need to have a plan to handle default Trash folder created for Cyrus server. I
am marking this as fixed. Karen or zach please log another bug regarding default
folders for Cyrus server.

Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED

    
    

    
  
I'm still crashing with today's build, but not on POP Empty Trash (bug 23447)
since 01/12.  If this should have worked today, then please reopen this bug, or
tell me what I might be doing wrong.

    
    

    
  
Today's build should fix the crash problem. 1-20-2000's build doesn't contain 
the fix I check in. Thanks,

    
    

    
  
Jeff, Fix still in M13 build or will in M14 build?

    
    

    
  
M13, I think. I checked in the code yesterday. So, it should be M13.

    
    

    
  
No crash on 2000.01.21.08 Linux build.  However, the Trash is not emptied, I
assume this is because Mozilla doesnt know that the Trash folder on Cyrus is
/INBOX.Trash and not /Trash.  Bug 24667 is the default folders on Cyrus issue
now.  Mark verified.
Status: RESOLVED → VERIFIED

    
    

    
  
Used Linux 2000-01-21-08-M13 commercial build ob Cyrus IMAP server:
Jeff, I used today's commercial build -- After empty Trash of the Inbox, nothing 
happened....even no crash this time, but the messages of Trash folder still 
there!!

    
    

    
  
Yes, there is a bug which is address by zach's bug 24667.
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: