Closed chrisdos64 closed 6 years ago
I forgot to add some informations: vdr is 2.4.0, the plugin is the newest from git. Additionally i loaded streamdev-server, femon, svdrposd, xineliboutput, epgsearch and vompserver. All together is running on a OpenSuse Leap 15.0 in a Xen virtualized host.
One thread calls cVNSIClient::Recording with a write-lock of Timers and tries to acquire the m_msgLock
cVNSIClient::Recording does not grab m_msgLock. I already fixed this: https://github.com/FernetMenta/vdr-plugin-vnsiserver/commit/0c84792e6b73fe0f644b443c454c22f16cb5f632
Please post a backtrace and syslog that shows version of vnsiserver
Oh! It seems, i missed something... I had linked the wrong directory in my PLUGINS/src directory, so i had an older version. Now i downloaded the newest and will give it a try. Now i get a version 1.7.0, before it was 1.5.2 - shame on me!
I think the backtrace is not longer needed...
glad to hear it is resolved. can I close the issue?
It seems to be fine, but the condition was quite rare... You may close the issue. If i encounter another problem i'll open up another... ;-)
Hi! I detected a deadlock during 'normal' usage, which i try to describe below: One thread calls cVNSIClient::Recording with a write-lock of Timers and tries to acquire the m_msgLock, but the m_msgLock is held by another thread trying to get a read-lock of timers... Due to the fact, that i'm currently not need to add/delete/modify timers via vnsi, i simply disabled the appropriate commands. But this is no final solution. And i'm not quite sure, that it solves the problem completely. I wonder, what the m_msgLock should protect. If i'd know that, i think i could find a solution for the deadlock. Does it only protects some simple members, or is it also intended to protect the stream? If so, i wonder how this can work completely, because the stream is given to another thread as far as i understood the code. Best regards, Chris