Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Robby_S
New Contributor I
132 Views

First call to m_mfxSession.InitEx() caused "Segmentation fault"

Jump to solution

So I partially rewrote my application to fit the initialization function into the Media Server Studio SDK. When I ran my code, after the call to m_mfxSession.InitEx(), the code crashed with the error message "Segmentation fault". I tried with both MFX_IMPL_HARDWARE_ANY and MFX_IMPL_SOFTWARE, the same crash happened in both cases.

What are the likely causes?

One thing I can think of is that my code uses libraries from the FFMPEG libav tools, such as libavcodec, libavdevice, libavfilter, libavformat, etc. I understand that the libav library provided with the Media Server Studio SDK may not necessarily be compatible with the aforementioned libraries. Is it possible that the crash is caused by the incompatible libraries?

I am working to verify my suspicion. Meanwhile, if you already know the answer, please kindly let me know.

Thanks,

Robby

0 Kudos
1 Solution
132 Views

Hi Robby - Some update on the issue. As mentioned previously and you observed, directly linking dispatcher is not recommended. If it is absolutely necessary, some of the dispatcher logic should be replicated on the application side (such as adapter selection). According to the manual, it says: "Applications use SDK functions by linking with the SDK dispatcher library, as illustrated in Figure 2. The dispatcher library identifies the hardware acceleration device on the running platform, determines the most suitable platform library, and then redirects function calls. If the dispatcher is unable to detect any suitable platform-specific hardware, the dispatcher redirects SDK function calls to the default software library." So, directly linking is not recommended.

We are going to update the Linux document to reflect this recommendation (thanks for letting us know). We have logged this behavior and will try to fix this at appropriate pace - given the nature of the issue and it's "criticality" (which is not high since there is a known and recommended methodology that works).

 

View solution in original post

12 Replies
132 Views

Hi Robby - From the information you have provided, its hard to say what the root cause is. In general, if the error occurs in MSDK, the SDK throws error codes and (unhelpful, agreed) error messages. Segfault after InitEx() does not seem like an MSDK issue. The InitEx() takes the mfxInitParam structure as input - so let us know what the parameters are that you are passing to the InitEx(). For code reviews, it would be helpful in general to give us access to the code. 

 

