Process ID not displayed by the sin command

QNX Newsgroups (Archives) qdn.public.qnx4
1

Hi,

The system I am working on is a multitasking embedded system. The Receive()
function that I am using in one of the processes does not return the correct
process ID of the sender of some messages. I know which process is sending
the messages, I also know the process ID and the symbolic name attached to
that process, and I can see that data on the output screen of the QNX sin
command when issued at the command prompt. But the process ID returned by
the Receive() function in the receiving process is, for one thing, not the
process ID of the sender; secondly, a process with that ID does appear in
the list of currently running processes, which can be displayed by issuing
the sin command at the command prompt.

Any comments?

Thank you.

2

Is this local or remote communication. It may be the pid of a VC.

“Orhan Ozdengiz” <ozdengiz@axion.net> wrote in message
news:94o76h$m99$1@inn.qnx.com…

Hi,

The system I am working on is a multitasking embedded system. The
Receive()
function that I am using in one of the processes does not return the
correct
process ID of the sender of some messages. I know which process is sending
the messages, I also know the process ID and the symbolic name attached to
that process, and I can see that data on the output screen of the QNX sin
command when issued at the command prompt. But the process ID returned by
the Receive() function in the receiving process is, for one thing, not the
process ID of the sender; secondly, a process with that ID does appear in
the list of currently running processes, which can be displayed by issuing
the sin command at the command prompt.

Any comments?

Thank you.

3

“Orhan Ozdengiz” <ozdengiz@axion.net> wrote in message
news:94o76h$m99$1@inn.qnx.com…

Hi,

The system I am working on is a multitasking embedded system. The
Receive()
function that I am using in one of the processes does not return the
correct
process ID of the sender of some messages. I know which process is sending
the messages, I also know the process ID and the symbolic name attached to
that process, and I can see that data on the output screen of the QNX sin
command when issued at the command prompt. But the process ID returned by
the Receive() function in the receiving process is, for one thing, not the
process ID of the sender; secondly, a process with that ID does appear in
the list of currently running processes, which can be displayed by issuing
the sin command at the command prompt.

Any comments?

In my opinion what you describe is in theory impossible unless the
“other” process as actually send a message. There is little
information from which to make a guess here.

Last time I’ve seen some code do something like this, it was because
code in an interrupt handler was no writting at the right place as
was overwriting some stuff :wink:

Could you post the output of sin in question and the code where you
do the Receive() and print the pid



Thank you.

4

