Hello,
I’m getting this errno error (Server fault on msg pass) on a MsgReplyv
call and I’m wondering what would cause this error to happen. I’ll give
alittle background. I have three of our own applications that are
running, and they send messages without a problem. As soon, as we
introduce the forth application, it causes the application that its
sending to, to error on a MsgReplyV from message from another process.
We are in the process of porting a number applications from qnx4 to
neutrino. The cause and effect of this problem seem completely unrelated.
I’m really looking for suggestions on how to narrow this problem down
and hopefully understand the nature of the problem better so that I can
more effectively troubleshoot it. Any suggestions would be greatly
appreciated.
Eric Norton
Eric Norton wrote:
Hello,
I’m getting this errno error (Server fault on msg pass) on a MsgReplyv
call and I’m wondering what would cause this error to happen. I’ll give
alittle background. I have three of our own applications that are
running, and they send messages without a problem. As soon, as we
introduce the forth application, it causes the application that its
sending to, to error on a MsgReplyV from message from another process.
We are in the process of porting a number applications from qnx4 to
neutrino. The cause and effect of this problem seem completely unrelated.
I’m really looking for suggestions on how to narrow this problem down
and hopefully understand the nature of the problem better so that I can
more effectively troubleshoot it. Any suggestions would be greatly
appreciated.
Eric Norton
ESRVRFAULT means the server faulted (the one doing the reply is the
server) during the message pass. You passed a list of memory to the
kernel, and essentially ellicited a segmentation violation (SIGSEGV)
during the message pass. The usual cause is that the some or all of the
memory referenced in the IOV list isn’t legitamite memory (ie. already
free’d, never allocated, etc) or became unmapped.
Eric Norton <enorton_nospam@nospam_fct.ca> wrote:
Hello,
I’m getting this errno error (Server fault on msg pass) on a MsgReplyv
call and I’m wondering what would cause this error to happen.
Usually this means that there was an invalid pointer dereferenced
by the kernel in evaluation/processing the reply msg/iov, and
it traps the fault, and fails the MsgReply[v] with this error.
So, this means verify that the iov point/array is valid, and that
all the memory it refers to (address, for length bytes) for every
iov that you’ve claimed is valid (niov parameter) is valid.
-David
David Gibbs
QNX Training Services
dagibbs@qnx.com
Adam Mallory wrote:
ESRVRFAULT means the server faulted (the one doing the reply is the
server) during the message pass. You passed a list of memory to the
kernel, and essentially ellicited a segmentation violation (SIGSEGV)
during the message pass. The usual cause is that the some or all of the
memory referenced in the IOV list isn’t legitamite memory (ie. already
free’d, never allocated, etc) or became unmapped.
Or the pointer points to less memory than the length you specified,
perhaps because you made a mistake when calculating the length.
You can try puting a little loop just above the MsgReply call that tries
to read each byte of the reply buffer, based on the iov array you’re
about to pass to MsgReplyv. It should cause a SIGSEGV. And by looking
at the state of things under the debugger, you will be able to find out
which part of the reply was set up incorrectly.
Wojtek Lerch wrote:
Or the pointer points to less memory than the length you specified,
perhaps because you made a mistake when calculating the length.
Would that not constitute memory which “isn’t legitimate memory”
–
Cheers,
Adam
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
Adam Mallory wrote:
Wojtek Lerch wrote:
Or the pointer points to less memory than the length you specified,
perhaps because you made a mistake when calculating the length.
Would that not constitute memory which “isn’t legitimate memory”
Yes, I meant the “or” as adding to your list in the parentheses
(“already free’d, never allocated, etc”). Of course, I wasn’t really
adding anything new, since the “etc” part covered it already. 
Adam Mallory wrote:
Eric Norton wrote:
Hello,
I’m getting this errno error (Server fault on msg pass) on a MsgReplyv
call and I’m wondering what would cause this error to happen. I’ll
give alittle background. I have three of our own applications that are
running, and they send messages without a problem. As soon, as we
introduce the forth application, it causes the application that its
sending to, to error on a MsgReplyV from message from another process.
We are in the process of porting a number applications from qnx4 to
neutrino. The cause and effect of this problem seem completely unrelated.
I’m really looking for suggestions on how to narrow this problem down
and hopefully understand the nature of the problem better so that I
can more effectively troubleshoot it. Any suggestions would be greatly
appreciated.
Eric Norton
ESRVRFAULT means the server faulted (the one doing the reply is the
server) during the message pass. You passed a list of memory to the
kernel, and essentially ellicited a segmentation violation (SIGSEGV)
during the message pass. The usual cause is that the some or all of the
memory referenced in the IOV list isn’t legitamite memory (ie. already
free’d, never allocated, etc) or became unmapped.
Thanks Guys, I’m still trying to debug my problem but this will help.
David Gibbs wrote:
Eric Norton <enorton_nospam@nospam_fct.ca> wrote:
Hello,
I’m getting this errno error (Server fault on msg pass) on a MsgReplyv
call and I’m wondering what would cause this error to happen.
Usually this means that there was an invalid pointer dereferenced
by the kernel in evaluation/processing the reply msg/iov, and
it traps the fault, and fails the MsgReply[v] with this error.
So, this means verify that the iov point/array is valid, and that
all the memory it refers to (address, for length bytes) for every
iov that you’ve claimed is valid (niov parameter) is valid.
-David
So, I found the bug and it was exactly as you guys had said. I was
sending in the incorrect number of nparts into the MsgSendv. Now, since
I’m porting code, I looked back and noticed the same bug in our QNX4
code with our call to Replymx. I’m wondering why it didn’t represent
itself until now. I’m curious as to whether the Replymx was doing some
error checking that doesn’t happen now, i.e. it knows that you only
passed in X number of parts, even though you specified you sent in Y to
the function.
Thanks,
Eric
Eric Norton <enorton_nospam@nospam_fct.ca> wrote:
David Gibbs wrote:
So, I found the bug and it was exactly as you guys had said. I was
sending in the incorrect number of nparts into the MsgSendv. Now, since
I’m porting code, I looked back and noticed the same bug in our QNX4
code with our call to Replymx. I’m wondering why it didn’t represent
itself until now. I’m curious as to whether the Replymx was doing some
error checking that doesn’t happen now, i.e. it knows that you only
passed in X number of parts, even though you specified you sent in Y to
the function.
QNX4 had the same checking, same error. Likely either the memory
for the extra mx entries was valid, or the “extra data” pointed to
by the (garbage) mx entreis happened to be at valid address space
in your QNX4 process, but with the different in-memory layout of
a QNX6 process, it didn’t happen to be valid.
It’s like asking… I dereferenced a garbage pointer before, and
it didn’t crash – now I’ve changed os/library/something, and
deferencing a garbage pointer crashes… why didn’t it crash before?
-David
David Gibbs
QNX Training Services
dagibbs@qnx.com
David Gibbs wrote:
Eric Norton <enorton_nospam@nospam_fct.ca> wrote:
David Gibbs wrote:
So, I found the bug and it was exactly as you guys had said. I was
sending in the incorrect number of nparts into the MsgSendv. Now, since
I’m porting code, I looked back and noticed the same bug in our QNX4
code with our call to Replymx. I’m wondering why it didn’t represent
itself until now. I’m curious as to whether the Replymx was doing some
error checking that doesn’t happen now, i.e. it knows that you only
passed in X number of parts, even though you specified you sent in Y to
the function.
QNX4 had the same checking, same error. Likely either the memory
for the extra mx entries was valid, or the “extra data” pointed to
by the (garbage) mx entreis happened to be at valid address space
in your QNX4 process, but with the different in-memory layout of
a QNX6 process, it didn’t happen to be valid.
I’m not quite sure how it works under QNX4, but does a QNX4 process once
compiled, always use the same virtual memory addresses everytime it
runs? If so, then I can understand your statement above and it makes
sense to me.
Eric
Eric Norton <enorton_nospam@nospam_fct.ca> wrote:
David Gibbs wrote:
Eric Norton <enorton_nospam@nospam_fct.ca> wrote:
David Gibbs wrote:
QNX4 had the same checking, same error. Likely either the memory
for the extra mx entries was valid, or the “extra data” pointed to
by the (garbage) mx entreis happened to be at valid address space
in your QNX4 process, but with the different in-memory layout of
a QNX6 process, it didn’t happen to be valid.
I’m not quite sure how it works under QNX4, but does a QNX4 process once
compiled, always use the same virtual memory addresses everytime it
runs? If so, then I can understand your statement above and it makes
sense to me.
Yes, the in-memory layout everytime it runs will generally be the same.
(Same is true for QNX6 processes.) Of course, by this I mean all functions,
all static data, etc – allocation results will come from the same address
range, but if the allocation order changes (perhaps driven by different
system behaviour) the placement of allocated data can change.
-David
David Gibbs
QNX Training Services
dagibbs@qnx.com