Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Too many open files #2538

Open
vincentneo opened this issue Jul 16, 2023 · 7 comments
Open

Too many open files #2538

vincentneo opened this issue Jul 16, 2023 · 7 comments

Comments

@vincentneo
Copy link
Contributor

vincentneo commented Jul 16, 2023

I left my simulator running on my Mac for a while, and came back to a SIGABRT crash as well as this final console message:
�[1;31m[ 0][t 4][1689493045.501645088][EventFdBsd.cpp:44][#1][!ConnectionCreator][&err == -1] [PosixError : Too many open files : 24 : socketpair failed]�[0m

Judging from it, I guess it has something to do with file descriptor limits imposed by the OS, which for macOS is 256. (Unsure what it is for watchOS)

No, I could not reliably replicate this, and there could be a high chance that it's my fault, but thought I would open this nonetheless, in case its a real concern.

Usage observed on watchOS, latest master + #2501 + #2517

@levlam
Copy link
Contributor

levlam commented Jul 16, 2023

This is expected after the option waitsForConnectivity is enabled. I could only cite, what I wrote to you, while we discussed addition of the option: "It should crash now if there is no connectivity for a very long time, but the user is online. If the user is offline, then I expect OS to kill the app earlier".

I also wrote, how to prevent the crash: "It would be better to implement task canceling when they aren't needed anymore. RawConnectionHttp has close() method, but it does nothing now, because the code doesn't keep track of active tasks".

@vincentneo
Copy link
Contributor Author

Ah got it! thought open files != tasks and assumed it was a separate issue.

That said, when this occured, user is both online and with stable connectivity.

@levlam
Copy link
Contributor

levlam commented Jul 16, 2023

This is a real issue for watchOS devices, so it can be kept opened.

@levlam levlam reopened this Jul 16, 2023
@vincentneo
Copy link
Contributor Author

vincentneo commented Jul 16, 2023

By the way, I realised it always spams tons (like 1000s in span of 20 minutes) of �[1;31m[ 1][t 3][1689529388.331466197][ConnectionCreator.cpp:900][#1][!ConnectionCreator] [Error : 0 : Socket is empty]�[0m, right before the too many files crash.

In one test example I observed the Socket is empty error message, 1267 times. A look at memory graph shows 1269 instances of NSURLSessionConfiguration, which is observed to climb at roughly similar rates with the error message.

Yet, it seems if I manage to keep tdlib busy, such as if I'm requesting a bunch of stuff, the rate of which the error "socket is empty"'s appearance, appears to be lessen.

Any relation to the mentioned issue as well?

@levlam
Copy link
Contributor

levlam commented Jul 16, 2023

This is related to the crash. The line in the log is printed when a new "connection" is created. A new connection is created when the previous connection is dead. i.e. requests to the connection received no response. In this case the connection is closed and a new connection is created. But when waitsForConnectivity is set to true, the requests sent to the old connection are stuck in the waiting state instead of failing. This eventually leads to the crash because system resource are exhausted.

@vincentneo
Copy link
Contributor Author

Right, I retested it with the master branch build without any patches, and while getting 332 'socket is empty' errors in a short span of 4 minutes, there were only 34 instances of NSURLSessionConfiguration.

@vincentneo
Copy link
Contributor Author

The commit b73061f should make things slightly better. Basically each task can at max last for 90s before timeout.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants