[softhddevice-Plugin] Segfault bei offenem OSD und einem resize des Fensters

    This happens with vdr-2.4.0 and vdr-2.4.1 and the latest clone of https://github.com/ua0lnj/vdr-plugin-softhddevice. I'm using only LCARS as Skin. And the plugins which are started are only softhddevice and satip.


    If an OSD is open and visible then resizing the VDR window multiple times, VDR crashes with a segfault. The backtrace is:

    This happens also directly after a VDR start when only the initial channel information is visible.

    Hi,

    did you check out the branch vaapi+vdpau+cuvid, if yes you can try with "export LIBVA_DRIVER_NAME=i965" in case your default is iHD and you use vaapi.

    CU

    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

    Edited once, last by 9000H ().

    Hi,


    @9000H

    i'm using the mentioned branch

    git status

    Auf Branch vdpau+vaapi+cuvid

    Ihr Branch ist auf demselben Stand wie 'origin/vdpau+vaapi+cuvid'.


    @lnj

    My development system is using a NVIDIA card with vdpau.

    The additional condition "if(ftLib)" makes it harder to get a segfault, but it still happens.
    The parameter "-w disable-ogl-osd" works absolutely as desired. No crash at all after changing the window size very often.


    In syslog if see stop messages of the oglThread after a window resize. Could this be a race condition or an unitialized variable, wrong pointer or similar? Because the oglThread will be restarted immediately to show the last OSD (before resize).


    But nevertheless, i'm currently happy with disabling the OpenGL OSD and i'm able to work further on :)

    Zabrimus

    I'm implementing a HbbTV plugin. You can check the sources at

    VDR OSR Browser (github) - the offscreen browser which renders the pages using CEF

    (easiest build can be done by "make release". But be aware that ca. 250 MB are loaded (for a binary build of CEF) from http://opensource.spotify.com/cefbuilds/index.html)


    VDR Plugin HbbTV - The VDR plugin


    The develop branches will be merged after some optimizations into the master branch.

    @lnj

    I have created a minimal test plugin. It can be found at Github OsdTest


    In osdimage.c the scaling of the image can be activated or deactivated. Scaling uses FFmpeg libswscale. Unfortunetely VDR has no interface in cPixmap to scale images automatically (e.g. using the gpu, opengl or similar). Therefore i need software scaling :(

    Code
    // scale image
#define SCALEOSD

    Comment the define, and the image is used as is. Image size is 1280 x 720.


    Following observations:

    I have no issue if softhddevice is started with "-w disable-ogl-osd". Both scaled and unscaled image works as desired.

    But if started without the parameter, VDR crashes very fast if i resize the window.

    Code
    Thread 1 "vdr" received signal SIGSEGV, Segmentation fault.
OsdImage::SetOsdSize (this=0x555555abf450) at osdimage.c:109
109         pixmap->Clear();
(gdb) bt
#0  0x00007fffe9dabc11 in OsdImage::SetOsdSize() (this=0x555555abf450) at osdimage.c:109
#1  0x00007fffe9dabce3 in OsdImage::readOsdUpdate() (this=0x555555abf450) at osdimage.c:134
#2  0x00007fffe9daba63 in OsdImage::TriggerOsdResize() (this=0x555555abf450) at osdimage.c:85
#3  0x00007fffe9dab48c in cPluginOsdtest::MainThreadHook() (this=0x5555558c9190) at osdtest.c:95
#4  0x0000555555699d83 in cPluginManager::MainThreadHook() (this=0x7fffffffdab0) at plugin.c:405
#5  0x00005555557034a8 in main(int, char**) (argc=10, argv=0x5555557fc0b0) at vdr.c:1550


    The problem is the following code in osdtest.c:


    Or is this fundamentally wrong coded? Because pixmap seems to be always null (except the very first call).
    And haven't found a solution to prevent this. The test plugin doesn't use any threads, therefore the oberservation is different to that from the real plugin, which creates a backtrace in softhddevice.


    Zabrimus

    I tryed now.

    1. No test for exist image file in /tmp, have crash without it :)

    2. Incorrect Makefile lib linker, I have ERROR: /usr/src/vdr-2.4.1-mod/PLUGINS/lib/libvdr-osdtest.so.2.4.1: undefined symbol: sws_scale

    In Makefile I changed 2 lines:


    LIBS += $(shell pkg-config --libs libswscale)


    $(Q)$(CXX) $(CXXFLAGS) $(LDFLAGS) -shared $(OBJS) $(LIBS) -o $@

    After that I have:


    With cuvid and opengl osd plugin works fine without crash.


    With vdpau and opengl osd I have crash from time to time, in log:

    And from time to time I have works plugin with vdpau and opengl osd, no crash.

    Hi,

    here with softhddevice (vaapi)

    did add a test if(!swsCtx)

    Construct OsdImage...

    start readOsdUpdate

    Image size 0x0

    OsdImage readOsdUpdate, get scale context

    OsdImage readOsdUpdate, swsCtx 0?

    OsdImage readOsdUpdate, scale image

    Magick: abort due to signal 11 (SIGSEGV) "Segmentation Fault"...

    Aborted (core dumped)


    so maybe the context is 0 some times.


    add:

    but the hbbtv plugin did scale for some unkown reason fine now with vaapi and softhddevice.

    CU

    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

    Edited once, last by 9000H ().

    Hi,

    with softhdcuvid (vaapi) openglosd it did crash immediately



    CU

    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

    This is really strange. The test image will be copied with the install target - i thought. And i have used the static linker in the Makefile.

    I have started a new test with vdr 2.4.1 and also updated my softhddevice plugin to the latest version.

    And there is no difference to my very first observation:

    pixmap is always null and i never. And sometimes get this


    The image size is the result of


    It is really strange to have different behaviour and values with same sources. Nonsense image sizes can be catched in the sources, but then i have no image at all.

    Forgot to mention: softhddevice with vdpau, vdr 2.4.0 and 2.4.1 without any patches.


    Is it an error in my plugin? Or not? And how to get the plugin running in all versions of softhd*

    Totally confused now....


    ps:

    I tried to compile ffmpeg mit cuvid and this drives me crazy. With --enable-shared, ffmpeg does not show cuvid as decoder. Without --enable-shared, ffmpeg shows me the cuvid decoder, but then i have no shared libaries. And i don't know how to check if cuvid is used in softhddevice?

    I am finally able to use softhddevice/softhdcuvid with cuvid. At least one advantage of trying to fix errors ;)


    In the meanwhile i've added many checks for display width/height to both osdtest the main plugin and these values are now ignored and the processing only takes place if valid values are returned/found.


    The result is, that i wasn't successful anymore to get a crash in my plugin. But VDR still crashed in softhddevice with the already mentions backtrace


    I have played a little bit with the sources of softhddevice and inserted two statements:

    and i got no exception anymore while resizing the VDR window. But now there seems to exists a deadlock

    And no menu opens at all anymore.


    Hi,

    no issues with latest osdtest and softhddevice(vaapi)

    but with softhdcuvid(vaapi) it did crash

    core dump

    maybe jojo61 can have a look

    CU

    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

    Edited once, last by 9000H ().

    @lnj

    I'm using only the VDR core menu. And while often resizing the VDR window, at some time, VDR segfaults or stuck with the above backtrace. Neither osdtest nor the main plugin is involved.


    I've created a patch but with possibly not the best solution. But I was not able anymore to get a deadlock or crash at all (independant of the plugin or core VDR menu).


    But there is one downside. Sometimes the command queue shall get filled with too many commands while the thread is !Running and then the OSD is empty until the next resize. This happens not too often, but it happens. Therefore i think, there could exists a better solution.

    I have tested softhdcuvid and this plugin seems to have similar problems as described above. Like segfault in

    Code
    if (FT_Done_FreeType(ftLib))
        esyslog("failed to deinitialize FreeType library!");

    But additionally softhdcuvid crashes immediately when trying to open osdtest.

    I have to remove the area sizes greater than Full HD to be able to show at least the initial osdtest pixmap

    Code
    tArea areas[] = {
            // {0, 0, 4096 - 1, 2160 - 1, 32}, // 4K
            // {0, 0, 2560 - 1, 1440 - 1, 32}, // 2K
            {0, 0, 1920 - 1, 1080 - 1, 32}, // Full HD
            {0, 0, 1280 - 1,  720 - 1, 32}, // 720p
    };


    Zabrimus

    You are right. 4K, 4K2K, UHD, QFFHD, .... :/ But it still crashes with 3840x2160 and 2560x1440. But with another BT


    Is it because of the nvidia driver 418?

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login