Closed Bug 97497 Opened 23 years ago Closed 23 years ago

Trunk, M094 & N620 crash [@ MSVCRT.DLL - nsUInt32Array::RemoveAt]

Categories

(MailNews Core :: Networking: IMAP, defect)

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

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.5

People

(Reporter: jay, Assigned: mscott)

References

Details

(Keywords: crash, dataloss, topcrash, Whiteboard: [PDT+])

Crash Data

Attachments

(6 files, 2 obsolete files)

new very safe fix
691 bytes, patch
naving
: review+
Bienvenu
: superreview+
Details | Diff | Splinter Review
TB36570338
448 bytes, text/plain
Details
IMAP log of "crash when compacting IMAP Inbox folder after deleted marked as deleted msgs"
141.12 KB, text/plain
Details
Last few lines of my IMAP log
17.61 KB, text/plain
Details
Attach the Server Settings Info
44.52 KB, image/gif
Details
possible fix....backs out one line from a checkin back in end of July
855 bytes, patch
naving
: review+
sspitzer
: superreview+
Details | Diff | Splinter Review 
MozillaTrunk Talkback data shows quite a few of these crashes.  A couple of
entries mention working with IMAP mail.  Here are a few incidents and the most
recent report with stack signature:

MSVCRT.DLL + 0x11186 (0x78011186) cac63334
	 line 
	Build: 2001082706 CrashDate: 2001-08-28 UptimeMinutes: 1417  Total: 1417 
	OS: Windows NT  5.0 build 2195
	 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=34642483
StackTrace: http://climate/reports/singleincidentinfo.cfm?dynamicBBID=34642483
(34642483)
URL: http://whirlpool.net.au
(34642483)
Comments: Compact IMAP folder.

MSVCRT.DLL + 0x11186 (0x78011186) cac63334
	 line 
	Build: 2001082706 CrashDate: 2001-08-27 UptimeMinutes: 27  Total: 27 
	OS: Windows NT  5.0 build 2195
	 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=34595460
StackTrace: http://climate/reports/singleincidentinfo.cfm?dynamicBBID=34595460
(34595460)
Comments: I couldn't access the sent folder  so I closed the mail window and it
crashed.

MSVCRT.DLL + 0x11186 (0x78011186) cac63334
	 line 
	Build: 2001082209 CrashDate: 2001-08-27 UptimeMinutes: 500  Total: 5295 
	OS: Windows NT  5.0 build 2195
	 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=34593403
StackTrace: http://climate/reports/singleincidentinfo.cfm?dynamicBBID=34593403
(34593403)
URL: http://whirlpool.net.au

MSVCRT.DLL + 0x11186 (0x78011186) e23416e8
	 line 
	Build: 2001082209 CrashDate: 2001-08-27 UptimeMinutes: 4794  Total: 4794 
	OS: Windows NT  5.0 build 2195
	 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=34571631
StackTrace: http://climate/reports/singleincidentinfo.cfm?dynamicBBID=34571631
(34571631)
URL: http://whirlpool.net.au
(34571631)
Comments: Compacting IMAP mailbox

MSVCRT.DLL + 0x11186 (0x78011186) cac63334
	 line 
	Build: 2001082309 CrashDate: 2001-08-24 UptimeMinutes: 396  Total: 402 
	OS: Windows NT  5.0 build 2195
	 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=34482191
StackTrace: http://climate/reports/singleincidentinfo.cfm?dynamicBBID=34482191
(34482191)
Comments: I just closed all of my Mozilla windows and it died.

MSVCRT.DLL + 0x11186 (0x78011186) cac63334
	 line 
	Build: 2001082111 CrashDate: 2001-08-24 UptimeMinutes: 1269  Total: 1269 
	OS: Windows NT  5.0 build 2195
	 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=34455681
StackTrace: http://climate/reports/singleincidentinfo.cfm?dynamicBBID=34455681

MSVCRT.DLL + 0x11186 (0x78011186) cac63334
	 line 
	Build: 2001082306 CrashDate: 2001-08-23 UptimeMinutes: 264  Total: 264 
	OS: Windows NT  5.0 build 2195
	 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=34431211
StackTrace: http://climate/reports/singleincidentinfo.cfm?dynamicBBID=34431211

The above entries were all for Windows 2000...I also found one crash on Windows
NT 4.0:

MSVCRT.dll + 0x11186 (0x78011186) 8829822a
	 line 
	Build: 2001082015 CrashDate: 2001-08-24 UptimeMinutes: 4014  Total: 5584 
	OS: Windows NT  4.0 build 1381
	 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=34491799
StackTrace: http://climate/reports/singleincidentinfo.cfm?dynamicBBID=34491799

Here's the most recent crash with stacktrace:

