Open awesomekling opened 10 months ago
As mentioned on discord, we apparently create a separate memfd-backed anonymous buffer for each frame of animated gifs when interacting with ImageDecoder.
With a 708 frame gif, that means we create 708 file descriptors, just for the one gif on the page. It's not surprising we hit the per-process fd limit that way.
We should refactor the way Gifs or other animated image formats are handled in ImageDecoder to not use so many dang file descriptors.
Isn't the ulimit for fds on Linux many thousands?
In a bash session on my ubuntu 22.04 machine, it's 1024
$ ulimit -n
1024
That's the soft limit though. Could setrlimit
that up by 10x as a short-term fix :)
With the merging of https://github.com/SerenityOS/serenity/pull/24025 this issue becomes a bit more pressing. The current max number of fds that can be transferred at a time is 64. This limits gifs to 64 frames. The absolute max on linux for SCM_RIGHTS fd passing is 253, according to the man pages.
To reproduce, open https://berkeleygraphics.com/typefaces/berkeley-mono/
After a short time, this error shows up:
There's a pretty huge GIF animation with 708(!) frames on the page, seems likely to be related :sweat_smile: