Rommel Dongre <rdongre@pillardata.com> wrote:
Hi:
We’re trying to debug the following situation:
Process A is a resource manager.
Process B is a client.
Process B does an open() to the namespace registered by Process A.
This returns a good fd.
Then Process B does a devctl() on that fd.
This never returns. pidin shows that Process B is REPLY blocked on
Process A. But the devctl() handler of Process A has not been hit!
Well, that does mean the message got to process A.
Does process A use a threadpool, or did you write your main loop:
while(1){
ctp = dispatch_block();
dispatch_handler(ctp);
}
If you wrote your own loop, or for debug purposes, you can substitute
and run single threaded, you can:
while(1){
unsigned short *type;
ctp = dispatch_block();
type = (short *)(ctp->msg);
printf(“message type is %d\n”, *type );
dispatch_handler(ctp);
}
This gets you a pretty good trace of the messages as they come in.
ctp->msg is the start of the incoming message. The message type is
the first 16-bit (short type) for all messages.
You can print out other useful bits, like ctp->info bits, such
as pid, coid, etc of who sent the message, for debugging.
Where did that message go? Is there a way to track the IPC messages
(something like a tcpdump for IPC messages?)
The fact that you are receive block on process A means the message
went to process A.
The fact that your devctl handler didn’t get called is a different
issue.
Also, the system analysis/profiling perspective/tool in the IDE along
with the instrumented kernel can give remarkable insight into where
messages go – but I don’t think you need it for this.
The REPLY blocked on Process A clearly labels that your message came
to Process A – its just a question of what happened after.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.