I am running Firefox 3.6.{13,14}, with a large number of open tabs, and an uptime of days or weeks at a time. Whenever I quit the application in those circumstances, the windows go away after a few seconds, but top(1) continues to show the very large firefox-bin process running (at low CPU) for a few minutes before it goes away. If I hook up strace(1) to it during that time, I see a flurry of madvise() calls. It seems to me that giving hints to the system on how certain ranges of memory will be used is a bit pointless if the application is about to exit anyway, especially if the number of madvise() calls is so large that it significantly delays program termination.

Please try reproducing with a Firefox 4 beta. The system calls themselves are not particularly interesting, and I'd guess you're probably seeing slow shutdown from Places (bookmarks/history) cleaning itself up... It was known to be slow in Firefox 3.6, and should be much better in Firefox 4.

(In reply to comment #0) > It seems to me that giving hints to the system on how certain ranges of memory > will be used is a bit pointless if the application is about to exit anyway, > especially if the number of madvise() calls is so large that it significantly > delays program termination. Which files are being madvised? You can get the memory ranges from /proc/<pid>/smaps

(In reply to comment #1) > Please try reproducing with a Firefox 4 beta. The system calls themselves are > not particularly interesting, and I'd guess you're probably seeing slow > shutdown from Places (bookmarks/history) cleaning itself up... It was known to > be slow in Firefox 3.6, and should be much better in Firefox 4. I'll give the beta a try. Please allow me some time on this, however, as I'm currently testing a bugfix between 3.6.13 and .14pre :] (There could be heavy bookkeeping going on between the syscalls, but given that the CPU usage is low, like 1 or 2%, I'm presuming that it's the syscalls that are the bottleneck.) (In reply to comment #2) > Which files are being madvised? You can get the memory ranges from > /proc/<pid>/smaps I don't have that information at the moment, but from a (partial) strace log that I started recording once the shutdown delay was evident, I can tally up the number of madvise() calls on differently-sized memory buffers as follows: (singletons not listed) 2 madvise(ADDR, 40960, MADV_DONTNEED) = 0 3 madvise(ADDR, 73728, MADV_DONTNEED) = 0 6 madvise(ADDR, 45056, MADV_DONTNEED) = 0 18 madvise(ADDR, 57344, MADV_DONTNEED) = 0 50 madvise(ADDR, 61440, MADV_DONTNEED) = 0 105 madvise(ADDR, 49152, MADV_DONTNEED) = 0 189 madvise(ADDR, 32768, MADV_DONTNEED) = 0 352 madvise(ADDR, 4096, MADV_DONTNEED) = 0 361 madvise(ADDR, 8192, MADV_DONTNEED) = 0 898 madvise(ADDR, 36864, MADV_DONTNEED) = 0 6683 madvise(ADDR, 24576, MADV_DONTNEED) = 0 16269 madvise(ADDR, 12288, MADV_DONTNEED) = 0 So most of the calls are on a buffer 12288 bytes in size, if that number seems familiar to anyone....

that sounds like jemalloc relinquishing memory. Those areas are not backed by files. This should be harmless.

12288 is 0x3000, fwiw.

I've recently started seeing this with Firefox 8.0 under the same conditions. If I close the window shortly after startup, everything works fine, but if I quit Firefox after it has been running for a few days, it just spams madvise calls. I haven't yet tested to see if it will ever stop doing this, but it has gone at least ten minutes before.

I think the root cause of this is our attempt to clean up memory/etc on shutdown...which should be a no-op. Bug 662444 will take care of this.

For the record, this loop stopped when I disabled the Readability extension. I can now close Firefox just fine.