Closed Bug 1453735 Opened 5 years ago Closed 4 years ago

Firefox has hundreds of IPC shared memory files open (as file descriptors, not memory mappings)

Categories

(Core :: IPC, defect, P3)

59 Branch
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: germano.massullo, Unassigned)

References

Details

Attachments

(4 files)

Attached file lsof. against Firefox
User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180327091359

Steps to reproduce:

OS: Fedora 27
Firefox 59.0.2

While investigating on bugreports concerning graphical artifacts
https://bugzilla.mozilla.org/show_bug.cgi?id=1421353
https://bugs.freedesktop.org/show_bug.cgi?id=104216
I found out that Firefox opens hundreds of /dev/shm/org.chromium.* files
that is one of the causes that lead the system to exceed max ulimit -n

See attachment
So here's something interesting: normally, I don't see Firefox having *any* IPC shared memory files open as actual file descriptors.  ipc::Shmem maps the file in both processes (it's assocated with an IPDL actor) and then closes the file, and mappings don't count against RLIMIT_NOFILE.  (The ipc::Shmem object itself is “sent” to control which process is allowed to access the memory region, using mprotect or similar to trap data races.)  Note that lsof lists memory mappings as well; they can be distinguished by the lack of a number in the "FD" column.

However, the CrossProcess{Mutex,Semaphore} classes appear to leave the file open, and other code that uses SharedMemoryBasic (or base::SharedMemory) directly might also.  I can cause a few fds to appear by flipping the pref layers.progressive-paint (I don't actually know what that does; I found it by code inspection), but the attachment shows hundreds of fds.

Maybe there's some other graphics feature doing this?  And maybe it's a simple matter of putting a SharedMemoryBasic::Close(false) in the right place to not use so many fds?

Something that might help debug this: "stat -L /proc/PID/fd/FD" (where PID and FD are numbers) will print info about the actual file, even if it's unlinked.  If the size is something like 40 or 48, that's probably CrossProcessSemaphore or CrossProcessMutex; if it's larger, it's probably something else.

Cc'ing :jesup, who's also mentioned encountering problems with the 1k fd limit.
Summary: Firefox opens hundres of /dev/shm/org.chromium.* files → Firefox has hundreds of IPC shared memory files open (as file descriptors)
Attached file lsof _p and stat _L
(In reply to Jed Davis [:jld] (⏰UTC-6) from comment #1)
> Something that might help debug this: "stat -L /proc/PID/fd/FD" (where PID
> and FD are numbers)

See new attachment :-)
Not that I ought to be looking at work on the weekend, but: those are probably semaphores (glibc sem_t on 64-bit has size 32 & alignment 8; CrossProcessSemaphore adds an int32_t refcount; 36 aligned up to 8 is 40).  And they should be cleaning up their file descriptors courtesy of bug 1416726[1][2] — the only user of CrossProcessSemaphore known to searchfox is the TextureClient locking — but somehow that's not working.

(Also, I just noticed the sizes were already in the lsof output under the SIZE/OFF column; sorry about that.)

[1] https://searchfox.org/mozilla-central/rev/fca4426325624fecbd493c31389721513fc49fef/gfx/layers/client/TextureClient.cpp#1759
[2] https://searchfox.org/mozilla-central/rev/fca4426325624fecbd493c31389721513fc49fef/ipc/glue/CrossProcessSemaphore_posix.cpp#79
See Also: → 1416726, 1401776
Couldn't reproduce it. I'll set this bug to "IPC" component.
Component: Untriaged → IPC
Product: Firefox → Core
If you need me to run any kind of tests, please let me know
Germano, are you still seeing this?
Flags: needinfo?(germano.massullo)
Flags: needinfo?(germano.massullo)
(In reply to Jim Mathies [:jimm] from comment #9)
> Germano, are you still seeing this?

Well, consider that actually the amount of tabs I am using if a lot less than in past.
Anyway I runned again the lsof -p and stat -L and attached them here
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Priority: -- → P3
Resolution: --- → WORKSFORME
I didn't see evidence of fd leaks in attachment 9016966 [details].
Attached file nov_2018.txt
Today I started experiencing GUI glitches, so I immediately have taken some infos by running

# lsof -p 18193 && lsof -p 8916 && lsof -p 8212 && lsof -p 8074 && lsof -p 7994 && lsof -p 7873 
# stat -L /proc/18193/fd/* && stat -L /proc/8916/fd/* && stat -L /proc/8212/fd/* && stat -L /proc/8074/fd/* && stat -L /proc/7994/fd/* && stat -L /proc/7873/fd/*

$ ulimit
returns "unlimited"

Could you please check if everything is okay? In any case what should I check in order to do that on myself next time, so I don't have to ask you everytime?
Thank you for your time
You need to log in before you can comment on or make changes to this bug.