citizenfx / fivem

The source code for the Cfx.re modification frameworks, such as FiveM, RedM and LibertyM, as well as FXServer.
https://cfx.re/
3.48k stars 2.06k forks source link

LOAD_RESOURCE_FILE not closing file handles #2414

Open Nimplex opened 6 months ago

Nimplex commented 6 months ago

What happened?

On the server I have a script that relies on a large number of open files, I noticed that after some time reading and writing files, the server stopped writing and reading files, many scripts began to return errors, specifically: "Listening on socket failed - libuv error EMFILE, "[ net-tcp-server] error on connection: too many open files". In the code responsible for the "SAVE_RESOURCE_FILE" and "LOAD_RESOURCE_FILE" functions, I did not notice the logic responsible for closing the file descriptor.

Expected result

Server should automatically close file descriptors when file operations end

Reproduction steps

  1. Open many file descriptors
  2. Watch FXServer slowly die

Importancy

Crash

Area(s)

FXServer

Specific version(s)

Server 7290 windows

Additional information

No response

Yum1x commented 6 months ago

Does the same occurs when using the functions provided by the ScRT and properly closing them?

local file = io.open()
--  ...
const file = fs.readFileSync()
// ...
Nimplex commented 6 months ago

I don't know, I've never tried using io.open()

tens0rfl0w commented 6 months ago

The file stream is correctly closed when the objects lifetime ends (after exiting the scope of the SAVE_/LOAD_RESOURCE_FILE native functions and removal of the streams ref).

Also, testing this with random reads and writes to over 30k(!) different resource files showed no exhausted stream I/O file descriptor limit (which sits at 512) and no increase in open file handles, so this normally works quite well.

You may have to provide a repro here.

Nimplex commented 6 months ago

I am not sure how to reproduce this error, it happens sporadically. I managed to reduce the frequency of its occurrence when I changed the logic responsible for writing logs (some even have several thousand lines in one file).

tens0rfl0w commented 6 months ago

Well, there has to be some more info, otherwise how should anyone be able to even find a direction where to look at. Are you accessing the resource files from within multiple resources, concurrent threads, ...? Any info like that could probably help.

Nimplex commented 6 months ago

I would like to correct in advance the version of the server I am using, we are using version 7290 on linux (ubuntu 22.04 minimal). It reads files from multiple resources at the same time, the error occurred when with each new chat message I read the contents of the log and saved it by adding new logs to the end of the file. Most of the write and read operations are done in new threads.