Incident ID 34642483
Stack Signature MSVCRT.DLL + 0x11186 (0x78011186) cac63334
Bug ID
Trigger Time 2001-08-28 14:05:17
Email Address
User Comments Compact IMAP folder.
Build ID 2001082706
Product ID MozillaTrunk
Platform ID Win32
Trigger Reason Access violation
Stack Trace
MSVCRT.DLL + 0x11186 (0x78011186)
nsUInt32Array::RemoveAt
[d:\builds\seamonkey\mozilla\mailnews\base\util\nsUInt32Array.cpp, line 247]
nsImapFlagAndUidState::ExpungeByIndex
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapFlagAndUidState.cpp, line 166]
nsImapServerResponseParser::numeric_mailbox_data
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapServerResponseParser.cpp,
line 960]
nsImapServerResponseParser::response_data
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapServerResponseParser.cpp,
line 689]
nsImapServerResponseParser::ParseIMAPServerResponse
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapServerResponseParser.cpp,
line 218]
nsImapProtocol::ParseIMAPandCheckForNewMail
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 1214]
nsImapProtocol::Expunge
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 4309]
nsImapProtocol::ProcessSelectedStateURL
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 1890]
nsImapProtocol::ProcessCurrentURL
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 1124]
Adding crash, topcrash keywords and [@ MSVCRT.DLL + 0x11186 -
nsUInt32Array::RemoveAt] to summary for tracking.
Keywords: crash, topcrash
*** Bug 97452 has been marked as a duplicate of this bug. ***
Nominating nsBranch since users shouldn't get the crashes when compacting IMAP 
folder.....
Keywords: nsbranch
From bug 97452, there is crash from Local Folder Compact folder too.....Ccing 
Sheela.
We need to contact some of these people from talkback reports, in order to 
reproduce this bug. 
Bug 97452 was reported against a Linux build, BTW.  It's been marked a dup of
this one; should OS be changed to All?

This hits me about one time in twenty on Linux, but I'm unable to provide
Talkbacks as it currently won't initialize in RedHat 7.1.  I haven't seen the
bug with IMAP:5 tracing turned on (for tracking another issue); if I can give
any other help finding it in the meantime, please let me know how.
If you search for stack signature in climate you get a blank page. Does 
anyone have a clue ?
Navin:  You can't query for "MSVCRT.DLL + 0x11186" because the query page
doesn't like the spaces.  Try querying for just MSVCRT.DLL and look for the
offset "0x11186" in the results.  Or just go to:
http://warp/u/talkback/reports/Trunk/offset/
and click on the msvcrt.dll link in the left menu...that should show you all the
crashes sorted by offset...this crash is the second one in the list.
I can reproduce this on Linux when compacting IMAP folders. It's really annoying
- it hits me about once or twice a day. Now talkback is back in nightlies, I'll
attach the ID when I hit it again. Unless it was fixed by bug 97246.

Gerv
On duped bug 97260, bernard@digitalobjects.co.nz reports this caused all his
data to be lost in inbox on his Linux box. His comments in that bug follow.

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3+) Gecko/20010827
BuildID:    20010827
Inbox started comapcting and then mozilla closed itself without any warnings.
All emails in inbox disappeared #!%^!....:-(
Reproducible: Didn't try
Keywords: dataloss
*** Bug 99365 has been marked as a duplicate of this bug. ***
triaging.
Keywords: nsbranch → nsbranch+
Target Milestone: --- → mozilla0.9.5
Blocks: 99230
This hits me 10-20 times a day, with increased frequency in recent builds.  Even
though I have Talkback installed and active, Mozilla crashes immediately without
activating it or printing any error messages to stdout or stderr.  The folder is
compacted by the IMAP server (seen at next startup and verified with Pine).

I'm willing to provide debug information, if someone wants to give instructions
on exactly what environment variables or logs to enable.
Peter which operating system are you using ?
Linux--Red Hat 7.1, kernel 2.4.3-12, all updated RPMs installed.  This is the
same system I was using in the report on 08/30, although I've since disabled the
IMAP logging.
Is it just random. I mean are you noticing any particular action that causes 
this - like deleting some particular messages and then compacting. 
I always compact after deleting messages (which is why it's hitting me *so* many
times), but the simple act of compacting doesn't always kill the app.  It's more
or less random--I thought at one point it was after messages had been filtered
to a local folder, but have determined that's not the only case.  I don't
receive much HTML mail, so it's not triggered by that, but otherwise I haven't
been able to determine any kind of pattern.

My IMAP server is UW IMAP 2000c running on the same host as the app.
In similar situations, the GUI occasionally freezes, with the app using little
to no CPU.  If I then click on a message, I get a crash.  This happened just
after the last report.
I recognise some of those crash reports (the ones where I forgot to delete the
whirlpool URL).

I can provide a few more hints on reproducing it. I can pretty much guarantee
that I'll get that crash if I leave the mail client running over night and the
first thing I do in the morning is run the compact folders action. Even if I
spend some time actually doing other things in the mail client, it will still
crash once I do get around to compacting the folders. Dashed annoying.

My IMAP server is:

ii  cyrus-imapd    1.5.19-8.1     CMU Cyrus mail system (IMAP support)

