When using jemalloc, Firefox takes a very long time to start up. Looking at it with strace and lsof, it has created an unlinked temp file (/tmp/jemalloc.XXXXXX) and is writing 2GB worth of zeroes to it. When it finishes, it appears to close the file and it is deleted, freeing the disk space. This problem goes away when I run with MALLOC_OPTIONS=O. This is on Linux, Ubuntu Feisty Fawn, kernel.org kernel 126.96.36.199, 2GB RAM, 2.5GB swap. I have Tracemonkey JIT turned on for both chrome and content, if that makes a difference. This may be related to #447710, except that the file is much larger, and gone by the time the browser starts up. I'm running Firefox 3.1b2pre: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081017 Minefield/3.1b2pre
I should clarify that it closes (and so deletes) the file when it is done creating it, not when it is done running. I see nothing on my screen while the file is created, which takes 30 seconds or so, then the browser GUI comes up. lsof reports that the file is no longer open, and the disk space has been freed.
This is very similar to (maybe the same as) #461782, although if so that bug has a nonobvious name.
Errr...It turns out this bug *is* the same as #461782, as in exactly the same, as in the same bug number. I meant to say it's similar to #448840.
Are you using LinDOSFS? (Ubuntu installed onto C:?) Otherwise I think only a sparse file would be created.
Ignore the above comment, this is a jemalloc bug introduced in bug 427109 and I proposed a fix in bug 447710 comment 8
It's on a regular ext3 filesystem. You're right, it's a dup of bug 447710, I should have searched more carefully before filing it. Thanks!
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 447710
You need to log in before you can comment on or make changes to this bug.