SIGSEGV on Mqueue 4.24A with long messages

I am using Mqueue ver 4.24A, date Aug 30, 1999 which I believe to be the
latest recognised version (see other postings for discussions on the
versions of Mqueue kicking around). I have just spent some time chasing
a problem which turned out to be sending a message longer than the
message size for which the queue was created. The problem was, instead
of rejecting the call, Mqueue SIGSEGVs, variously at either 5:000000A7,
or 5:0000328D. Not very friendly.

Has anybody else had this problem? Obviously the workaround is not to do
it, but sometimes it takes a while to get the bugs out…

I have seen mq-send return EMSGSIZE (msg_len is greater than the msgsize of
the mqueue) when I tried to send a message larger than the mqueue was setup
for but I have not seen Mqueue SIGSEGV. If you have test code post it and I
will try it on my system. I use mqueues heavily.

I use the Dec 1999 CD which is the 4.24A version of Mqueue you are using. I
do not know if QNX has released anything else (ignoring the 4.24B mistake).

KenR

Donald Backstrom wrote:

I am using Mqueue ver 4.24A, date Aug 30, 1999 which I believe to be the
latest recognised version (see other postings for discussions on the
versions of Mqueue kicking around). I have just spent some time chasing
a problem which turned out to be sending a message longer than the
message size for which the queue was created. The problem was, instead
of rejecting the call, Mqueue SIGSEGVs, variously at either 5:000000A7,
or 5:0000328D. Not very friendly.

Has anybody else had this problem? Obviously the workaround is not to do
it, but sometimes it takes a while to get the bugs out…

How does that saying go… “If it hurts, don’t do it!” :slight_smile:

Seriously,

I’ve seen this problem but it was about 4 years ago on an older version
and was supposed to be fixed.

I had a queue defined at 128 bytes and was shoving a 172 byte structure
into it (structure grew, not everything used sizeof()). The message got
passed
intact without corruption but upon all processes closing the queue and
issuing
an ‘rm /dev/mqueue/status_queue’ Mqueue would sigsegv.

It took a long time to find that one. If memory serves I had to get
enough
messages in to wrap the “limit” at least once (ie 64 128 byte messages, I
had to write at least 65 messages had to process through the queue).

I know this isn’t any help - but your not alone.

Jay Hogg

Donald Backstrom wrote in message <3A552B4B.85D6BDFF@cstgroup.com.au>…

I am using Mqueue ver 4.24A, date Aug 30, 1999 which I believe to be the
latest recognised version (see other postings for discussions on the
versions of Mqueue kicking around). I have just spent some time chasing
a problem which turned out to be sending a message longer than the
message size for which the queue was created. The problem was, instead
of rejecting the call, Mqueue SIGSEGVs, variously at either 5:000000A7,
or 5:0000328D. Not very friendly.

Has anybody else had this problem? Obviously the workaround is not to do
it, but sometimes it takes a while to get the bugs out…

Unfortunately, the path that fails goes through a series of about 4 mq_sends
between various processes in a ring before the final process replies to the
first one. It was the reply that fails (because I was stuffing up the message
type somewhere in the loop) and was sending too many bytes. When I simplify it,
the crash doesn’t occurr, and also if I put enought things in the debugger, I
will often get the EMSGSIZE return so I suspect it is related to what else is
going on inside Mqueue at the time.

If I come up with something simple that can reproduce it, I’ll post it. At the
moment it requires NT boxes to talk to as well as QNX so I just don’t think it
is worth the effort until I get something simpler.

Thanks for the reply.

p.s. Mqueues are fun - we have been using them for only about 6 months and they
solve a lot of problems in distributed systems using Send/Receive/Reply
especially when the network is dodgy or nodes come and go. They force a bit of a
different mindset though. It would appear though that they are a bit late on the
scene in QNX terms. Any other gotchas that you have noticed? The bad version was
a shocker and removing it solved a lot of problems. I imagine sinice it is POSIX
that they exist in the RTP - do you have any experience with them there?

rectech wrote:

I have seen mq-send return EMSGSIZE (msg_len is greater than the msgsize of
the mqueue) when I tried to send a message larger than the mqueue was setup
for but I have not seen Mqueue SIGSEGV. If you have test code post it and I
will try it on my system. I use mqueues heavily.

I use the Dec 1999 CD which is the 4.24A version of Mqueue you are using. I
do not know if QNX has released anything else (ignoring the 4.24B mistake).

KenR

Donald Backstrom wrote:

I am using Mqueue ver 4.24A, date Aug 30, 1999 which I believe to be the
latest recognised version (see other postings for discussions on the
versions of Mqueue kicking around). I have just spent some time chasing
a problem which turned out to be sending a message longer than the
message size for which the queue was created. The problem was, instead
of rejecting the call, Mqueue SIGSEGVs, variously at either 5:000000A7,
or 5:0000328D. Not very friendly.

Has anybody else had this problem? Obviously the workaround is not to do
it, but sometimes it takes a while to get the bugs out…

Other than the version issue I haven’t had any problems with mqueues. I’ll be
trying them under QRTP next month so I don’t have any experience in that area yet.

The only other things I can think of:

  • there is a small period where the mq_send is blocked waiting for Mqueue to finish
    some processing,
  • the mqueues show up in /dev/mqueue and ls -l will show you how many are still in
    the mqueue,
  • if the mqueue messages are printable then cat /dev/mqueue/ can be
    useful,
  • on a network you only need one Mqueue running,

KenR

Donald Backstrom wrote:

Unfortunately, the path that fails goes through a series of about 4 mq_sends
between various processes in a ring before the final process replies to the
first one. It was the reply that fails (because I was stuffing up the message
type somewhere in the loop) and was sending too many bytes. When I simplify it,
the crash doesn’t occurr, and also if I put enought things in the debugger, I
will often get the EMSGSIZE return so I suspect it is related to what else is
going on inside Mqueue at the time.

If I come up with something simple that can reproduce it, I’ll post it. At the
moment it requires NT boxes to talk to as well as QNX so I just don’t think it
is worth the effort until I get something simpler.

Thanks for the reply.

p.s. Mqueues are fun - we have been using them for only about 6 months and they
solve a lot of problems in distributed systems using Send/Receive/Reply
especially when the network is dodgy or nodes come and go. They force a bit of a
different mindset though. It would appear though that they are a bit late on the
scene in QNX terms. Any other gotchas that you have noticed? The bad version was
a shocker and removing it solved a lot of problems. I imagine sinice it is POSIX
that they exist in the RTP - do you have any experience with them there?

rectech wrote:

I have seen mq-send return EMSGSIZE (msg_len is greater than the msgsize of
the mqueue) when I tried to send a message larger than the mqueue was setup
for but I have not seen Mqueue SIGSEGV. If you have test code post it and I
will try it on my system. I use mqueues heavily.

I use the Dec 1999 CD which is the 4.24A version of Mqueue you are using. I
do not know if QNX has released anything else (ignoring the 4.24B mistake).

KenR

Donald Backstrom wrote:

I am using Mqueue ver 4.24A, date Aug 30, 1999 which I believe to be the
latest recognised version (see other postings for discussions on the
versions of Mqueue kicking around). I have just spent some time chasing
a problem which turned out to be sending a message longer than the
message size for which the queue was created. The problem was, instead
of rejecting the call, Mqueue SIGSEGVs, variously at either 5:000000A7,
or 5:0000328D. Not very friendly.

Has anybody else had this problem? Obviously the workaround is not to do
it, but sometimes it takes a while to get the bugs out…

rectech wrote in message <3A59E10A.E4BB87C1@iname.com>…

Other than the version issue I haven’t had any problems with mqueues. I’ll
be
trying them under QRTP next month so I don’t have any experience in that
area yet.

The only other things I can think of:

  • there is a small period where the mq_send is blocked waiting for Mqueue
    to finish
    some processing,
  • the mqueues show up in /dev/mqueue and ls -l will show you how many are
    still in
    the mqueue,
  • if the mqueue messages are printable then cat /dev/mqueue/<mqueue name
    can be
    useful,
  • on a network you only need one Mqueue running,

You will find that most of the QNX “regulars” have written their own
queueing
systems using the same general concept but with some added features (
some ala qnx2):

  • Statistics gathering (How can you judge performance without it??)
  • Broadcast to all readers vs Next reader
  • Special handling for distributed networks
  • Better handling of memory
  • Better performance (shared memory based queuing)

From original discussions, Mqueue is “late” because it really isn’t part of
QNX but was provided for porting of POSIX applications that use it. The
original author(s) stated long ago (QUICS thread) that Mqueue (on QNX4)
was designed for legacy code and wasn’t targeted at new development.

Jay


KenR

Donald Backstrom wrote:

Unfortunately, the path that fails goes through a series of about 4
mq_sends
between various processes in a ring before the final process replies to
the
first one. It was the reply that fails (because I was stuffing up the
message
type somewhere in the loop) and was sending too many bytes. When I
simplify it,
the crash doesn’t occurr, and also if I put enought things in the
debugger, I
will often get the EMSGSIZE return so I suspect it is related to what
else is
going on inside Mqueue at the time.

If I come up with something simple that can reproduce it, I’ll post it.
At the
moment it requires NT boxes to talk to as well as QNX so I just don’t
think it
is worth the effort until I get something simpler.

Thanks for the reply.

p.s. Mqueues are fun - we have been using them for only about 6 months
and they
solve a lot of problems in distributed systems using Send/Receive/Reply
especially when the network is dodgy or nodes come and go. They force a
bit of a
different mindset though. It would appear though that they are a bit late
on the
scene in QNX terms. Any other gotchas that you have noticed? The bad
version was
a shocker and removing it solved a lot of problems. I imagine sinice it
is POSIX
that they exist in the RTP - do you have any experience with them there?

rectech wrote:

I have seen mq-send return EMSGSIZE (msg_len is greater than the
msgsize of
the mqueue) when I tried to send a message larger than the mqueue was
setup
for but I have not seen Mqueue SIGSEGV. If you have test code post it
and I
will try it on my system. I use mqueues heavily.

I use the Dec 1999 CD which is the 4.24A version of Mqueue you are
using. I
do not know if QNX has released anything else (ignoring the 4.24B
mistake).

KenR

Donald Backstrom wrote:

I am using Mqueue ver 4.24A, date Aug 30, 1999 which I believe to be
the
latest recognised version (see other postings for discussions on the
versions of Mqueue kicking around). I have just spent some time
chasing
a problem which turned out to be sending a message longer than the
message size for which the queue was created. The problem was,
instead
of rejecting the call, Mqueue SIGSEGVs, variously at either
5:000000A7,
or 5:0000328D. Not very friendly.

Has anybody else had this problem? Obviously the workaround is not to
do
it, but sometimes it takes a while to get the bugs out…

Jay Hogg wrote:

From original discussions, Mqueue is “late” because it really isn’t part of
QNX but was provided for porting of POSIX applications that use it. The
original author(s) stated long ago (QUICS thread) that Mqueue (on QNX4)
was designed for legacy code and wasn’t targeted at new development.

I was told to use it for a new development project (before QRTP). What should
one use now for QNX 4.2x?