I could probably get debug information from the server side if someone knew the
right incantations to get that information out of Cyrus.
I've seen this with the 9/13 build.  I'm idle with biff and the biff going off
seems to be the entry into the crash.
*** Bug 100254 has been marked as a duplicate of this bug. ***
I'm still trying to trigger this on my machine so I can see what's going on.
Looking at the stack trace it doesn't look like a null ptr check kind of fix. So
I really need to reproduce this in order to see what's going on.
I've been trying (unsucessfully) to come up with a solid way of reproducing it.
 I get behaviour similar to that of Dan Everton (2001-09-17 03:09).  I just
thought I should note that I have also been seeing bug 94738, and if I remember
correctly, in close proximity to the crashes from this bug.  However, I can't
reproduce 94738 with any reliability either.  I've also see 94738 and then
compacted with no problems.  

I think the long term relationship between the client and the server may be the
problem.  If I use mail actively after just loading it up, I don't seem to see
either bug.

Sorry, no Talkback data since the RPM build I have does not have Talkback and I
can't seem to install it via XPI (Redhat 7.1, Linux 2.4.3, Fully patched).
This is also a topcrasher with Mozilla 0.9.4 so adding M094 to summary. 
Talkback is reporting this crash under the MSVCRT.DLL stack signature with the
following offsets:  
0x1240c (Windows 98  4.10 build 67766446)
0x11186 (Windows NT  5.0 build 2195 or Win2K)
0x110f4 (Windows NT 4.0 build 1381) and others.  

The stack hasn't changed much at all, and most of the user comments still talk
about compacting imap mailboxes.  Here is a recent incident and some user
comments that might help us reproduce this:

Incident ID 35616028
Stack Signature MSVCRT.DLL + 0x11186 (0x78011186) cac63334
Bug ID
Trigger Time 2001-09-19 16:14:17
Email Address gene@nttmcl.com
User Comments Compacting an IMAP folder, not huge but fairly small (with <20
messages) this time.
Build ID 2001091311
Product ID Netscape6.20
Platform ID Win32
Trigger Reason Access violation
Stack Trace
MSVCRT.DLL + 0x11186 (0x78011186)
nsUInt32Array::RemoveAt
[d:\builds\seamonkey\mozilla\mailnews\base\util\nsUInt32Array.cpp, line 247]
nsImapFlagAndUidState::ExpungeByIndex
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapFlagAndUidState.cpp, line 166]
nsImapServerResponseParser::numeric_mailbox_data
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapServerResponseParser.cpp,
line 960]
nsImapServerResponseParser::response_data
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapServerResponseParser.cpp,
line 689]
nsImapServerResponseParser::ParseIMAPServerResponse
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapServerResponseParser.cpp,
line 218]
nsImapProtocol::ParseIMAPandCheckForNewMail
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 1214]
nsImapProtocol::Expunge
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 4309]
nsImapProtocol::ProcessSelectedStateURL
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 1890]
nsImapProtocol::ProcessCurrentURL
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 1124] 


MSVCRT.DLL + 0x11186:

Incident 35482763 - Stacktrace:
http://climate/reports/stackcommentemail.cfm?dynamicBBID=35482763
    Comments: i was on a imap server changing to an other directory then ...
Incident 35615719 - Stacktrace:
http://climate/reports/stackcommentemail.cfm?dynamicBBID=35615719
    Comments: Compacting a huge IMAP folder
Incident 35616087 - Stacktrace:
http://climate/reports/stackcommentemail.cfm?dynamicBBID=35616087
    Comments: Compacting a mid-sized IMAP folder.

MSVCRT.dll + 0x110f4:
Incident 35486861 - Stacktrace:
http://climate/reports/stackcommentemail.cfm?dynamicBBID=35486861
    Comments: I just hit the compact mail folder menu item.
Incident 35547247 - Stacktrace:
http://climate/reports/stackcommentemail.cfm?dynamicBBID=35547247
    Comments: I selected compact mail folders. I happened to be doing a truss of
the imap process at the time and saw the server finish doing the expunge.
Mozilla crashed when it was removing its local copy of the 707 emails I had just
deleted from the folder.
    Comments: Funny because earlier I deleted 2690 emails from another folder
and it coped OK. Hope this extra info helps.
MSVCRT.dll + 0x10752:

Incident 35403366 - Stacktrace:
http://climate/reports/stackcommentemail.cfm?dynamicBBID=35403366
    Email: selmer@netscape.com
    Comments: I did something in mail it was either switch folders click on a
message or iconify the window. Can't remember what it was I wasn't really paying
close attention when I did it.
Summary: Trunk crash [@ MSVCRT.DLL + 0x11186 - nsUInt32Array::RemoveAt] → Trunk & M094 crash [@ MSVCRT.DLL - nsUInt32Array::RemoveAt]
adding PDT to status whiteboard
Whiteboard: PDT
Whiteboard: PDT → [PDT]
No known ETA because I still haven't been able to trigger this crash on my
machine. Code inspection around the crash site doesn't show any null ptr checks
that are missing so the cause is something more severe. than a null ptr.
Whiteboard: [PDT] → [PDT] [ETA: ??]
minusing for now. Still trying to reproduce and will continue to try.
Keywords: nsbranch+ → nsbranch-
Target Milestone: mozilla0.9.5 → mozilla0.9.6
I just experienced this crash again.  I had deleted a few messages from an imap
folder...I went to the Trash folder and tried to empty it...and boom!  

