341647 - improper handling of "too many open files" error

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect)

Description

[Alan Batie]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

I'm not sure what triggered this, but suspect it's related to my running a script yesterday to archive old mail into a parallel Archive tree of IMAP folders, thus doubling the number of them.  This morning I try to start up SeaMonkey (SeaMonkey 1.0 Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060127 SeaMonkey/1.0), it was hanging.  I ran ktrace on it, with this result at the end:

   330 seamonkey-bin CALL  geteuid
   330 seamonkey-bin RET   geteuid 501/0x1f5
   330 seamonkey-bin CALL  geteuid
   330 seamonkey-bin RET   geteuid 501/0x1f5
   330 seamonkey-bin CALL  getattrlist(0xbfff8e70,0xbfff9640,0xbfff9300,0x330,0x5)
   330 seamonkey-bin NAMI  "/.vol/234881026/258655"
   330 seamonkey-bin CALL  getattrlist(0xbfff9670,0xbfff9e40,0xbfff9b00,0x32c,0x5)
   330 seamonkey-bin NAMI  "/.vol/234881026/258655/CFMSupport"
   330 seamonkey-bin RET   getattrlist -1 errno 2 No such file or directory
   330 seamonkey-bin CALL  getattrlist(0xbfff9d70,0xbfffa240,0xbfffa200,0x2c,0x5)
   330 seamonkey-bin NAMI  "/.vol/234881026/8536"
   330 seamonkey-bin RET   getattrlist 0
   330 seamonkey-bin CALL  open(0xbfffa700,0,0x1ff)
   330 seamonkey-bin RET   open -1 errno 24 Too many open files
   330 seamonkey-bin CALL  open(0xbfffa5a0,0,0x1ff)
   330 seamonkey-bin RET   open -1 errno 24 Too many open files
   330 seamonkey-bin CALL  getattrlist(0xbfff9d70,0xbfffa240,0xbfffa200,0x2c,0x5)
   330 seamonkey-bin NAMI  "/.vol/234881026/49098"
   330 seamonkey-bin RET   getattrlist 0
   330 seamonkey-bin CALL  open(0xbfffa700,0,0x1ff)
   330 seamonkey-bin RET   open -1 errno 24 Too many open files
   330 seamonkey-bin CALL  open(0xbfffa5a0,0,0x1ff)
   330 seamonkey-bin RET   open -1 errno 24 Too many open files
   330 seamonkey-bin CALL  getattrlist(0xbfff9dc0,0xbfffa590,0xbfffa250,0x32c,0x5)
   330 seamonkey-bin NAMI  "/.vol/234881026/1416203/libwallet.dylib"
   330 seamonkey-bin RET   getattrlist 0
   330 seamonkey-bin CALL  getattrlist(0xbfff9700,0xbfff9ed0,0xbfff9b90,0x328,0x5)
   330 seamonkey-bin NAMI  "/.vol/234881026/1416333"
   330 seamonkey-bin RET   getattrlist 0
   330 seamonkey-bin CALL  getattrlist(0xbfff9a70,0xbfffa240,0xbfff9f00,0x32c,0x5)
   330 seamonkey-bin NAMI  "/.vol/234881026/1416203"
   330 seamonkey-bin RET   getattrlist 0
   330 seamonkey-bin CALL  getattrlist(0xbfff9590,0xbfff9d90,0xbfff9a20,0x358,0x5)
   330 seamonkey-bin NAMI  "/.vol/234881026/1416333"
   330 seamonkey-bin RET   getattrlist 0
   330 seamonkey-bin CALL  open(0xbfffa9d0,0,0)
   330 seamonkey-bin RET   open -1 errno 24 Too many open files
   330 seamonkey-bin CALL  lseek(0xffffffff,0,0x2)
   330 seamonkey-bin RET   lseek -1 errno 9 Bad file descriptor
   330 seamonkey-bin CALL  close(0xffffffff)
   330 seamonkey-bin RET   close -1 errno 9 Bad file descriptor
   330 seamonkey-bin CALL  __disable_threadsignal(0x1)
   330 seamonkey-bin RET   __disable_threadsignal 0


It was just sitting here doing nothing.

There are two problems here:

1.  It's apparently ignoring the fact that it is getting an error
2.  It seems OS X defaults to a ridiculously low 256 file descriptor limit.  I ran "ulimit -S -n 2048", then SeaMonkey from a command line, and it started up ok.

Reproducible: Always

Steps to Reproduce:
1.  I'm not sure, but I think creating a large number of folders (>256) will do it.
Actual Results:  
SeaMonkey hangs on startup

Expected Results:  
It should attempt to increase the file descriptor limit when it runs out, and if that fails, report the error to the user (probably have to close all the folders first to free up some descriptors?), including a description of what the user needs to do to remedy the problem, and then shutdown as gracefully as possible.  Or even better, include some way of managing the file descriptors so that files are opened as closed as needed to work within the limit.

Workaround: manually set ulimit and start up from a command line

Comment 1

[Andrew Schultz]

Not sure where this would go (NSPR?), but we'll start in XPCOM

Comment 2

[David Warren]

(In reply to comment #1)
> Not sure where this would go (NSPR?), but we'll start in XPCOM
> 
This also happens on 10.4 using Mozilla Mail. The chances of occurance increase with the number of folders you have and the length of time you leave Mozill running.
It seems that Mozilla should either close files it is not using or increase the processes max open file limit. Apple defaults this to 256, but it can be increased  to 10240 with a call to setrlimit. 

Comment 3

[Adam Guthrie]

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

Comment 4

[Tanner M. Young [:tmyoung]]

Is this still an issue in Firefox 3.5?

If it is not, we should set the resolution of the bug to WORKSFORME.

Comment 5

[Alan Batie]

I assume you mean the latest version of Seamonkey, since firefox doesn't have email ;-)

I've been using Thunderbird for some time now, and haven't run into the problem...

Comment 6

[Tanner M. Young [:tmyoung]]

Great.  I will resolve this as Worksforme, and if the issue reappears, we will reopen the bug.