syslink error MessageQDrv.c with EZSDK gstreamer

Gunter:

    A call to MessageQ_create() failed. 

            if (cargs.args.create.params != NULL) {
                cargs.args.create.handle = MessageQ_create (name, &params);
            }
            else {
                cargs.args.create.handle = MessageQ_create (name, NULL);
            }
            GT_assert (curTrace, (cargs.args.create.handle != NULL));

    See line 419 in: 

   http://www.sanb.design.ti.com/tisb_releases/SysLink/2_10_03_20/exports/syslink_2_10_03_20/packages/ti/syslink/ipc/hlos/knl/Linux/MessageQDrv.c

   There are several ways MesageQ_create() can fail, but in all error cases it returns NULL and can print an error trace, see:

    http://www.sanb.design.ti.com/tisb_releases/SysLink/2_10_03_20/exports/syslink_2_10_03_20/packages/ti/syslink/ipc/hlos/knl/MessageQ.c

    One possible failure mode would be doing a MessageQ_create() with a MessageQ name same as one that is already in use.   Is there some GST element in the pipeline which gets energy every 20 seconds?  or fails to initialize the first time and automatically checks and retries and fails?

    It may help if you can turn on the SysLink kernel side trace:  http://processors.wiki.ti.com/index.php/SysLink_UserGuide#Trace.2C_debug_and_build_configuration

    and cross check against what the GST element plugin code is doing.

- Gil

I think along these same lines is the following post.

http://e2e.ti.com/support/embedded/linux/f/354/t/241471.aspx

The post above is what we are experiencing.  The logs are with the kernel side trace enabled.  It always happens after a restart of a process if the process dies without cleanup of the pipeline.