I have a situation where the programme counter(PC) shows
that vxworks msgQreceive function has been called by task A
and Q is full, still I am not picking up the messages. There
is no other task registered to receive messages from this Q.
The sending task B, which is ISR in this case, is getting
timedout everytime it tries posting new message in it. A's
state is PEND which means I am waiting for some resource to
get free but PC shows I have called vxworks msgQReceive and
currently at qJobget+0x018 location. There seems to be two
causes now(identified by me): either vxworks qjobget task is
not able to do semTake or no messages in Q. But Q is full
and semTake failure seems unlikely(though I dont have a
mechanism to check so).

Besides explaining root cause for above, can anyone suggest
how to get my task in READY state again? I also tried
flushing the Q; on doing this, more messages get posted in Q
but A still doesnt pick up any :(

Answers were Sorted based on User's Feedback



I have a situation where the programme counter(PC) shows that vxworks msgQreceive function has been..

Answer / mohit

Thanks Gaurav for ur answer. But if B is using WAIT_FOREVER,
it should never timed out, right? Also, all application
tasks are runnig n at same priority in preemptive manner.
Anyhow, in this case, I found that qJobGet() of vxworks is a
lower level generic function which is used by many other
routines including msgSend. If this is the case, I am trying
out following:
1. I am trying to get a stack dump of this task. Though it
would involve lot of labour but I am hoping to take a dump
of valid addresses that I found in its stack. This should
help in obtaining actual caller of qJobGet(). This way, we
might find the resource our task A is actually wai6ting for
to acquire(it should be either of some vxworks semaphore or
msgQ itself).
2. Second, I found that task structure of vxworks contains a
variable that stores the address of the object task is
currently PENDed on. If that address can be dumped, again we
can hope to progress from here.
Unfortunately am using an older version of vxworks and can
not afford to upgrade to later versions. So, many of the
utilities found on web have to be actually written using
available vxworks's online tools.

Is This Answer Correct ?    1 Yes 0 No

I have a situation where the programme counter(PC) shows that vxworks msgQreceive function has been..

Answer / sandy

Its been a while since I worked with VxWorks platform, but
what I suspect is that it may be a basic implementation
problem and nothing to do with the VxWorks routine. I would
expect that such basic issues in the OS primitives to be
already solved by the vendor(at least for this one, given
the price we pay). It may not be reasonable to suspect the
implementation of this basic OS service.
1. Very simple way to debug would be to write a task that
only reads from this queue and does nothing else. Do not
copy the code from the task being debugged, write afresh.
It is very easy to have overlooked a seemingly good but
trivial coding error.

2. It is highly likely that the que that u are examining is
a different que than the task is trying to read from. There
are may ways this can happen, one of which -- Do you use
any task variables? why I ask is that, the qID that you are
using to read() may be a task variable OR part of a
datablock that is implemented in a 'task variable' way.
Though the same global variable name, it would be a
different memory.

3. If you have already figured out the issue, please share
with us:-)

Is This Answer Correct ?    0 Yes 0 No

I have a situation where the programme counter(PC) shows that vxworks msgQreceive function has been..

Answer / mohit

Hi Gaurav/Sandy,
Sorry that i forgot to post the issue I found. I dumped the
task A stack and read the functions pushed onto stack. this
led me to the last caller of the function. I found that task
A was pending on another Q which was created 'dynamically'
to send a small message to different board(controlled by
different processor). task A was on WAIT_FOREVER for an
acknowledgement of message sent. Now, it was the case of IPC
message dropped due to which even though receiving board did
send the acknowledgement(verified multiple times using
counter), it was not received by task A. To overcome
problem, i changed the timeout value for ACK to finite value
and everything now works fine(IPC messages dropped count
increasing though).
So it was indeed a different Q that task A was pending on.
But due to PC showing qjobGet(), i was confusing the two.
Also the other Q was being dynamically created to send IPC
message and destroyed on receiving Ack. This is a very bad
coding method and am now chasing the writer of that code :)

Is This Answer Correct ?    0 Yes 0 No

I have a situation where the programme counter(PC) shows that vxworks msgQreceive function has been..

Answer / gaurav srivastava

That is very strange , in your case the problem does not
seem to be the queue or msgQRecieve .I would go through the
following checklist :

1)What is the priority given to task A ? Is it high enough
when compared to other coexisting tasks ? If the priority
is very low then A wouldnt get executed often enough to
clear the queue (with task A being the only reader) , the
queue would get full and B would time out if it is
WAIT_FOREVER .

2)Make sure you are reading from the right queue.

I can't think of anything else , please let me know if you
have already found a solution to your problem.

Is This Answer Correct ?    0 Yes 1 No

Post New Answer

More Vxworks Interview Questions

What is another for creating a task without using taskspawn?

2 Answers  


what do u mean by Semaphore..when v wil go for using this..explain about hat.what is the difference betw..binary ,,counting and mutex semphores

2 Answers   Bosch,


I have a situation where the programme counter(PC) shows that vxworks msgQreceive function has been called by task A and Q is full, still I am not picking up the messages. There is no other task registered to receive messages from this Q. The sending task B, which is ISR in this case, is getting timedout everytime it tries posting new message in it. A's state is PEND which means I am waiting for some resource to get free but PC shows I have called vxworks msgQReceive and currently at qJobget+0x018 location. There seems to be two causes now(identified by me): either vxworks qjobget task is not able to do semTake or no messages in Q. But Q is full and semTake failure seems unlikely(though I dont have a mechanism to check so). Besides explaining root cause for above, can anyone suggest how to get my task in READY state again? I also tried flushing the Q; on doing this, more messages get posted in Q but A still doesnt pick up any :(

4 Answers  


Assume there is a global variable & a static global variable.Both gets memory allocated from the data segment. Then how does the visiblity of static global varible gets limited to the file alone (in which it gets declared) ???

2 Answers   Wipro,


What is priority inversion?

10 Answers   Juniper Networks,






what are the various methods to overcome it?

2 Answers   Vector India,


Write a code to connect Hardware interrupt to ISR...?

1 Answers   iNet, Wipro,


hi this is srikanth i need video classes for Vxworks any body having this forward me thanking u

1 Answers   DELL, Wipro,


Which RTOS supports Non-Preemptive scheduling ? Why other scheduling methods are supported by such Oses?

1 Answers   Elico,


what is task spawn in vxworks ?plz anyone explain me

2 Answers   NAL,


IN RTOS HAVING 1OKBYTES OF MEMORY AND YOUR PROGRAMM FOR ASKING FOR 5KBYTES AND YOU GOT NULL ERROR ? WHY DOES IT BEHAVES LIKE THIS

4 Answers  


Categories