I think chofmann has been seeing this crash too.  His most recent crash has a
different stack trace, but a few of his older crashes are the same as the one
reported here.

chofmann's most recent crash:
Incident ID 36018351
Stack Signature KERNEL32.DLL + 0xa217 (0xbff7a217) 71c036e9
Bug ID
Trigger Time 2001-09-28 14:26:16
Email Address chofmann@netscape.com
User Comments compacting mail
Build ID 2001092705
Product ID Netscape6.20
Platform ID Win32
Trigger Reason Access violation
Stack Trace
KERNEL32.DLL + 0xa217 (0xbff7a217)
KERNEL32.DLL + 0xb2ca (0xbff7b2ca)
MSVCRT.DLL + 0x1436 (0x78001436)
PR_Free [../../../../pr/src/malloc/prmem.c, line 84]
nsMemoryImpl::Free [d:\builds\seamonkey\mozilla\xpcom\base\nsMemoryImpl.cpp,
line 328]
nsMemory::Free [d:\builds\seamonkey\mozilla\xpcom\base\nsMemoryImpl.cpp, line 560]
imgContainer::FillWithColor
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgContainer.cpp, line 663]
imgContainer::DoComposite
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgContainer.cpp, line 515]
imgContainer::Notify
[d:\builds\seamonkey\mozilla\modules\libpr0n\src\imgContainer.cpp, line 439]
nsTimer::Fire [d:\builds\seamonkey\mozilla\widget\timer\src\windows\nsTimer.cpp,
line 200]
FireTimeout [d:\builds\seamonkey\mozilla\widget\timer\src\windows\nsTimer.cpp,
line 78]
KERNEL32.DLL + 0x2317 (0xbff72317)
FireTimeout [d:\builds\seamonkey\mozilla\widget\timer\src\windows\nsTimer.cpp,
line 51]
USER32.DLL + 0x3bb5 (0xbff53bb5)
0x30010003
0x5faaac9a 

And an older chofmann crash:

Incident ID 35629344
Stack Signature MSVCRT.DLL + 0x10752 (0x78010752) 6d538e8d
Bug ID
Trigger Time 2001-09-19 23:22:52
Email Address chofmann@netscape.com
User Comments compacting imap mail folder
Build ID 2001091814
Product ID Netscape6.20
Platform ID Win32
Trigger Reason Access violation
Stack Trace
MSVCRT.DLL + 0x10752 (0x78010752)
nsUInt32Array::RemoveAt
[d:\builds\seamonkey\mozilla\mailnews\base\util\nsUInt32Array.cpp, line 247]
nsImapFlagAndUidState::ExpungeByIndex
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapFlagAndUidState.cpp, line 166]
nsImapServerResponseParser::numeric_mailbox_data
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapServerResponseParser.cpp,
line 960]
nsImapServerResponseParser::response_data
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapServerResponseParser.cpp,
line 689]
nsImapServerResponseParser::ParseIMAPServerResponse
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapServerResponseParser.cpp,
line 218]
nsImapProtocol::ParseIMAPandCheckForNewMail
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 1214]
nsImapProtocol::Expunge
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 4309]
nsImapProtocol::ProcessSelectedStateURL
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 1890]
nsImapProtocol::ProcessCurrentURL
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 1124] 

Unbelievably, I just hit this today.  I had one browser window open, and the
mail window.  I have biff set to go off every ten minutes.  I was working on the
Mac for an hour, and after a while (45 minutes or so), I crashed while doing
nothing on my Win32 box.  I was doing lots of bugmail work on the Mac, so biff
was getting a workout on the Win32 box.
plussing again. Clearly this is still happening to people then. If anyone can
reliably reproduce it, I'm dying to know how =).
Keywords: nsbranch- → nsbranch+
Target Milestone: mozilla0.9.6 → mozilla0.9.5
Attached patch wild ass guess..... (obsolete) — — Splinter Review 

    
  

        Attachment #51638 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        extra bullet proofing (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
I added some harmless bullet proofing in the hopes that this somehow prevents us
from hitting the crash. Still can't figure out what's causing it nor can I
reproduce it. 

The bullet proofing does the following:
1) makes sure m_pData (an allocated buffer) is not null
2) make sure the size of the allocated buffer is greater than 0
3) Don't store the subtraction of two unsigned 32 bit integers in a signed int,
instead check to make sure the sum of the two unsigned 32 bit integers is less
than the total size of the buffer. 

    
    

    
  
Comment on attachment 51639 [details] [diff] [review]
extra bullet proofing

