After 96h+ up and whole nights imaging without interruption, kstars sometimes crashes out of file descriptors. Last occurrence happened during execution of shutdown process, which could not execute. Executing script /home/tallfurryman/Documents/EkosShutdown.sh QProcessPrivate::createPipe: Cannot create pipe 0x4c676c0: Too many open files It is obviously relatively difficult to track descriptor leaks for end-users, so perhaps an instrumented run will be necessary. Or a periodic lsof, which will provide name associations.
This particular situation on the shutdown script made Ekos unable to finish the shutdown process, and state SHUTDOWN_SCRIPT never completed. Another timeout safeguard to be implemented here.
Yes we need to figure out where the leak is. Maybe from FITS Viewer?
I propose to use the OSS services of Synopsys Coverity to get a static code analysis of KStars.
Hi, I can reliably create this situation by running the 'loop' function in the guider section. The number of [socket] fd's in the kstars /proc grows continuously and never reduces after the loop is terminated by Stop. Even terminating the indi server doesn't clean up the open fd's. The image presented by the loop function is successfully updated, even after the number of fd's hits 1024, so it would seem that it isn't directly related to the loop. Or the loop is causing fd's to be opened, but not actually using them? I'm running kstars 2.7.9 with indi 1.7.4 (pulled from git repository and built on Sep 4) Equipment is laptop with Fedora 28, Meade LX90 and Zwo ASI 224C.
I can't replicate this with v3.0.0 in master. I think the fd issues in FITS viewer was fixed a while ago.
I just re-checked this as I did do a git pull to get the latest version, and it is actually 3.0.0. I mistakenly reported the kde version. During the run of the loop guide, I find this in the proc/fd: $ ls /proc/3549/fd 0 100 103 106 109 12 15 18 20 23 26 29 31 34 37 4 42 45 48 50 53 6 64 67 7 72 75 78 80 83 86 89 91 94 97 1 101 104 107 11 13 16 19 21 24 27 3 32 35 38 40 43 46 49 51 54 61 65 68 70 73 76 79 81 84 87 9 92 95 98 10 102 105 108 110 14 17 2 22 25 28 30 33 36 39 41 44 47 5 52 55 62 66 69 71 74 77 8 82 85 88 90 93 96 99 Most of them are: lrwx------. 1 ... 64 Oct 2 23:24 90 -> 'socket:[59370]' lrwx------. 1 ... 64 Oct 2 23:24 91 -> 'socket:[66537]' lrwx------. 1 ... 64 Oct 2 23:24 92 -> 'socket:[66538]' lrwx------. 1 ... 64 Oct 2 23:24 93 -> 'socket:[78162]' up to lrwx------. 1 ... 64 Oct 2 23:39 717 -> 'socket:[101062]' lrwx------. 1 ... 64 Oct 2 23:39 718 -> 'socket:[101063]' lrwx------. 1 ... 64 Oct 2 23:39 719 -> 'socket:[99119]' It seems to increase at the frame rate of the guider loop. As I can replicate this on-demand, is there something I can do to provide more info?
This is with internal guider using the simulators?
(In reply to Jasem Mutlaq from comment #7) > This is with internal guider using the simulators? No, this is using the ASI224C as the guider. I have only had it happen in the 'loop' function.
Cannot be reproduced with 3.3.4. Please reopen if you can reproduce it reliably.