SSDPServerController.OnExpirationTimerElapsed: Cannot acquire synchronization lock. Maybe a deadlock | Page 3

Discussion in 'Older releases' started by MrTechno, January 5, 2014.

  1. mm1352000
    • Team MediaPortal

    mm1352000 Development Group

    Joined:
    September 1, 2008
    Messages:
    21,518
    Likes Received:
    4,730
    Ratings:
    +8,196 / 17
    Home Country:
    New Zealand New Zealand
  2. Google AdSense Guest Advertisement



    to hide all adverts.
  3. MrTechno
    • Team MediaPortal

    MrTechno Development Group

    Joined:
    February 27, 2011
    Messages:
    1,256
    Likes Received:
    275
    Gender:
    Male
    Location:
    London
    Ratings:
    +515 / 1
    Home Country:
    United Kingdom United Kingdom
    Show System Specs
    Adding IP filtering to MP2 server reduced the lock ups but they still happened on my machine. I haven't found the root cause, I just disabled VPN.
     
    • Thank You! Thank You! x 1
  4. mm1352000
    • Team MediaPortal

    mm1352000 Development Group

    Joined:
    September 1, 2008
    Messages:
    21,518
    Likes Received:
    4,730
    Ratings:
    +8,196 / 17
    Home Country:
    New Zealand New Zealand
    Well hmmm...

    The logs in the other thread seem to only show the message after TVE attempts to call SSDPClientController.Close(), whereas the logs in this thread seem to show the message while MP2 Server should be running and the SSDP controller still active. In short: I suspect the existence of two distinct causes or scenarios. TVE's Close() issue is probably much easier to resolve.

    Looking at the Close() function:
    https://github.com/MediaPortal/Medi...tructure/CP/SSDP/SSDPClientController.cs#L350

    ...it seems odd to me is that _isActive = false and the socket = null loop aren't all within the same lock. Surely an atomic/locked shutdown would be cleaner/better? The assumption seems to be that if Close() acquires the lock and is able to set _isActive false then the Receive() handling will "die" without any major problem and we should be okay to close the sockets... but I'm not so sure about that assumption.

    Looking at the Receive() functions:
    https://github.com/MediaPortal/Medi...tructure/CP/SSDP/SSDPClientController.cs#L111
    https://github.com/MediaPortal/Medi...tructure/CP/SSDP/SSDPClientController.cs#L149

    Obviously they only acquire the lock for checking _isActive and then release it immediately. Crucially: there is no locking around the socket access that happens later (eg. socket.EndReceiveFrom()).

    Consider the following sequence with two threads.
    1. Thread A: Receive() invoked, lock acquired, _isActive is true so processing will continue. Lock released.
    2. Thread B: Close() invoked, lock acquired, _isActive is set false. Lock released.
    3. Thread A: The if (socket == null) check is passed before Thread B sets the shared socket reference to null. Local socket reference acquired (so Thread B setting socket to null will not have immediate effect).
    4. Thread B: Lock acquired, local socket reference acquired, shared socket reference set null. Lock released.
    5. Thread A: EndReceiveFrom() invoked on local socket reference.
    6. Thread B: Close() invoked on local socket reference either directly or within NetworkHelper.DisposeSSDPMulticastSocket().

    What happens?
    I don't know for sure, but it might not be good.
    If EndReceiveFrom() unblocks on Close() and an exception is thrown in Thread A everything would be fine I think (the exception would be caught and Receive() would return).
    However, if Close() waits for EndReceiveFrom() to receive and return but EndReceiveFrom() never does actually receive or time out... that could be our lovely deadlock. Close() blocks TVE forever.

    It interests me to see that there is an optional timeout parameter on socket.Close() which we currently do not use. ;)

    I suspect there could potentially be other issues lurking in the Receive() processing too, simply due to the fact that _isActive is only checked at the start of Receive() and not anywhere within the processing (and Close() does not close atomically within the lock).

    Plausible?
    Garbage?
    :)
     
  5. breese
    • Team MediaPortal

    breese Retired Team Member

    Joined:
    July 11, 2011
    Messages:
    3,903
    Likes Received:
    325
    Gender:
    Male
    Occupation:
    Sr. Systems Engineer
    Location:
    Arlington Heights, Illinois
    Ratings:
    +768 / 0
    Home Country:
    United States of America United States of America
    Show System Specs
    I have too as seeing one thread is MP1 and another thread is MP2, is there common code (outside of TVE) that might produce this issue?
     
  6. mm1352000
    • Team MediaPortal

    mm1352000 Development Group

    Joined:
    September 1, 2008
    Messages:
    21,518
    Likes Received:
    4,730
    Ratings:
    +8,196 / 17
    Home Country:
    New Zealand New Zealand
    Not if you exclude TVE. The issue is in MP2's UPnP library (which is used for TVE CableCARD tuner support) - that much is very clear. With TVE, even if you don't have a CableCARD tuner, the SSDP/UPnP detector is always used so there is always the potential for problems.
     
  7. mm1352000
    • Team MediaPortal

    mm1352000 Development Group

    Joined:
    September 1, 2008
    Messages:
    21,518
    Likes Received:
    4,730
    Ratings:
    +8,196 / 17
    Home Country:
    New Zealand New Zealand
    • Like Like x 1
    • Informative Informative x 1
  8. pnyberg

    pnyberg Portal Pro

    Joined:
    August 21, 2006
    Messages:
    405
    Likes Received:
    18
    Occupation:
    IT professional
    Location:
    Stockholm
    Ratings:
    +19 / 0
    Home Country:
    Sweden Sweden
    Show System Specs
    Hello,

    I have this with the latest MP2 Summer 2015 release of MP2 server as well. But only when closing/stopping the server.
    Everything works okay until, stopping the server, eventually it will stop - but is this known error?

    Attaching log.
     
Loading...

Users Viewing Thread (Users: 0, Guests: 0)

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice
  • About The Project

    The vision of the MediaPortal project is to create a free open source media centre application, which supports all advanced media centre functions, and is accessible to all Windows users.

    In reaching this goal we are working every day to make sure our software is one of the best.

             

  • Support MediaPortal!

    The team works very hard to make sure the community is running the best HTPC-software. We give away MediaPortal for free but hosting and software is not for us.

    Care to support our work with a few bucks? We'd really appreciate it!