r=naving. I also tried
to reproduce without any
sucess.

        Attachment #51639 -
        Flags: review+

    
    

    
  
My guess is that the problem is we're trying to remove at a negative index,
which we're treating as a very large positive number. Your fix might handle
that, but I would just try using the debugger to simulate that, and see if your
fix does indeed fix it.

    
    

    
  
User Comments ok, was able to do it again... compacting large mail folder

Incident ID 36142060
Stack Signature MSVCRT.DLL + 0x10752 (0x78010752) 6d538e8d
Bug ID
Trigger Time 2001-10-01 18:21:47
Email Address chofmann@netscape.com

Build ID 2001092705
Product ID Netscape6.20
Platform ID Win32
Trigger Reason Access violation
Stack Trace
MSVCRT.DLL + 0x10752 (0x78010752)
nsUInt32Array::RemoveAt
[d:\builds\seamonkey\mozilla\mailnews\base\util\nsUInt32Array.cpp, line 247]
nsImapFlagAndUidState::ExpungeByIndex
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapFlagAndUidState.cpp, line 166]
nsImapServerResponseParser::numeric_mailbox_data
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapServerResponseParser.cpp,
line 960]
nsImapServerResponseParser::response_data
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapServerResponseParser.cpp,
line 689]
nsImapServerResponseParser::ParseIMAPServerResponse
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapServerResponseParser.cpp,
line 218]
nsImapProtocol::ParseIMAPandCheckForNewMail
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 1214]
nsImapProtocol::Expunge
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 4309]
nsImapProtocol::ProcessSelectedStateURL
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 1890]
nsImapProtocol::ProcessCurrentURL
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 1124] 

    
  

        Attachment #51639 -
        Attachment is obsolete: true

    
    

    
  


  

    
    

    
  
Comment on attachment 51726 [details] [diff] [review]
new very safe fix

we're going to just check for any negative index.

        Attachment #51726 -
        Flags: superreview+

    
    

    
  
Our supsicion is that numeric_mailbox_data is probably extracting an index value
of -1  (or some other negative number) from the server response. So a low risk
fix is to just bail out in nsImapFlagAndUidState::ExpungeByIndex if the signed
version of the index is less than 0.

Here's the fix:
  if ((PRInt32) msgIndex < 0)
    return NS_ERROR_INVALID_ARG;

I'll take it to PDT today.
Status: NEW → ASSIGNED
Whiteboard: [PDT] [ETA: ??] → [PDT] [ETA: 10/02]

    
  

        Attachment #51726 -
        Flags: review+

    
    

    
  
this piece of bullet proofing is now in the trunk.

    
    

    
  
adding dependency bug.
Blocks: 99508
No longer blocks: 99230

    
    

    
  
pls check it in - PDT+
Whiteboard: [PDT] [ETA: 10/02] → [PDT+] [ETA: 10/02]

    
    

    
  
bullet proofing is now in on the branch and trunk. 

Let's monitor the talk back reports in the next day or two and see if these stop
showing up. 
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

    
    

    
  
Verified no crash for above described scenarios:
1) Compact IMAP folders
2) Access IMAP Sent folder
3) Close all Mozilla windows

Windows build 10-10-05-0.9.4. Verified.
Status: RESOLVED → VERIFIED

    
    

    
  
I think I'm still seeing this with a branch build from yesterday. I'm having
trouble submitting talkback.

Gerv

    
    

    
  
I think I've just hit this, and finally got a Talkback window to go with it. 
TB36570338Y, from Linux -sea build 2001100808.

    
    

    
  
Which build are you using? I cannot reproduce this crash on Linux either for 
10-10-04-0.9.4 for IMAP mark as delet mode w/compacting folder.....

    
    

    
  
Linux nightly 2001100808; I can't duplicate it at will, and especially not with
Talkback, but it hits me regularly.  System details are above in my comment from
09-13.  Similar behaviour was reported recently in bug 101592, which may in fact
be a dup.

Bug 97452, my original report on this issue, was marked as a dup of this one, BTW.

    
    

    
  
I'm using the branch build from late last night now. The crash is not 100%
reproducible - it normally happens a few hours in, and not on the first compact.
But it always happens eventually. It's very rare that my Mozilla crashes for any
other reason.

Gerv

    
    

    
  
I cannot reproduce this problem as following:
1) On my WinNT platform
2) On my Linux 6.1 & other co-workers' Linux 7.1 systems
3) On NMS 4.15 IMAP mark as delete mode
4) On other IMAP server: UW IMAP/mark as delete mode
4) On IMAP Inbox & other imap folders

I need to get more info for reproducing this problem:
1) What IMAP server are you using?
2) Can I know your server setting info?
3) How many msgs are you tring to deleting and compacting.
4) Compacting from Inbox or other IMAP folder/subfolder?
5) What have you done prior compacting IMAP folders?
6) What the percentage for getting this crash?


    
    

    
  
Server: UW IMAP, from Red Hat 7.1 RPM imap-2000c-10.