In the process doing the Receive(0, … are you attaching a prefix? If so, you
might be seeing a system utility sending standard messages such as fstat.

Orhan Ozdengiz wrote:

Hi,

The system I am working on is a multitasking embedded system. The Receive()
function that I am using in one of the processes does not return the correct
process ID of the sender of some messages. I know which process is sending
the messages, I also know the process ID and the symbolic name attached to
that process, and I can see that data on the output screen of the QNX sin
command when issued at the command prompt. But the process ID returned by
the Receive() function in the receiving process is, for one thing, not the
process ID of the sender; secondly, a process with that ID does appear in
the list of currently running processes, which can be displayed by issuing
the sin command at the command prompt.

Any comments?

Thank you.

5

Orhan Ozdengiz <ozdengiz@axion.net> wrote:

Hi,

The system I am working on is a multitasking embedded system. The Receive()
function that I am using in one of the processes does not return the correct
process ID of the sender of some messages. I know which process is sending
the messages, I also know the process ID and the symbolic name attached to
that process, and I can see that data on the output screen of the QNX sin
command when issued at the command prompt. But the process ID returned by
the Receive() function in the receiving process is, for one thing, not the
process ID of the sender; secondly, a process with that ID does appear in
the list of currently running processes, which can be displayed by issuing
the sin command at the command prompt.

Any comments?

Every time I’ve seen something like this it has been programmer error,
not system error. The Send/Receive/Reply stuff is used by everything
in the system.

A couple things to remember on something like this – just looking at the
data in the message doesn’t tell you where the message came from – if a
short or zero-length message came in, the contents of the data buffer will
be the same as from the previous message, which can give the illusion that
this is data that somebody else sent you. That is, a receive buffer is
NOT cleared by the system, only as many bytes as are sent will be copied
over. (Well, actually, the smaller of the number of bytes specified on
the send and for the receive will be copied.)

Do you have a signal handler or interrupt handler that could be modifying
a variable or memory out of the line of flow of the code?

Can you post the actual “sin” output from your system when you see this,
as well as the code from you program around your Receive call?

-David

QNX Training Services
dagibbs@qnx.com

6

Thank you for your interest.

I guess, I have to make the following correction to my original message: I
missed a “not” there. The last sentence of my message should read as
follows:

“… But the process ID returned by the Receive() function in the receiving
process is, for one thing, not the process ID of the sender; secondly, a
process with that ID does NOT appear in the list of currently running
processes, which can be displayed by issuing the sin command at the command
prompt.”

Here is additional info that will hopefully clarify certain points:

  • The software is running on a single node. No QNX network/no other nodes.

-The sending process triggers a proxy to communicate with the receiving
process (i.e. in this specific case, I am not using the
Send()/Receive()/Reply() trio). In other words, “Trigger(pxy);” is used and
the sending process has no clue about what the message represented by the
proxy, pxy, is. According to the principles of messaging-via-proxies (as it
is the case with the other IPC schemes), it is the Kernel’s responsibility
to move the ‘canned message’ corresponding to pxy from the receiving
process’ canned-message buffer to its receive buffer and to tell the
receiver process the ID of the sender (of course, you already know that).
Now, the sending process’ symbolic name and ID can be viewed on the console
(using the sin command) but the code prints out the sender’s ID as a few
numbers off the actual ID of the sending process. That is, if the sending
process’ ID is, say 567, the proxy gets triggered by process 568 (or 569…
the largest difference I have noticed so far was 20, and that, when the
actual sender’s process ID was a 4 digit number - no consistent pattern
occurs here). The funny thing is, 568 (or 569, or whatever that number may
be) is not displayed on the console when the sin command is issued.

-There are no user defined interrut handlers.


“Orhan Ozdengiz” <ozdengiz@axion.net> wrote in message
news:94o76h$m99$1@inn.qnx.com…

Hi,

The system I am working on is a multitasking embedded system. The
Receive()
function that I am using in one of the processes does not return the
correct
process ID of the sender of some messages. I know which process is sending
the messages, I also know the process ID and the symbolic name attached to
that process, and I can see that data on the output screen of the QNX sin
command when issued at the command prompt. But the process ID returned by
the Receive() function in the receiving process is, for one thing, not the
process ID of the sender; secondly, a process with that ID does appear in
the list of currently running processes, which can be displayed by issuing
the sin command at the command prompt.

Any comments?

Thank you.

7

“Orhan Ozdengiz” <ozdengiz@axion.net> wrote in message
news:94q714$1lk$1@inn.qnx.com…

Thank you for your interest.

I guess, I have to make the following correction to my original message: I
missed a “not” there. The last sentence of my message should read as
follows:

“… But the process ID returned by the Receive() function in the
receiving
process is, for one thing, not the process ID of the sender; secondly, a
process with that ID does NOT appear in the list of currently running
processes, which can be displayed by issuing the sin command at the
command
prompt.”

Here is additional info that will hopefully clarify certain points:

  • The software is running on a single node. No QNX network/no other nodes.

-The sending process triggers a proxy to communicate with the receiving

Here is the problem. When you Trigger a proxy, Receive return the
id of the PROXY not of the process that send it. Proxy are not
really meant to send a message since the message is always the same.

process (i.e. in this specific case, I am not using the
Send()/Receive()/Reply() trio). In other words, “Trigger(pxy);” is used
and
the sending process has no clue about what the message represented by the
proxy, pxy, is. According to the principles of messaging-via-proxies (as
it
is the case with the other IPC schemes), it is the Kernel’s responsibility
to move the ‘canned message’ corresponding to pxy from the receiving
process’ canned-message buffer to its receive buffer and to tell the
receiver process the ID of the sender (of course, you already know that).

You have misinterpreted the doc, or the doc is fuzzy :wink:


Now, the sending process’ symbolic name and ID can be viewed on the
console
(using the sin command) but the code prints out the sender’s ID as a few
numbers off the actual ID of the sending process. That is, if the sending
process’ ID is, say 567, the proxy gets triggered by process 568 (or
569…
the largest difference I have noticed so far was 20, and that, when the
actual sender’s process ID was a 4 digit number - no consistent pattern
occurs here). The funny thing is, 568 (or 569, or whatever that number may
be) is not displayed on the console when the sin command is issued.

If you’d run sin proxy you would see the number 568 belong to a proxy !

-There are no user defined interrut handlers.


“Orhan Ozdengiz” <> ozdengiz@axion.net> > wrote in message
news:94o76h$m99$> 1@inn.qnx.com> …
Hi,

The system I am working on is a multitasking embedded system. The
Receive()
function that I am using in one of the processes does not return the
correct
process ID of the sender of some messages. I know which process is
sending
the messages, I also know the process ID and the symbolic name attached
to
that process, and I can see that data on the output screen of the QNX
sin
command when issued at the command prompt. But the process ID returned
by
the Receive() function in the receiving process is, for one thing, not
the
process ID of the sender; secondly, a process with that ID does appear
in
the list of currently running processes, which can be displayed by
issuing
the sin command at the command prompt.

Any comments?

Thank you.
\

8

Thank you very much Mario. Your remarks made me understand the situation.
Unfortunately, in the Library Reference of Watcom C/C++, which I am using,
the return value of the Receive() function is given only as the ID of the
sender process; there is no mention of the proxy ID in case the Trigger()
function is used.

Thanks again!

PS: Thanks to everybody who has shown an interest.

“Mario Charest” <mcharest@void_zinformatic.com> wrote in message
news:94q7ko$hig$1@nntp.qnx.com…

“Orhan Ozdengiz” <> ozdengiz@axion.net> > wrote in message
news:94q714$1lk$> 1@inn.qnx.com> …
Thank you for your interest.

I guess, I have to make the following correction to my original message:
I
missed a “not” there. The last sentence of my message should read as
follows:

“… But the process ID returned by the Receive() function in the
receiving
process is, for one thing, not the process ID of the sender; secondly, a
process with that ID does NOT appear in the list of currently running
processes, which can be displayed by issuing the sin command at the
command
prompt.”

Here is additional info that will hopefully clarify certain points:

  • The software is running on a single node. No QNX network/no other
    nodes.

-The sending process triggers a proxy to communicate with the receiving

Here is the problem. When you Trigger a proxy, Receive return the
id of the PROXY not of the process that send it. Proxy are not
really meant to send a message since the message is always the same.

process (i.e. in this specific case, I am not using the
Send()/Receive()/Reply() trio). In other words, “Trigger(pxy);” is used
and
the sending process has no clue about what the message represented by
the
proxy, pxy, is. According to the principles of messaging-via-proxies (as
it
is the case with the other IPC schemes), it is the Kernel’s
responsibility
to move the ‘canned message’ corresponding to pxy from the receiving
process’ canned-message buffer to its receive buffer and to tell the
receiver process the ID of the sender (of course, you already know
that).

You have misinterpreted the doc, or the doc is fuzzy > :wink:


Now, the sending process’ symbolic name and ID can be viewed on the
console
(using the sin command) but the code prints out the sender’s ID as a few
numbers off the actual ID of the sending process. That is, if the
sending
process’ ID is, say 567, the proxy gets triggered by process 568 (or
569…
the largest difference I have noticed so far was 20, and that, when the
actual sender’s process ID was a 4 digit number - no consistent pattern
occurs here). The funny thing is, 568 (or 569, or whatever that number
may
be) is not displayed on the console when the sin command is issued.


If you’d run sin proxy you would see the number 568 belong to a proxy !

-There are no user defined interrut handlers.


“Orhan Ozdengiz” <> ozdengiz@axion.net> > wrote in message
news:94o76h$m99$> 1@inn.qnx.com> …
Hi,

The system I am working on is a multitasking embedded system. The
Receive()
function that I am using in one of the processes does not return the
correct
process ID of the sender of some messages. I know which process is
sending
the messages, I also know the process ID and the symbolic name
attached
to
that process, and I can see that data on the output screen of the QNX
sin
command when issued at the command prompt. But the process ID returned
by
the Receive() function in the receiving process is, for one thing, not
the
process ID of the sender; secondly, a process with that ID does appear
in
the list of currently running processes, which can be displayed by
issuing
the sin command at the command prompt.

Any comments?

Thank you.


\

9

“Orhan Ozdengiz” <ozdengiz@axion.net> wrote in message
news:94tavr$sfu$1@inn.qnx.com…

Thank you very much Mario. Your remarks made me understand the situation.
Unfortunately, in the Library Reference of Watcom C/C++, which I am using,
the return value of the Receive() function is given only as the ID of the
sender process; there is no mention of the proxy ID in case the Trigger()
function is used.

To my own surprise, I have to agree with you. The doc is not clear about
that
at all.

Any doc people reading this?

Thanks again!

PS: Thanks to everybody who has shown an interest.

“Mario Charest” <mcharest@void_zinformatic.com> wrote in message
news:94q7ko$hig$> 1@nntp.qnx.com> …

“Orhan Ozdengiz” <> ozdengiz@axion.net> > wrote in message
news:94q714$1lk$> 1@inn.qnx.com> …
Thank you for your interest.

I guess, I have to make the following correction to my original
message:
I
missed a “not” there. The last sentence of my message should read as
follows:

“… But the process ID returned by the Receive() function in the
receiving
process is, for one thing, not the process ID of the sender; secondly,
a
process with that ID does NOT appear in the list of currently running
processes, which can be displayed by issuing the sin command at the
command
prompt.”

Here is additional info that will hopefully clarify certain points:

  • The software is running on a single node. No QNX network/no other
    nodes.

-The sending process triggers a proxy to communicate with the
receiving

Here is the problem. When you Trigger a proxy, Receive return the
id of the PROXY not of the process that send it. Proxy are not
really meant to send a message since the message is always the same.

process (i.e. in this specific case, I am not using the
Send()/Receive()/Reply() trio). In other words, “Trigger(pxy);” is
used
and
the sending process has no clue about what the message represented by
the
proxy, pxy, is. According to the principles of messaging-via-proxies
(as
it
is the case with the other IPC schemes), it is the Kernel’s
responsibility
to move the ‘canned message’ corresponding to pxy from the receiving
process’ canned-message buffer to its receive buffer and to tell the
receiver process the ID of the sender (of course, you already know
that).

You have misinterpreted the doc, or the doc is fuzzy > :wink:


Now, the sending process’ symbolic name and ID can be viewed on the
console
(using the sin command) but the code prints out the sender’s ID as a
few
numbers off the actual ID of the sending process. That is, if the
sending
process’ ID is, say 567, the proxy gets triggered by process 568 (or
569…
the largest difference I have noticed so far was 20, and that, when
the
actual sender’s process ID was a 4 digit number - no consistent
pattern
occurs here). The funny thing is, 568 (or 569, or whatever that number
may
be) is not displayed on the console when the sin command is issued.


If you’d run sin proxy you would see the number 568 belong to a proxy !

-There are no user defined interrut handlers.


“Orhan Ozdengiz” <> ozdengiz@axion.net> > wrote in message
news:94o76h$m99$> 1@inn.qnx.com> …
Hi,

The system I am working on is a multitasking embedded system. The
Receive()
function that I am using in one of the processes does not return the
correct
process ID of the sender of some messages. I know which process is
sending
the messages, I also know the process ID and the symbolic name
attached
to
that process, and I can see that data on the output screen of the
QNX
sin
command when issued at the command prompt. But the process ID
returned
by
the Receive() function in the receiving process is, for one thing,
not
the
process ID of the sender; secondly, a process with that ID does
appear
in
the list of currently running processes, which can be displayed by
issuing
the sin command at the command prompt.

Any comments?

Thank you.




\

10

My guess is that you are sending messages over a network.
Two different machines don’t share the same ID space, so in
this circumstance a VC (Virtual Circuit) is setup. There are
psuedo ID’s (VID’s) on either side. To find some details,
try “sin vc”.

The Virtual ID you get, is the correct ID to reply to. It
is possible to figure out the actual PID from the VID.


Previously, Orhan Ozdengiz wrote in qdn.public.qnx4:

Hi,

The system I am working on is a multitasking embedded system. The Receive()
function that I am using in one of the processes does not return the correct
process ID of the sender of some messages. I know which process is sending
the messages, I also know the process ID and the symbolic name attached to
that process, and I can see that data on the output screen of the QNX sin
command when issued at the command prompt. But the process ID returned by
the Receive() function in the receiving process is, for one thing, not the
process ID of the sender; secondly, a process with that ID does appear in
the list of currently running processes, which can be displayed by issuing
the sin command at the command prompt.

Any comments?

Thank you.
\

–
Mitchell Schoenbrun --------- maschoen@pobox.com

11

Mario Charest <mcharest@void_zinformatic.com> wrote:

: “Orhan Ozdengiz” <ozdengiz@axion.net> wrote in message
: news:94tavr$sfu$1@inn.qnx.com…
:> Thank you very much Mario. Your remarks made me understand the situation.
:> Unfortunately, in the Library Reference of Watcom C/C++, which I am using,
:> the return value of the Receive() function is given only as the ID of the
:> sender process; there is no mention of the proxy ID in case the Trigger()
:> function is used.

: To my own surprise, I have to agree with you. The doc is not clear about
: that
: at all.

: Any doc people reading this?

Yes. I’ll fix the docs – thanks.

Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems