Open hoffie opened 3 years ago
Yes, I am planning to continue the investigation. I'll look at SetRecordingDir first, as it relates to my active PR. The thread ones appear to be related to the multithreading. Could you repeat the test without -T?
$ valgrind --leak-check=full ./Jamulus -s -n -p 10001 -e localhost:10000 -l /tmp/log -R /tmp/recordings -o 'Private Server;Stockholm;205' -m /tmp/jam.dat -u 40 -T -w 'Welcome!' $ for x in {1..12}; do Jamulus -c localhost:10001 --nogui --inifile /tmp/x &; done # leave running for some minutes # Ctrl+C and wait for exit (takes a rather long time, possibly due to valgrind overhead + recording finishing?)
I think it would be better to kill the clients first, then leave a significant time for things to settle before terminating the server. If the server is killed with active sessions, we might get false positives, reporting memory that would have been freed on disconnect.
I think the one in SetRecordingDir()
might be a case in point.
I think it would be better to kill the clients first
I think I did, will make sure in my next test tomorrow.
Could you repeat the test without -T?
Will do.
Independent of valgrind I have run a test with 33 clients and no recording/-T. Memory was stable over hours. When adding multithreading there was a sudden increase after some seconds/minutes, but it then seemed stable. I think some more thorough tests should be done, but it would not be high on my list. I will do the repeated valgrind tests though.
Is this still in progress?
I did not get around to working on it recently. I still think this should be analyzed properly. Keeping it open, but moving it to Backlog for that reason. Feel free to take over.
Ok.
I have some memory logging on my Jamulus processes and below are three of them from last week. I thought it was a correlation between memory allocation and users. The first one is an open server and the two others are private servers but the config is the same. Something is not ok but I have a hard time to figure out what. I'm running 3.7.0 on the first one and 3.7.0dev-664fd9ed on the other two.
Tagging as 3.11.0 just to look at it again.
We'll need to validate for each target, too, if we're going to clean up fully. Maybe break it down per target for actual investigation, as it might need different people working on it - make it easier to target fixes coming into different future releases.
@ann0see are you okay to assign yourself to this?
No. I'm not confident enough with the topic.
OK, maybe we could drop it from 3.11.0 unless someone can pick it up -- it's not something I'd be comfortable with, either.
Describe the bug
Even after #1073, valgrind shows some possible leaks. These should be investigated.
Note: I'm not entirely sure if they are real or relevant leaks. I suppose there may be some ressources which are not destroyed explicitly when Jamlus shuts down. This would be not relevant in the real world, but would probably still be shown as a possible leak by valgrind.
So, I'm not saying that all of the outputs are worth fixing, I'm just proposing to investigate their validity and relevance.
To Reproduce
Expected behavior No leaks.
Screenshots
Operating system
Version of Jamulus
3.6.2dev-a26ff711 (= #1073)
@softins Are you already planning to look further into this? I can try my luck, but you seem way more proficient in tracking such things down. :)