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

OSError: [Errno 24] Too many open files #8

Open
low-pass opened this issue Apr 1, 2020 · 2 comments
Open

OSError: [Errno 24] Too many open files #8

low-pass opened this issue Apr 1, 2020 · 2 comments
Assignees

Comments

@low-pass
Copy link
Contributor

low-pass commented Apr 1, 2020

Known facts:

  • The error is generated when relatively hefty testbench (about 20-25 nested entities inside) is simulated more than 50 times in a loop
  • Initializing rtl_iofile objects in init method for some entities seems to accelerate the problem (appears sooner), removing such rtl_iofile calls will delay this problem to 500~ish loops before crash
  • Deleting the objects within testbench in the end of each loop by calling e.g. "del self.obj1" does not seem to affect the issue
@mkosunen
Copy link
Member

@low-pass : Does this problem still persists as should we try to fix it in release 1.5

@sporrasm
Copy link
Contributor

sporrasm commented Jan 5, 2022

Possibly related: We've had a similar issue in spice where parallel processes are launched to read the IOs from simulator output file. If there are more than 50 IOs in the single file, the OS throws the "Too many open files error". This was solved in commit d196a95d9 of the spice module (https://github.com/TheSystemDevelopmentKit/spice) by reading the file in chunks of 50. Also, v1.7_RC of thesdk module let's the user split running parallel tasks into smaller chunks (e.g. 10 at a time). This may help, if you are running the "hefty testbenches" with nested entities in parallel.

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

3 participants