[SOLVED] [ansible] vdr 2.4.7 Segmentation Fault beim Start mit softhddevice und aktivem skinnopacity oder skinflat

  • Hallo, zusammen.


    Habe die Tage testweise einmal einen yaVDR Ansible von Ubuntu 18.04 auf 20.04 gehievt. Hat soweit auch gut geklappt. Allerdings produziert der VDR 2.4.7 beim Start (mit aktivem vdr-plugin-skinnopacity) einen Segmentation Fault.


    Im laufenden Betrieb kann ich bspw. vom LCARS auf NOPACITY Skin ohne Problem umstellen. Deaktiviere ich vorab mit vdrctl skinnopacity startet der VDR auch einwandfrei.


    Eine leere setup.conf brachte ebenfalls keine Änderung beim Startverhalten des VDR. Hat jemand irgendwelche weiteren Ideen dazu ...?


    Hier einmal ein Auszug aus dem Log:

    Gruß,

    Holger.

  • Als Workaround kannst du das Frontend immer attached starten lassen, indem du das -D aus der /etc/vdr/conf.avail/softhddevice.conf entfernst.


    Ansonsten müsste man mal einen Backtrace produzieren und nachvollziehen, was genau da zum Crash führt.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hi, seahawk1986

    Ansonsten müsste man mal einen Backtrace produzieren und nachvollziehen, was genau da zum Crash führt.

    Ich werde mal (zeitnah) einen Backtrace erstellen und hier posten (Versuch mit vdr-dbg & nopacity-dbg):

    vdr_bt_full.txt


    Ohne genaue Ahnung zu haben, passiert der VDR Crash wohl hier:

    Code
    Thread 1 (Thread 0x7f9ee2e8e800 (LWP 6555)):
    #0  0x00007f9ee30fe18b in raise () from /lib/x86_64-linux-gnu/libc.so.6
    #1  0x00007f9ee30dd92e in abort () from /lib/x86_64-linux-gnu/libc.so.6
    #2  0x00007f9edcb769eb in ?? () from /usr/lib/libGraphicsMagick-Q16.so.3
    #3  <signal handler called>
    #4  0x00007f9edce6df60 in cNopacityDisplayChannelView::CreatePixmaps (this=0x55bfe6e90b50) at displaychannelview.c:154
    #5  0x00007f9edce5dc6c in cNopacityDisplayChannel::cNopacityDisplayChannel (this=0x55bfe6e66640, WithInfo=<optimized out>) at displaychannel.c:22
    #6  0x00007f9edce9d9d7 in cNopacity::DisplayChannel (this=<optimized out>, WithInfo=<optimized out>) at nopacity.c:32
    #7  0x000055bfe6127479 in cDisplayChannel::cDisplayChannel (this=0x55bfe6e07c10, Number=1, Switched=true) at skins.h:468
    #8  0x000055bfe60cb43a in main (argc=<optimized out>, argv=<optimized out>) at device.h:354


    P.S.: Das -Din softhddevice.conf entfernen ist ein funktionierender Workaround; der VDR 2.4.7 startet ohne Mucken mit nopacity 1.1.8.


    Danke und Gruß,

    Holger.

    4 Mal editiert, zuletzt von holger_p. ()

  • seahawk1986: Hab mal versucht, einen Backtrace zu ermitteln (s.o.)

  • lnj: Since this seems to affect multiple skins - what are the dimensions of the dummy OSD used by softhddevice?


    VDR's cPixmap (and cPixmapMemory, both defined in osd.c) do not seem to have a null-Check for the dimensions - if the PixMapBackground is created with an effective size of 0, the cPixMapMemory will call malloc(0), which will return a pointer that shall not be dereferenced, so if something accesses it's data member, things would go south...

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • If seahawk is right here, does this one change something?



    Code
    osd.c:1153
    -- data = MALLOC(tColor, this->DrawPort().Width() * this->DrawPort().Height());
    ++ data = MALLOC(tColor, max(1, this->DrawPort().Width() * this->DrawPort().Height()));


    btw. If size is 0, then malloc() returns either NULL, or a unique pointer value that can later be successfully passed to free().

  • I did tests until reproduce the problem, everything works. Try disabling the rest of the plugins, maybe some combination fails.

    vdr-2.5.5, nopacity 1.1.8, Ubuntu 20.04.

    I will continue tests.

    lnj I did a test to disable - with vdrctl - all plugins etc. but kept satip, softhddevice and skinnopacity enabled. The vdr 2.4.7 crashes during startup.

    With deactivation of the skinnopacity and using default LCARS or classic skin the startup works without any (VDR startup ) ssue.

    I furtheron installed and used vdr-plugin-skinflat with keeping skinnopacity disabled: The VDR crashes during startup using this skin as well.


    The given workaround by seahawk1986 to comment out -Din the softhddevice.conf to start the VDR with an attached frontend works as such. No crashes during startup.


    P.S. My VDR setup is an Intel setup,; no additional graphic cards etc.

    2 Mal editiert, zuletzt von holger_p. ()

  • Thats a lot of null pointer checks - is this common for output plugins to return NULL if a dummy osd is used? Or would it be nicer to provide a cPixmap Implementation with noop for all function calls?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • It was historically in softhd* plugins.

    And it may be good practice to check whether the pixmap was created or not.

    Generally crashed the Fill function, I tried make it as empty function, but without success.

    I'll think about another way.

  • I have added a commit (with a few others) in the skinnopacity Devel Branch.

    This should fix the segfault when using the softhd* detached mode.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    Einmal editiert, zuletzt von kamel5 ()

  • For me as non programmer the code looks elegant and efficient.

  • MegaV0lt , Thank you for the compliment, I do my best. :) I didn't want to check every pixmap to see if it existed.

    I also think that this problem should be fixed in the output device so that not every skin has to implement a workaround.


    Nevertheless, I made Part 2 of the fix to make it even easier to map it in all skin functions.

    See the last commit in git branch Devel.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Looks good to me. Maybe i try to adapt. Bur can not test. Also have not much time...

  • Hi,

    [...]

    I also think that this problem should be fixed in the output device so that not every skin has to implement a workaround.

    [...]

    I personally do not have any preferences if it is better to solve this situation
    a) in softhddevice or

    b) to perform the OSD checks in (any) of the skin plugins or
    c) anywhere else (i.e. in the VDR by kls as mentioned by wirbel )

    For any references I created Github issue for lnj on this first of all:

    Starting softhddevice in detached mode leads to segfault of VDR (2.4.7)


    Regards,

    Holger.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!