Open mspanc opened 8 years ago
Does the server hang or the client? I which case, there is also the question which client (name + exact version), since this could also be a bug in the client, where a failure returned by the respective API call is not handled correctly.
For sure that happens for the client. If I try to call e.g. jack_lsp it does nothing and hangs until I do ctrl+c instead of returning immediately with an error.
Probably it also affects daemon, I have found out that some of existing clients that have connected before hitting the limit behave strange, for example they weren't responding for DBus messages (they are based on GLib/GStreamer) but I haven't found a pattern.
Anyway, my issue is with the client. Even if daemon is overloaded I expect client to gracefully handle such case.
What do you mean by name + version? I have mentioned exact commit number in the previous comment.
The version of the client application. But jack_lsp is a good example.
I just read through jack,_lsp it seems to to the right thing, so most likely a bug in the Server.
Can you provide backtraces of the running Server and the hanging Clients? That could help a bit.
Sure, I'll do this after the weekend.
I have compiled jack with patches that increase SHM registry size so it may be unrelated, but this is the most recent case I got with hanged jack_lsp:
jack_lsp backtrace: https://gist.github.com/mspanc/c143c74c9b34839c7ab16fcb8f10aea2 jackd backtrace: https://gist.github.com/mspanc/d338318ffa1079601fb19529e4cda979 jackd log is attached jackd.log.zip
Did jack_lsp trigger the "shm registry full" error in this case?
Can't easy say, the server is doing a lot of stuff, 100+ JACK clients are being spawned/killed all the time. Rather one of previous clients did this.
I am using JACKD with the same version as shipped with Ubuntu 16.04 (1ed50c9).
If clients hits "shm registry full" error, it is not gracefully disconnected, but it hangs instead.