Skip to main content

Deadlock occurring in RI stack when deleting a DVR recording while in playback

4 replies [Last post]
mtulini
Offline
Joined: 2012-07-24
Points: 0

Hi all,

Here is the scenario: We record a program on DVR. We play it back. While the recording is playing, we attempt to delete it. Our application (the Buckeye guide) hangs at this point. The recording continues to play in the background and never deletes.

When the user attempts to delete the recording, the application performs the following two steps asynchronously:

1) Deletes the recording
2) Tunes to the previous channel

I have attached a thread dump of the two deadlocking threads. The deleting thread holds a lock on HNRecordingManagerImpl and appears to be waiting to acquire a lock on RecordingManagerInterface. The tuning thread appears to hold a lock on RecordingManagerInterface and is waiting to acquire a lock on HNRecordingManagerImpl. I say "appears" because it is obfuscated in the thread dump, and I only ascertained this by visually inspecting the stack code.

Can somebody from CableLabs please confirm this, and if so provide guidance on how to resolve?

Thanks,

Matt

AttachmentSize
deadlockedThreads.txt2.06 KB

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
cpratt
Offline
Joined: 2008-12-18
Points: 0

Yeah, I believe this issue was fixed as part of IT/OCAP_RI-586 (http://java.net/jira/browse/OCAP_RI-586).

Your thread dump shows:

at org/cablelabs/impl/media/player/AbstractPlayer/close()V(+7)
at org/cablelabs/impl/manager/recording/RecordingImpl/deleteRecordedServiceData(Z)V(+56)
at org/cablelabs/impl/manager/recording/RecordingImpl/delete()V(+137)

The RI trunk code no longer makes the player.close() call on the caller's thread (as of change 29729 on Feb 2nd). So you need a newer version of the RI with this fix (or patch in the referenced source changes referenced in the bug).

mtulini
Offline
Joined: 2012-07-24
Points: 0

Thank you for the reply. It turns out we are still running 1.2.1 and we are going to capture this update in one of our upcoming releases.

cpratt
Offline
Joined: 2008-12-18
Points: 0

Sounds good.

The trunk changesets that you should be able to apply are 29729 and 29851.

Let us know if you have any further issues/questions.

mtulini
Offline
Joined: 2012-07-24
Points: 0

In org/cablelabs/impl/manager/recording/RecordedServiceImpl.equals(), I moved the synchronized block slightly down the code (past the first two if-statements) and the deadlock issue went away. There is some Comcast-added code below this. But this method does not modify any variables, it only reads them, so does it need to be synchronized? Is there a larger concurrency issue in the stack that needs to be addressed?