ring buffer overflows -> cDevice::Detach() blockiert...

  • device.c.5.diff ist doch keine Lösung dafür.


    Denn die Ursache ist:
    AttachReceiver() hält den mutexReceiver und stoppt nach AddPid() am cCamSlot-mutex.
    In cCiAdapter::Action() wird der cCamSlot-mutex gehalten, und Detach() stoppt am mutexReceiver.
    => deadlock


    Um das zu lösen, muss man tiefer im VDR-Code drin sein, als ich es bin.
    Möglicherweise muss die ganze mutexReceiver Sache noch mal von Grund auf neu überdacht werden.


    So lange bleibt es bei device.c.4.diff.

  • jrie


    Danke für Deine Mühen.


    Regards
    fnu

    HowTo: APT pinning

  • Jo, jedenfalls danke. Mit der v4 konnte ich bei mir keinen Absturz mehr feststellen. Vorher war das bei wildem Rumgezäppe und gleichzeitigem Aufnehmen Stand der Dinge, dass die Mühle sich verabschiedet hat.

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von iNOB ()

  • ...


    Um das zu lösen, muss man tiefer im VDR-Code drin sein, als ich es bin.
    Möglicherweise muss die ganze mutexReceiver Sache noch mal von Grund auf neu überdacht werden.


    Wenn doch jetzt die Situation von @jfie genau analisiert ist, könnte sich denn da nicht mal der ursprüngliche Author der Sache annehmen? Von wem stammt dieser Code? Bei mir sorgt das fast täglich für einen Hänger da ich praktisch nur die verschlüsselten CH Sender schaue.


    Gruss, Xcoder

    VDR 1: Zotac ZBOX EN860, 16GB RAM, 2 TB HDD, Debian Stretch, vdr-2.2.0, softhddevice, permashift, minisatip

    VDR 2: Reelbox AVG I (stable)

  • Bis Klaus mal dazu kommt, ist deine einzige Option, die Plugins mit Receivern wegzulassen, also osdteletext, permashift etc.
    Ich bin auch viel auf diesen Sendern, und bei mir knallt es praktisch nie.

  • Seit welcher VDR-Version besteht denn etwa das Problem?


    Bzw. andersherum gefragt:
    Ich bin momentan noch auch 2.0.7, benutze osdteletext und habe keine Probleme.
    Besteht die Gefahr, dass mich das mach einem Update auf 2.2.x erwischt?

    Gruss
    SHF


  • Also bei mir ist das in den paar Tagen seit Umstellung des einen Geräts von VDR 2.2.0 auf VDR 2.3.4 nicht mehr aufgetreten.


    Gruß
    Frank

    HowTo: APT pinning

  • Hi, after a few weeks I have had the same lock about 3 times.

    I still believe it is related to the above.


    A little investigation:


    Thread one:

    cTransfer::~cTransfer transfer.c:22 = cReceiver::Detach();

    cReceiver::Detach receiver.c:128 = device->Detach(this);

    cDevice::Detach device.c:1822 = camSlot->Assign(NULL); locking cCamslot &mutex !!!!

    cCamSlot::Assign ci.c:2162 = assignedDevice->Detach(caPidReceiver)

    cDevice::Detach device.c:1807 = Lock()

    Thus waiting for device lock


    Thread two:

    cDevice::Action device.c:1678 = Receiver->Receive(b, TS_SIZE);

    This is holding the device lock during "Distribute the packet to all attached receivers:"

    cCaPidReceiver::Receive ci.c:217 = AddEmmPid(EmmPid);

    cReceiver::AddPid receiver.c:49 = device->AddPid(Pid);

    cDevice::AddPid device.c:598 = camSlot->SetPid(Pid, true);

    waiting for cCamslot mutex


    Greetings Rene

  • Hi Rene,


    sorry it's been a while ;-).

    Please take a look at the attached patch.

    I believe the Lock()/Unlock() in cDevice::AttachReceiver() and cDevice::Detach() is superfluous, because the receiver[] list is already protected by mutexReceiver, which is held in both cases. Consequently we need to hold mutexReceiver in cDevice::Action() now, too, but this seems only natural, because now every access to receiver[] is protected only by mutexReceiver, and we totally avoid the deadlock in waiting for the device lock.


    Klaus

  • The lock on mutexReceiver was apparently held too long in cDevice::Detach().

    The attached patch (which replaces the previous one) now seems to work.


    The question now is, whether it also fixes the initial problem reported in this thread...


    Klaus

  • The question now is, whether it also fixes the initial problem reported in this thread...

    I will check asap. With the osdteletex-plugin the deadlock appeared rather reliable.


    BTW, very nice that this bug is treated now.


    Gruss, Xcoder

    VDR 1: Zotac ZBOX EN860, 16GB RAM, 2 TB HDD, Debian Stretch, vdr-2.2.0, softhddevice, permashift, minisatip

    VDR 2: Reelbox AVG I (stable)

  • I expirienced the following Issue with the applied patch vdr-2.3.8-fixdevicedetachlock-2.diff:


    During a recording is running:


    New vnsi clients are not able to get the channel list from vnsiserver the first entry is recived then it waits.

    Existings clients a not able to switch channels it waits for a stream.



    The recording keeps running, the programmed end time is not respected anymore.

    VDR needs to get restarted.


    After removing this patch anything is working as it should.


    Gruß RHS


    My system is vdr-2.3.8 with satip live dvbapi and vnsiserver plugins.

  • Beitrag von rofafor ()

    Dieser Beitrag wurde vom Autor gelöscht ().
  • I have a second Problem with the vdr-2.3.8-fixdevicedetachlock-2 Patch. If I use the patch, the streamdev client on a Rapberry PI can not switch the channel.

    A VDR streamdev client of the same sources on a x86 PC don't has this issue.

    MLD 5.1 mit vdr 2.2 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM -
    WD Green 6TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.3 mit vdr 2.3.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.1 mit vdr 2.2 - Banana Pi - softhddevice
    MLD 5.0 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT
    MLD 2.0 mit vdr 1.6 - SMT-7020s - 80GB HDD