• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 618 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OpenMax (OMX) callbacks crash/freeze when writing to stderr -- OMX bug?

Jon S.
Expert 1240 points

Hi there,

I am seeing that OMX applications freeze/crash when my IL_ClientCbEventHandler() callback calls fprintf(stderr, "my text...").  I am able to replicate this on the OMX example applications provided with EZSDK 5.03.01.15, just by replacing the printf's on state changes, port enable/disables, etc with fprintf's to stderr. Is this a bug?

I'm able to write to standard error from my main thread fine, and printf (to stdout) obviously works, as it's done in the demo. Are some file descriptors getting closed/corrupted in whatever threads the OMX api is creating? (I see the handler is called from omxproxy_handle_event, but don't know much about the context in which that code is being run...)

Thanks,

Jon

  • 0
    Prodigy 200 points

    The crash is due to a stack overflow. The threads from where the callbacks are called are created with too small stacks. What you can do is declare:

    #include <stdarg.h>
    #include <unistd.h>
    #include <pthread.h>

    int omx_printf(const char *fmt, ...)
    {
            static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
            static char buf[1024];
            va_list ap;
            int rc;
            
            va_start(ap, fmt);
            pthread_mutex_lock(&mutex);
            rc = vsnprintf(buf, sizeof(buf), fmt, ap);
            write(2, buf, rc);
            pthread_mutex_unlock(&mutex);
            va_end(ap);

            return rc;
    }

    And call omx_printf instead of fprintf.

  • 0 in reply to Gilles Chanteperdrix
    Expert 1240 points

    Gilles,

    Thank you for your insight on this -- I really appreciate it.  I'll give that a shot.

    Any chance you'd mind elaborating on how you found this?  I was having some trouble getting gdbserver to hit breakpoints and give me meaningful backtraces in OpenMax applications (makes sense if my stack was clobbered I guess...), and didn't see much in the way of pthread creation. (I saw some TIMM_OSAL_CreateTask functions, but I'm not sure if that's used by the API...)

    - Jon

  • 0 in reply to Jon S.
    Prodigy 200 points

    I met the issue on platforms where gdb was working and so where I could read the sp value in gbd. I guess you could find out the issue with omx on DM814x by compiling the kernel with CONFIG_DEBUG_USER, then booting the kernel with parameter debug_user=29. This causes the kernel to log information (including registers value in the application context) about faults when they happen. Then, with values of the pc register you would find by disassembling your binary that the segfault happens at a place where a stack push or pop operation happens. Then you would dump the process maps and find that the value of the sp register is out of any valid map, or in a read-only mapping.

  • 0 in reply to Gilles Chanteperdrix
    Expert 1240 points

    Gilles,

    Marking the thread "verified" -- tested that out and everything's running well.  Many thanks for the info on this, as well as the debugging tips!

    Cheers!

    Jon