Robby_S
New Contributor I
132 Views
mfxStatus SurvlChannel::Init(sInputParams *pParams)
{
    MSDK_CHECK_POINTER(pParams, MFX_ERR_NULL_PTR);

    mfxStatus sts = MFX_ERR_NONE;

    // prepare input stream file reader
    // for our purpose, only H.264 format is supported
    if (MFX_CODEC_AVC == pParams->videoType) {
        msdk_printf(MSDK_STRING("new CH264FrameReader() ... "));
        m_FileReader.reset(new CH264FrameReader());
        m_bIsCompleteFrame = true;
    }
    else {
        return MFX_ERR_UNSUPPORTED; // latency mode is supported only for H.264 and JPEG codecs
    }
    msdk_printf(MSDK_STRING("returned;\n"));

    msdk_printf(MSDK_STRING("m_FileReader->Init(pParams->strSrcFile) ... "));
    sts = m_FileReader->Init(pParams->strSrcFile);
    msdk_printf(MSDK_STRING("returned;\n"));
    MSDK_CHECK_RESULT(sts, MFX_ERR_NONE, sts);

    // memory type
    m_memType = pParams->memType;
    m_nFrames = pParams->nFrames ? pParams->nFrames : MFX_INFINITE;

    mfxInitParam initPar;
    mfxExtThreadsParam threadsPar;
    mfxExtBuffer* extBufs[1];
    mfxVersion version;     // real API version with which library is initialized

    MSDK_ZERO_MEMORY(initPar);
    MSDK_ZERO_MEMORY(threadsPar);

    // we set version to 1.0 and later we will query actual version of the library which will got leaded
    initPar.Version.Major = 1;
    initPar.Version.Minor = 0;

    initPar.GPUCopy = pParams->gpuCopy;

    msdk_printf(MSDK_STRING("init_ext_buffer(threadsPar) ... "));
    init_ext_buffer(threadsPar);
    msdk_printf(MSDK_STRING("returned;\n"));

    bool needInitExtPar = false;

    msdk_printf(MSDK_STRING("pParams->nThreadsNum == %d;\n"), pParams->nThreadsNum);
    if (pParams->nThreadsNum) {
        threadsPar.NumThread = pParams->nThreadsNum;
        needInitExtPar = true;
    }

    msdk_printf(MSDK_STRING("pParams->SchedulingType == %d;\n"), pParams->SchedulingType);
    if (pParams->SchedulingType) {
        threadsPar.SchedulingType = pParams->SchedulingType;
        needInitExtPar = true;
    }

    msdk_printf(MSDK_STRING("pParams->Priority == %d;\n"), pParams->Priority);
    if (pParams->Priority) {
        threadsPar.Priority = pParams->Priority;
        needInitExtPar = true;
    }

    msdk_printf(MSDK_STRING("needInitExtPar == %s;\n"), (needInitExtPar? "true" : "false"));
    if (needInitExtPar) {
        extBufs[0] = (mfxExtBuffer*)&threadsPar;
        initPar.ExtParam = extBufs;
        initPar.NumExtParam = 1;
    }

    // for debugging 
    initPar.Implementation = MFX_IMPL_HARDWARE_ANY;

    // create & initialize an MSDK session
    // call MFXInitEx() before calling any other MSDK functions.
    msdk_printf(MSDK_STRING("\n&m_mfxSession == %p...\n"), &m_mfxSession);
    msdk_printf(MSDK_STRING("\n&initPar == %p...\n\n"), &initPar);

    msdk_printf(MSDK_STRING("initPar.Implementation == %d;\n"), initPar.Implementation);
    msdk_printf(MSDK_STRING("initPar.Version.Major == %d;\n"), initPar.Version.Major);
    msdk_printf(MSDK_STRING("initPar.Version.Minor == %d;\n"), initPar.Version.Minor);
    msdk_printf(MSDK_STRING("initPar.ExternalThreads == %d;\n"), initPar.ExternalThreads);
    msdk_printf(MSDK_STRING("initPar.ExtParam == %p;\n"), initPar.ExtParam);
    msdk_printf(MSDK_STRING("initPar.NumExtParam == %d;\n"), initPar.NumExtParam);
    msdk_printf(MSDK_STRING("initPar.GPUCopy == %d;\n"), initPar.GPUCopy);
    msdk_printf(MSDK_STRING("&(initPar.reserved) == %p;\n"), &(initPar.reserved));

    if (pParams->bUseHWLib) {
        // try searching on all display adapters
        msdk_printf(MSDK_STRING("  HW: m_mfxSession.InitEx(initPar) ... \n"));
        //initPar.Implementation = MFX_IMPL_HARDWARE_ANY;
        sts = m_mfxSession.InitEx(initPar);
        msdk_printf(MSDK_STRING("  ... returned;\n"));

        // MSDK API version may not support multiple adapters - then try initialize on the default
        if (MFX_ERR_NONE != sts) {
            msdk_printf(MSDK_STRING("  HW failed; try again: m_mfxSession.InitEx(initPar) ... \n"));
            initPar.Implementation = (initPar.Implementation & !MFX_IMPL_HARDWARE_ANY) | MFX_IMPL_HARDWARE;
            sts = m_mfxSession.InitEx(initPar);
        msdk_printf(MSDK_STRING("  ... returned;\n"));
        }
    } else {
        msdk_printf(MSDK_STRING("  SW: m_mfxSession.InitEx(initPar) ... \n"));
        //initPar.Implementation = MFX_IMPL_SOFTWARE;
        sts = m_mfxSession.InitEx(initPar);
        msdk_printf(MSDK_STRING("  ... returned;\n"));
    }

    MSDK_CHECK_RESULT(sts, MFX_ERR_NONE, sts);

    sts = MFXQueryVersion(m_mfxSession , &version); // get real API version of the loaded library
    MSDK_CHECK_RESULT(sts, MFX_ERR_NONE, sts);

    // create decoder
    msdk_printf(MSDK_STRING("new MFXVideoDECODE(m_mfxSession) ... "));
    m_pmfxDEC = new MFXVideoDECODE(m_mfxSession);
    msdk_printf(MSDK_STRING("returned;\n"));
    MSDK_CHECK_POINTER(m_pmfxDEC, MFX_ERR_MEMORY_ALLOC);

    // set video type in parameters
    m_mfxVideoParams.mfx.CodecId = pParams->videoType;

    // prepare bit stream
    msdk_printf(MSDK_STRING("InitMfxBitstream( , ) ... "));
    sts = InitMfxBitstream(&m_mfxBS, pParams->nBitStrLen);
    msdk_printf(MSDK_STRING("returned;\n"));
    MSDK_CHECK_RESULT(sts, MFX_ERR_NONE, sts);

    // Populate parameters. Involves DecodeHeader call
    msdk_printf(MSDK_STRING("InitMfxParams( ) ... "));
    sts = InitMfxParams(pParams);
    msdk_printf(MSDK_STRING("returned;\n"));
    MSDK_CHECK_RESULT(sts, MFX_ERR_NONE, sts);

    // create device and allocator
    msdk_printf(MSDK_STRING("CreateAllocator( ) ... "));
    sts = CreateAllocator();
    msdk_printf(MSDK_STRING("returned;\n"));
    MSDK_CHECK_RESULT(sts, MFX_ERR_NONE, sts);

    // in case of HW accelerated decode frames must be allocated prior to decoder initialization
    msdk_printf(MSDK_STRING("AllocFrames( ) ... "));
    sts = AllocFrames();
    msdk_printf(MSDK_STRING("returned;\n"));
    MSDK_CHECK_RESULT(sts, MFX_ERR_NONE, sts);

    msdk_printf(MSDK_STRING("m_pmfxDEC->Init(&m_mfxVideoParams) ... "));
    sts = m_pmfxDEC->Init(&m_mfxVideoParams);
    msdk_printf(MSDK_STRING("returned;\n"));
    if (MFX_WRN_PARTIAL_ACCELERATION == sts)
    {
        msdk_printf(MSDK_STRING("WARNING: partial acceleration\n"));
        MSDK_IGNORE_MFX_STS(sts, MFX_WRN_PARTIAL_ACCELERATION);
    }
    MSDK_CHECK_RESULT(sts, MFX_ERR_NONE, sts);

    return sts;
}

 

