How to locate the SEM_ID a task is blocked on? - VxWorks

This is a discussion on How to locate the SEM_ID a task is blocked on? - VxWorks ; Hello, I'm trying to debug a system with about 50+ tasks. I have a specific task that I'm interested in identifying why it's blocking indefintely on a semaphore, which is not the expected behavior. What I'd like to know is ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: How to locate the SEM_ID a task is blocked on?

  1. How to locate the SEM_ID a task is blocked on?

    Hello,
    I'm trying to debug a system with about 50+ tasks. I have a specific
    task that I'm interested in identifying why it's blocking indefintely
    on a semaphore, which is not the expected behavior. What I'd like to
    know is which of the other tasks in the system is currently holding the
    semaphore, so I can determine what conditions are preventing its
    release. I've done some searching in this news group and encountered
    the semShow and semInfo routines but both require knowning the SEM_ID
    in advance. Is a reverse lookup possible (i.e a way to obtain the
    SEM_ID for a given taskID)?

    Thanks in advance,
    John


  2. Re: How to locate the SEM_ID a task is blocked on?


    On 13 Aug 2005, boynton_john@yahoo.com wrote:
    > Hello, I'm trying to debug a system with about 50+ tasks. I have a
    > specific task that I'm interested in identifying why it's blocking
    > indefintely on a semaphore, which is not the expected behavior.
    > What I'd like to know is which of the other tasks in the system is
    > currently holding the semaphore, so I can determine what conditions
    > are preventing its release. I've done some searching in this news
    > group and encountered the semShow and semInfo routines but both
    > require knowning the SEM_ID in advance. Is a reverse lookup
    > possible (i.e a way to obtain the SEM_ID for a given taskID)?


    "http://groups.google.ca/groups?q=waitList+group:comp.os.vxworks"

    I understand that this doesn't directly answer your question [if I
    understand your question, it seems a bit vague to me]. However, it
    might help you answer your own question. I don't know what the "show
    semId" will produce. I believe that the code [waitList()] will print
    out any of the last pending objects, even if the task is running.

    A problem with your question "Who holds the semaphore?" is that this
    information may not be kept. If a task succeeds in grabbing a
    semaphore, it is just allowed to run. Why would vxWorks keep
    information on what task has took the semaphore. Especially since it
    is legal to give the semaphore from yet another task.

    Windview, function shim/hook, etc. For an example of how to replace
    your own function with some vxWorks function, there are WTNs on the
    subject. As well, the Makefile for Doug Lea's allocator also show how
    to manipulate functions names in the vxWorks library. However, you
    can do the same thing with "#define semGive", "#define semTake", etc.

    hth,
    Bill Pringlemeir.

    --
    I never did give anybody hell. I just told the truth and they thought
    it was hell. - Harry S. Truman

    vxWorks FAQ, "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"

  3. Re: How to locate the SEM_ID a task is blocked on?

    boynton_john@yahoo.com wrote:
    > Hello,
    > I'm trying to debug a system with about 50+ tasks. I have a specific
    > task that I'm interested in identifying why it's blocking indefintely
    > on a semaphore, which is not the expected behavior.


    If this task is blocking indefintely, it also means the task that is
    holding this lock is not releasing it. So i think you have to 2
    problems to solve, not one.

    > What I'd like to
    > know is which of the other tasks in the system is currently holding the
    > semaphore, so I can determine what conditions are preventing its
    > release.


    Personally I would proceed with logging/printing all tasks
    locking/unlocking attempts for this particluar sempahore. Maybe
    blocking for a smaller period instead of forever would help..

    > I've done some searching in this news group and encountered
    > the semShow and semInfo routines but both require knowning the SEM_ID
    > in advance. Is a reverse lookup possible (i.e a way to obtain the
    > SEM_ID for a given taskID)?
    >
    > Thanks in advance,
    > John


    HTH

    --
    Prafulla Harpanhalli


  4. How to override or put a wrapper around a VxWorks system call

    Bill Pringlemeir wrote:
    >
    > Windview, function shim/hook, etc. For an example of how to replace
    > your own function with some vxWorks function, there are WTNs on the
    > subject. As well, the Makefile for Doug Lea's allocator also show how
    > to manipulate functions names in the vxWorks library. However, you
    > can do the same thing with "#define semGive", "#define semTake", etc.
    >


    This last replacement of a VxWorks function with your own function
    can also be performed using the "--wrap" option of the GNU linker.
    Here's the section out of the GNU LD manual about the option:

    Option "--wrap symbol"

    Use a wrapper function for symbol. Any undefined reference to
    symbol will be resolved to __wrap_symbol. Any undefined reference
    to __real_symbol will be resolved to symbol.

    This can be used to provide a wrapper for a system function. The
    wrapper function should be called __wrap_symbol. If it wishes to
    call the system function, it should call __real_symbol.

    Here is a trivial example:

    void *
    __wrap_malloc (size_t c)
    {
    printf ("malloc called with %zu\n", c);
    return __real_malloc (c);
    }

    If you link other code with this file using --wrap malloc, then
    all calls to malloc will call the function __wrap_malloc instead.
    The call to __real_malloc in __wrap_malloc will call the real
    malloc function.

    You may wish to provide a __real_malloc function as well, so that
    links without the --wrap option will succeed. If you do this,
    you should not put the definition of __real_malloc in the same
    file as __wrap_malloc; if you do, the assembler may resolve the
    call before the linker has a chance to wrap it to malloc.



    > hth,
    > Bill Pringlemeir.
    >


+ Reply to Thread