Config: One host has a default configuration, one has user mail folders stored
in a different path (/local/userpath instead of /home/user).  Crashes happen on
both.

Message deletion: This varies.  Sometimes I'll be compacting one message,
sometimes many.

Compact location: Most often in INBOX, because I'm there 90% of the time, but
has crashed similarly in other folders as well.

Prior actions: Varies.  Sometimes I have filtered messages to other IMAP folders
or local folders, but this is not a necessary condition for the crash to occur.
 Often I'll use the browser between compactions, other times I'll just be
reading messages.

Percentage: Depends on the day.  I've had occasions where the crash happens once
every five times and others where I've gone a day without crashing.

I've never been able to discern a pattern to the crashes, other than they happen
when compacting an IMAP folder and rarely trigger Talkback.  The first incident
I can find in my .talkback directory is TB35287558X (only TBs for the current
build show up in the talkback executable, for some reason, but it stores all of
the reports).

    
    

    
  
Here are all of the talkbacks I have locally that mention "compact".  In some
occurrences Talkback appeared after restarting Mozilla.

TB35287558X
TB35822849H
TB35867449X
TB35876510Q
TB35918925Q
TB36570338Y


    
    

    
  
Looks like the crash are mostly from MozillaTrunk builds. Can you try on the 
latest Branch 0.9.4 build to see whether this is reproducible?

    
    

    
  
I'm seeing it on the 0.9.5 branch. Mozilla is currently not doing anything with
the 0.9.4 branch, so the people who are still seeing this bug, at any rate,
don't have an interest in finding out whether it occurs there or not ;-)

I need to get more info for reproducing this problem:
> 1) What IMAP server are you using?
judge.mcom.com :-)

> 2) Can I know your server setting info?
Which ones do you want?

> 3) How many msgs are you tring to deleting and compacting.
It varies. Normally quite a few.

> 4) Compacting from Inbox or other IMAP folder/subfolder?
I think I've only ever seen it in Inbox, but I hardly ever compact anywhere
else, so that may not be significant.

> 5) What have you done prior compacting IMAP folders?
Used Mozilla for several hours. Immediately prior - presumably dragging some
messages into folders.

> 6) What the percentage for getting this crash?
About 5%, I would say. One time in twenty, but it doesn't seem to happen until
you've been running for a while.

Gerv

    
    

    
  
I've reproduced it in branch builds, but have never been able to get Talkback
reports from them--Mozilla crashes without triggering Talkback, as described
above.  The 6 TB reports listed are all I've been able to get in the six weeks
since I reported bug 97452.

    
    

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

    
    

    
  
Dup'd here again from 97452.  Here's a new Talkback, if there's anyone still out
there that doubts it's happening: TB36739973E.

    
    

    
  
-1 does not crash in the debugger. reopening, something else causes this crash.


Status: VERIFIED → REOPENED
Resolution: FIXED → ---

    
    

    
  
Yes. I finally got the crash by using today's branch build.....but it seems it 
is more easier to reproduce it today. I tried many time last Friday for 
different systems, couldn't reproduce compacting folder crash, but I can 
reproduce this crash when I tried the 3rd time for deleting msgs and compacting 
folder....I cannot get the talkback report, but I notice there was crash bug 
104835 for deleting many msgs...is the crash from deleting msgs, or from 
compacting folder?

    
    

    
  
Compacting the folder.  I can delete as many messages as I want from any folder
with no problem, but the browser crashes more often than not as soon as I select
|File/Compact Folders|.

    
    

    
  
File | Compact Folders compacts local folders, doesn't it, Navin? I.e., not imap
folders at all.

    
    

    
  
can we verifiy that this is fixed on the 094 branch?
Whiteboard: [PDT+] [ETA: 10/02] → [PDT+] [ETA: 10/02] [Fix checked in to 094 branch]

    
    

    
  
I got the crash from compacting IMAP Inbox folder after deleted many msgs from 
IMAP mark as deleted mode. I am using 10-15-05-0.9.4 branch build

    
    

    
  
David, the behaviour I see is that File|Compact Folders compacts the current
folder (only) if you're in an IMAP account, and all local folders if you're in a
local folder "account".  It does nothing to IMAP if you're in local, and nothing
to local if you're in IMAP.  (I don't have any POP3 accounts configured, so I
can't say what the behaviour is there.)

    
    

    
  
If you have: "When I delete a message [mark it as deleted]" set, then Compact
Folders removes all the messages with a red X beside them in the current folder.

Performing this operation is the cause of this crash.

Gerv

    
    

    
  
File | Compact folders compacts the current folder if it is imap, if it is local
/pop3 it compacts all folders under that accout. 

    
    

    
  