Robby_S
New Contributor I
132 Views

Hi, Sravanthi, please see above for my initialization function, with excessive logging instructions. 

Below is the stdout output when I ran the code:

new CH264FrameReader() ... returned;
m_FileReader->Init(pParams->strSrcFile) ... returned;
init_ext_buffer(threadsPar) ... returned;
pParams->nThreadsNum == 0;
pParams->SchedulingType == 0;
pParams->Priority == 0;
needInitExtPar == false;

&m_mfxSession == 0x6bd1650...

&initPar == 0x7fffec3ce1d0...

initPar.Implementation == 4;
initPar.Version.Major == 1;
initPar.Version.Minor == 0;
initPar.ExternalThreads == 0;
initPar.ExtParam == (nil);
initPar.NumExtParam == 0;
initPar.GPUCopy == 0;
&(initPar.reserved) == 0x7fffec3ce1f2;
  HW: m_mfxSession.InitEx(initPar) ... 
Segmentation fault

Robby_S
New Contributor I
132 Views

I removed  the dependency on libraries from the FFMPEG libav tools. Now things got a little more interesting ...

If I set Implementation to MFX_IMPL_HARDWARE_ANY, I still got the same old "Segmentation fault".

However, if I set Implementation to MFX_IMPL_SOFTWARE, I got this:

  SW: m_mfxSession.InitEx(initPar) ... 
  ... returned;
Return on error: error code -3,    bdti_mfx_survl.cpp    203

As defined in mfxdefs.h, MFX_ERR_UNSUPPORTED == -3. What can possibly cause this error?

Thanks,

Robby

 

Robby_S
New Contributor I
132 Views

OK I found the real cause: 

In my makefile, I was explicitly loading libmfx.so, as well as libmfxhw64.so. The latter was the culprit.

Only after I had found out that explicitly loading libmfxhw64.so was the culprit, and googled for it, did I see the warning against loading libmfxhw64.dll and libmfxsw64.dll not through the dispatcher in the release notes for the Windows version. However, The release notes for Linux (2015R6), which I was using, did not mention it at all! That is annoying.

I still don't quite understand why explicitly loading libmfxhw64.so gave me "Segmentation fault". My hardware supports the hardware acceleration.

As always, opinions, insights are welcome and greatly appreciated. Thanks.

-Robby

132 Views

Hi Robby - Glad you were able to figure out the issue. The MSDK, by default, links to the dispatcher when you build the application or run it. But the "segmentation fault" instead of throwing an error can surely be annoying - let me get back to you on why this is happening instead of a warning/error message at build/compile time. Once we know that, we can add that to the Release Notes document for Linux too.

Robby_S
New Contributor I
132 Views

Thanks Sravanthi. Please let me know if you find out something about the issue.

132 Views

Hi Robby - sure. Just wanted to check - Are you gated on the issue, and waiting for a fix? From your previous post, it seemed like you had found the root cause (explicitly loading the library) and have worked around it to build your application. Am I mistaken? 

Robby_S
New Contributor I
132 Views

Hi Sravanthi,

Yes I have solved the issue; no I am not gated on it. I was just curious to know if the issue could be reproduced. Sorry if I didn't make it clear in my earlier post.

-Robby

133 Views

Hi Robby - Some update on the issue. As mentioned previously and you observed, directly linking dispatcher is not recommended. If it is absolutely necessary, some of the dispatcher logic should be replicated on the application side (such as adapter selection). According to the manual, it says: "Applications use SDK functions by linking with the SDK dispatcher library, as illustrated in Figure 2. The dispatcher library identifies the hardware acceleration device on the running platform, determines the most suitable platform library, and then redirects function calls. If the dispatcher is unable to detect any suitable platform-specific hardware, the dispatcher redirects SDK function calls to the default software library." So, directly linking is not recommended.

We are going to update the Linux document to reflect this recommendation (thanks for letting us know). We have logged this behavior and will try to fix this at appropriate pace - given the nature of the issue and it's "criticality" (which is not high since there is a known and recommended methodology that works).

 

View solution in original post

132 Views

Also, would it be alright if I closed this thread? You can certainly start a new thread for any other issues, and we will be happy to help.

Robby_S
New Contributor I
132 Views

Sravanthi - Thanks for the explanation. Yes you can close the thread.

Reply