Error message when saving file "Exception: exportCSV() [Errno 24] Too many open files"

[bigl00z3]

I had this issue several time. I saved the error message once but couldn't find where I had save it. So the bug report is coming late.
When running many batches in a row (I would say likely >20), at one point I get an error message to save the profile:

99 18:24:02.099 Exception: exportCSV() [Errno 24] Too many open files: ''C:/Users/nbi/_2022 Roasts/S0 Error [saving.csv'@line](mailto:saving.csv'@line) 27134

another time (from the log):
02-08 12:24:50 MainThread artisanlib.main ERROR : [Errno 24] Too many open files: 'nul' Traceback (most recent call last): File "artisanlib\main.py", line 24233, in sendmessage_internal File "artisanlib\suppress_errors.py", line 26, in __init__ File "artisanlib\suppress_errors.py", line 26, in <listcomp> OSError: [Errno 24] Too many open files: 'nul'

Save an .alog is not possible exporting to .csv either. Saving as Excel seems to work.

This happened on Windows with 2.4.7 4f0b7ae
I have toried to reproduce it by repeating 53 consecutive “fake” batches. By “fake, I mean, no connected devices, just Start/Charge/Drop/Save. But I wasn't able to re create it successfully.

I haven’t been able to reproduce the issue either on Mac OS X c2ffdc9 by tested with 52 consecutive “fake” batches.

On RPi with build (old 2.4.7 continous build) I have also tested with 53 fake consecutive batches without any issues (in this test, roaster was running with connected devices, just doing Start/Charge/Drop/Save…).

Nico

[MAKOMO]

Brilliant! I guess I could finally catch this one (Commit bd1f912). To trap error messages produced by the external S7 to stdout and stderr which badly interacts in GUI apps two new fake file handles are opened to redirect those messages to /dev/null. A typo caused that those two file handles were not closed correctly in any case. A problem at least on Windows. Linux based systems seem to close those handles automatically after some time such they could not stack up. This could finally resolve this long standing and hard to reproduce issue. Thanks for this excellent report!