You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
running flutter test on OSX results in "Too many open files, errno =24" #2976
We'd probably have to look at Blink's text code from when we forked. It's wanting to do font measurements on a Mac, which is not a platform our engine has a lot of supporting code for anymore. :/
This feels like two separate issues. One is our holding of the package:test code on Mac and trying to drive too many tests at once. The second is our broken font fallback logic on Mac, resulting in a crash.
Oh the thing you're referring to was my technical debt benchmark. It used to open every file then read them all in parallel, but I changed it to just open them sequentially. That doesn't affect this.
I actually ran into this today just doing a flutter test run on my MacBook Pro 15 today. Changing ulimit via the command above works around it.
ulimit -S -n 2048
I've always worked around this by bumping the limit up in my .zshrc/.bashrc, but it'd be nice if we tried to stick within the value on the user's machine but emit a message that provides steps to bump it up for better performance.
If it turns out that some individual tests can't run within the limit, then emitting a friendly error message would be much better than the current behaviour.
Activity
apwilson commentedon Mar 29, 2016
I also get "Flutter quit unexpectedly." halfway through ruinning fltuter test (this is on flutter's package/flutter).apwilson commentedon Mar 29, 2016
This works around the too many open files issue on my machine -
but doesn't effect the crashapwilson commentedon Mar 29, 2016
Not sure if this is helpful but this is the start of the stack trace of the thread that crashed:eseidelGoogle commentedon Mar 29, 2016
That crash point looks like font fallback is failing to find a suitable font. Presumably it didn't expect to go down that path: https://github.com/flutter/engine/blob/master/sky/engine/platform/fonts/apple/FontPlatformDataApple.cpp#L81We'd probably have to look at Blink's text code from when we forked. It's wanting to do font measurements on a Mac, which is not a platform our engine has a lot of supporting code for anymore. :/eseidelGoogle commentedon Mar 29, 2016
This feels like two separate issues. One is our holding of the package:test code on Mac and trying to drive too many tests at once.
The second is our broken font fallback logic on Mac, resulting in a crash.Hixie commentedon Oct 14, 2016
We should more gracefully handle running out of file handles.
cbracken commentedon Feb 10, 2017
@Hixie IIRC you landed a fix related to too many open files on macOS. Is this safe to close or is there still work to do.
Hixie commentedon Feb 10, 2017
I do not know to what you refer. As far as I know this is still broken.
Hixie commentedon Feb 10, 2017
Oh the thing you're referring to was my technical debt benchmark. It used to open every file then read them all in parallel, but I changed it to just open them sequentially. That doesn't affect this.
cbracken commentedon Feb 10, 2017
sgtm - leaving it open then!
14 remaining items
pedromassangocode commentedon Aug 26, 2020
I tried to reproduce following the steps in #2976 (comment) and I was unable to reproduce this issue. I run the tests on a 2016 Macbook Pro 13'.
Not sure if it is really fixed so I will leave this opened.
cbracken commentedon Aug 29, 2020
I actually ran into this today just doing a
flutter testrun on my MacBook Pro 15 today. Changingulimitvia the command above works around it.I've always worked around this by bumping the limit up in my .zshrc/.bashrc, but it'd be nice if we tried to stick within the value on the user's machine but emit a message that provides steps to bump it up for better performance.
If it turns out that some individual tests can't run within the limit, then emitting a friendly error message would be much better than the current behaviour.
theniceboy commentedon Jan 28, 2021
Can confirm this issue still exists.
ulimit -S -n 2048fixes it, but the command has to be re-ran after switching channels.hdeleoncidenet commentedon Jun 24, 2022
Still exists. The command
ulimit -S -n 2048worked for me.gatspy commentedon Apr 8, 2024
macOS 14.3.1 how resolved？