This is still on the branch, even.
Incident ID 36876205
Stack Signature MSVCRT.DLL + 0x11186 (0x78011186) cac63334
Bug ID
Trigger Time 2001-10-18 12:52:58
Email Address stephend@netscape.com
URL Visited
User Comments Crash, was idle on this machine for a while, then came back and
tried to close the window. Boom, baby boom!
Build ID 2001101718
Product ID Netscape6.20
Platform ID Win32
Trigger Reason Access violation
Stack Trace
MSVCRT.DLL + 0x11186 (0x78011186)
nsUInt32Array::RemoveAt
[d:\builds\seamonkey\mozilla\mailnews\base\util\nsUInt32Array.cpp, line 247]
nsImapFlagAndUidState::ExpungeByIndex
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapFlagAndUidState.cpp, line 170]
nsImapServerResponseParser::numeric_mailbox_data
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapServerResponseParser.cpp,
line 960]
nsImapServerResponseParser::response_data
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapServerResponseParser.cpp,
line 689]
nsImapServerResponseParser::ParseIMAPServerResponse
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapServerResponseParser.cpp,
line 218]
nsImapProtocol::ParseIMAPandCheckForNewMail
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 1214]
nsImapProtocol::Expunge
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 4309]
nsImapProtocol::ProcessSelectedStateURL
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 1890]
nsImapProtocol::ProcessCurrentURL
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 1124] 

    
    

    
  
For those who can reproduce this with regularity can you please post or send me
an imap log of a session which ends in a crash?

directions are here:
http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

    
    

    
  
You got there before me :-) I'm still trying to crash it.

Gerv

    
    

    
  
I hit this today just too on a recent N6.2 candidate...  just before I came into
work.

Incident ID 36867522
Stack Signature MSVCRT.DLL + 0x10752 (0x78010752) 6d538e8d
Bug ID
Trigger Time 2001-10-18 09:35:08
Email Address chofmann@netscape.com
URL Visited
User Comments not doing anything. had mail and browser windows up.
Build ID 2001101205
Product ID Netscape6.20
Platform ID Win32
Trigger Reason Access violation
Stack Trace
MSVCRT.DLL + 0x10752 (0x78010752)
nsUInt32Array::RemoveAt
[d:\builds\seamonkey\mozilla\mailnews\base\util\nsUInt32Array.cpp, line 247]
nsImapFlagAndUidState::ExpungeByIndex
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapFlagAndUidState.cpp, line 170]
nsImapServerResponseParser::numeric_mailbox_data
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapServerResponseParser.cpp,
line 960]
nsImapServerResponseParser::response_data
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapServerResponseParser.cpp,
line 689]
nsImapServerResponseParser::ParseIMAPServerResponse
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapServerResponseParser.cpp,
line 218]
nsImapProtocol::ParseIMAPandCheckForNewMail
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 1214]
nsImapProtocol::Expunge
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 4309]
nsImapProtocol::ProcessSelectedStateURL
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 1890]
nsImapProtocol::ProcessCurrentURL
[d:\builds\seamonkey\mozilla\mailnews\imap\src\nsImapProtocol.cpp, line 1124] 

    
    

    
  
Above crash scenarios is:
1)Use IMAP mark as deleted mode
-------------------------------------------------------------------
2)Send to this IMAP acocunt 20 new msgs
3)Use Shift key for selecting to delete those 1st to 20th new msgs
4)Compacting Inbox folder
-------------------------------------------------------------------
5)Repeat 3 times from step 2 to step 4, nothing happens, no crash.
6)Repeat again from step 2 to step 4, crash occurs. 
(Crash occurs for the fouth times deleting msgs and compacting Inbox folder on 
the SAME system)...Hope this help.



    
    

    
  
I've attached the end of my IMAP log. The full log is 12Mb, and also includes
multiple instances of the "Waah! Can't copy to sent-mail folder" thing which is
my other big mail-news dogfood problem. If anyone wants a copy, let me know.

The two logs look basically the same to me...

Gerv
OS: Windows 2000 → All
Hardware: PC → All
Whiteboard: [PDT+] [ETA: 10/02] [Fix checked in to 094 branch] → [PDT+]

    
    

    
  
I still can't reproduce this under the debugger to figure out what's going on. I
just ended up deleting and compacting 3000 messages in chunks of a hundred or so
at a time. I was using the mark as delete model. Deleting 100 messages then
compacting then repeating. 

Still trying. 

    
    

    
  
I got the crash again, but this time is the fifth time, after you 
repeating as above I described....eventually, you will get the crash.....
I will attach the server settings screen shot here.


    
    

    
  
I still haven't been able to reproduce the crash. However, looking over old
checkins, I found that David modified nsImapFlagAndUidState::ExpungeByIndex as
part of a fix for 40701. His comment:

"I also cleaned up a little bit of the braces style, and used an nsMsgKeyArray
method to Remove an element instead of doing it by hand"

I undid his small change to call Remove and instead put back the one line that
was doing it by hand. This worked find in 6.1/092 so it should be safe to undo
it back to that state. 

I'm going to try to get this checked into the trunk for those folks who do see
this crash so they can try a trunk build tomorrow to see if they see the crash.



Status: REOPENED → ASSIGNED

    
    

    
  
Comment on attachment 54182 [details] [diff] [review]
possible fix....backs out one line from a checkin back in end of July

r=naving

        Attachment #54182 -
        Flags: review+

    
    

    
  
Comment on attachment 54182 [details] [diff] [review]
possible fix....backs out one line from a checkin back in end of July

sr=sspitzer

        Attachment #54182 -
        Flags: superreview+

    
    

    
  
this is now in the trunk so for those of you who can reproduce the crash it'd be
great if you could bang the heck out of the build tomorrow and see if you can
still reproduce it.

    
    

    
  
Let me forward this bug report over to the seamonkey newsgroup to try to get
more folks to try this out on the trunk.

    
    

    
  
I tried two times on today's trunk build 10-18-06-trunk build by following my 
steps. The crash is still occurring on today's trunk build -- I got two times 
crashes: one time is occurring for the fifth time deleting 20 msgs & compacting 
Inbox. the otehr crash is occurring on the fourth time deleting 20 msgs & 
compacting Inbox. It seems that the talkback is trying to catch my crashes, but 
I check the reports and couldn't find the reports. It displays "In Queue" but no 
incident ID......Couldn't find the crash reprots under my email address even I 
already sumitted. :-(

    
    

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

    
    

    
  
Karen, today's the 19th not the 18th. The trunk builds haven't come out yet this
morning I don't think. =).

    
    

    
  
Yes. I just found the latest one that I got from the Windows is 18 not 19.
I am trying on Linux for 19 now, so far I tried for the first time on Linux for 
10th times deleting 20 msgs/compacting Inbox, looks fine, no crash yet :-)....I 
am trying for the second time to for sure.....sorry for the above 
comments....but at least this problem can be reproduced on yesterday's trunk 
build as well by following my steps. I will let you know the second time 
results.

    
    

    
  
Since I always can reproduce the crash on Windows platform....
To be sure the fix on trunk build -- I reproduce the same crash on Linux 
10-17-04-0.9.4 branch build(it cash too) and then verify TWO TIMES on Linux 
10-19-08-trunk build and it all pass for trunk build -> no crash for 10 times 
deleting 20 msgs and compacting Inbox :-) - Super! I will suggest this fix to 
check in to the branch since I and some peoples can reproduce this crash on both 
Windows & Linux platforms....(Also, Scott, is this fix impacting other 
regression? Please let me know if any test cases that I need to run for the 
regression....thanks for the fix! Good works!)

    
    

    
  
If you can always reproduce on Windows, then we should wait to verify on that
platform before calling it truly fixed, right?  I'll grab the trunk when it
comes out and give it a whirl.

    
    

    
  
I just had PDT approval to check this into the branch. It's now in the branch
too. Jonathan is going to spin up new builds today with this patch. This could
potentially be our new canidate build. We felt more people would be testing it
if we had it in the branch too. 

After I get some lunch I'll post some explicit testing scenarios to run through.
The code change ONLY effects imap and it is only invoked when we are expunging
messages.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED

    
    

    
  
The code involved is only invoked when we get an expunge response from the
server. This happens most often when compacting folders. 

Regression tests should include:
1) making sure deleting messages (with the trash model and with mark as deleted)
is working correctly. Is the message removed from the view? When you quit and
comeback is the message still gone?

2) Compact your folders. Delete some messages in a folder (preferrably your
inbox), compact your folders. Send yourself some more messages that are going to
end up in the folder you just deleted from. Are the right set of messages in
your folder? Anything duplicated or a deleted message still showing?

3) Empty your trash folder. Just for kicks, quit, start up in offline mode then
bring up mail. Click on your Trash folder. Is the folder empty like it should
be?   Reconnect to the server. Select the trash folder again. Is it still empty?

    
    

    
  
Adding N620 to summary for tracking, since this was also happening on the branch.
Summary: Trunk & M094 crash [@ MSVCRT.DLL - nsUInt32Array::RemoveAt] → Trunk, M094 & N620 crash [@ MSVCRT.DLL - nsUInt32Array::RemoveAt]

    
    

    
  
So far, this is pass (no crash)for the original scenarios on WinNT branch 
10-19-16-0.9.4 build. I will check the original scenarios on other platforms 
(Linux & Mac 9.1) and run more further regression testing.....

    
    

    
  
OK. I tested for the original scenarios for Linux 10-19-15-0.9.4 & Mac 9.1 
10-19-13-0.9.4 builds - no crash.
I also run some tests based on Scott & Esther's test scenarios , I found some 
problems for Mark as deleted for Copy & Move, but that's not causing from this 
bug's fix -- that probably is some other bug that I already logged (or I will 
log for next release).
Basically, for this bug - this pass for all the platforms. 
Super!! Marking as verified.
Status: RESOLVED → VERIFIED

    
    

    
  
*** Bug 94738 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
Product: Core → MailNews Core
Crash Signature: [@ MSVCRT.DLL - nsUInt32Array::RemoveAt]

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: