Why does "sin" kill programs?

huo1 · June 20, 2005, 5:49pm

I have posted the problem months ago in a separate group but I never
got any good answers.

Here is the problem again.

If I run “sin” as a normal user, it would kill any “dittoed”
sessions, which can be either from Phindows or from “phditto”. It
would also kill some of my programs.
If I run “sin” as root, it would spare the ditto sessions, but it
would still kill my programs.

I tried to capture the signal using gdb. My program seems to be
getting SIGABRT. Trapping the signal does not seem to help much. My
programs still get killed eventually.

I don’t need “sin” for normal operation. But it is very useful
sometimes for debugging. For example, right now I am trying to find
out whether I have file descriptor leaks. “sin fds” would have
provided useful information. But every time I tried to run it, it
kills the program I’m trying to debug.

This seemed to be new for QNX 6.3. The new patch, 6.31, did not fix
it. I wonder if anyone has figured out a solution for the problem.

Thanks

Shouqin Huo

Rennie_Allen2 · June 20, 2005, 6:17pm

huo@qm.com wrote:

I have posted the problem months ago in a separate group but I never
got any good answers.

Here is the problem again.

If I run “sin” as a normal user, it would kill any “dittoed”
sessions, which can be either from Phindows or from “phditto”. It
would also kill some of my programs.

If I run “sin” as root, it would spare the ditto sessions, but it
would still kill my programs.

I tried to capture the signal using gdb. My program seems to be
getting SIGABRT. Trapping the signal does not seem to help much. My
programs still get killed eventually.

I don’t need “sin” for normal operation. But it is very useful
sometimes for debugging. For example, right now I am trying to find
out whether I have file descriptor leaks. “sin fds” would have
provided useful information. But every time I tried to run it, it
kills the program I’m trying to debug.

This seemed to be new for QNX 6.3. The new patch, 6.31, did not fix
it. I wonder if anyone has figured out a solution for the problem.

Sounds like the application in question mounts a prefix into the
namespace, and doesn’t handle some of the standard I/O messages that
“sin fds” sends to all prefixes. Since the problem is SIGABRT, I would
look for assertions, or if you developed with C++ some unhandled
exceptions…

Rennie

Mario_Charest1 · June 20, 2005, 6:54pm

“Rennie Allen” <rallen@csical.com> wrote in message
news:42B70828.8010109@csical.com…

huo@qm.com > wrote:
I have posted the problem months ago in a separate group but I never
got any good answers.

Here is the problem again. * If I run “sin” as a normal user, it would
kill any “dittoed”
sessions, which can be either from Phindows or from “phditto”. It
would also kill some of my programs.

This should be fixed in the next patch (SP2)

huo1 · June 21, 2005, 3:49pm

Mario Charestwrote:
“Rennie Allen” <> rallen@csical.com> > wrote in message
news:> 42B70828.8010109@csical.com> …
huo@qm.com > wrote:
I have posted the problem months ago in a separate group but I
never
got any good answers.

Here is the problem again. * If I run “sin” as a normal user, it
would
kill any “dittoed”
sessions, which can be either from Phindows or from “phditto”. It
would also kill some of my programs.

This should be fixed in the next patch (SP2)[/quote:a1ea3d96ba]

Thanks for the information. I wonder if there is any temperary
solution.

Shouqin Huo

huo1 · June 21, 2005, 3:49pm

rgallenwrote:
huo@qm.com > wrote:
I have posted the problem months ago in a separate group but I
never
got any good answers.

Here is the problem again.

If I run “sin” as a normal user, it would kill any “dittoed”
sessions, which can be either from Phindows or from “phditto”. It
would also kill some of my programs.

If I run “sin” as root, it would spare the ditto sessions, but it
would still kill my programs.

I tried to capture the signal using gdb. My program seems to be
getting SIGABRT. Trapping the signal does not seem to help much. My
programs still get killed eventually.

I don’t need “sin” for normal operation. But it is very useful
sometimes for debugging. For example, right now I am trying to find
out whether I have file descriptor leaks. “sin fds” would have
provided useful information. But every time I tried to run it, it
kills the program I’m trying to debug.

This seemed to be new for QNX 6.3. The new patch, 6.31, did not fix
it. I wonder if anyone has figured out a solution for the problem.

Sounds like the application in question mounts a prefix into the

namespace, and doesn’t handle some of the standard I/O messages that
“sin fds” sends to all prefixes. Since the problem is SIGABRT, I
would
look for assertions, or if you developed with C++ some unhandled
exceptions…

Rennie[/quote:7f7c1ca2a9]

I also tried to reply to any unhandled message or pulse types with
MsgError(receiveId, -1). It did not help. I am not sure what you mean
by “prefix”. I do have a registered processing name for each program
(using name_open ).

Thanks for the information. If it becomes too much pain, I’ll wait for
the next qnx release, sp2?.

Colin_Burgess1 · June 21, 2005, 4:08pm

There is a workaround - run sin as root. The problem is caused by sin
failing to dup the filedescriptor due to a permission check. If you run
as root then the failure won’t happen…

huo@qm.com wrote:

Mario Charestwrote:

“Rennie Allen” <> rallen@csical.com> > wrote in message

news:> 42B70828.8010109@csical.com> …
huo@qm.com > wrote:
I have posted the problem months ago in a separate group but I

never

got any good answers.

Here is the problem again. * If I run “sin” as a normal user, it

would

kill any “dittoed”
sessions, which can be either from Phindows or from “phditto”. It
would also kill some of my programs.

This should be fixed in the next patch (SP2)[/quote:a1ea3d96ba]

Thanks for the information. I wonder if there is any temperary
solution.

Shouqin Huo

–
cburgess@qnx.com

huo1 · June 22, 2005, 1:49am

Colin Burgesswrote:
There is a workaround - run sin as root. The problem is caused by

sin

failing to dup the filedescriptor due to a permission check. If you
run
as root then the failure won’t happen…

This is partially true. As stated in my original post, running “sin”
as root does not kill “phrelay” but it still kills my programs. A
work around would be nice.

Colin_Burgess1 · June 22, 2005, 2:21am

If running sin as root is causing your app to quit, then I would check your dup handler.

sin will send an IO_DUP message to obtain a copy of the fd, then it will send an _IO_FDINFO message.
Lastly it will send an IO_CLOSE handler.

Do you have a close_dup handler working correctly? Remember that the dup’d fd shared the same ocb
as the original.

wrt gdb, I would put breakpoint on raise() - then you should get a backtrace. It looks like you might be calling assert() or abort().

huo@qm.com wrote:

Colin Burgesswrote:

There is a workaround - run sin as root. The problem is caused by
sin

failing to dup the filedescriptor due to a permission check. If you

run

as root then the failure won’t happen…

This is partially true. As stated in my original post, running “sin”
as root does not kill “phrelay” but it still kills my programs. A
work around would be nice.

–
cburgess@qnx.com

huo1 · June 23, 2005, 1:49am

Colin’s suggestion is very helpful. It made me going through the QNX
manual more carefully. The extra IO messages new to 6.3 are actually
documented and there is an example. After the os change from 6.2 to
6.3, I only added a line to handle _IO_CONNECT. The correct way to do
it is, according to the example, to reject or handle all IO messages
in the range _IO_BASE and _IO_MAX by MsgReply(rcvId, EOK,0,0). After
the change, I can run “sin fds” as root without killing all my
programs.

One of my programs has a graphical front end. It still dies if I run
“sin fds”. I tried to do similar thing but it did not seem to help.
There, I don’t have direct access to MsgReceive. I get the message
through a callback after the photon stuff has done its own things. I
am not sure if I can get the _IO messages.

Thanks for all your help. It is a big step forward although the
solution is not complete yet.

Shouqin Huo

system · June 24, 2005, 2:00am

huo@qm.com <huo@qm-dot-com.no-spam.invalid> wrote:

Colin’s suggestion is very helpful. It made me going through the QNX
manual more carefully. The extra IO messages new to 6.3 are actually
documented and there is an example. After the os change from 6.2 to
6.3, I only added a line to handle _IO_CONNECT. The correct way to do
it is, according to the example, to reject or handle all IO messages
in the range _IO_BASE and _IO_MAX by MsgReply(rcvId, EOK,0,0). After
the change, I can run “sin fds” as root without killing all my
programs.

Actually the safe approch would be, if it is in the range, AND, if
it is an _IO_CONNECT, reply with MsgReply(rcvid, EOK, 0, 0); otherwise,
reply with MsgError(rcvid, ENOSYS);

-xtang

huo1 · June 27, 2005, 9:48pm

After I did what xtang suggested, everything worked fine. My photon
application also stopped crashing. Replying every IO message except
_IO_CONNECT with MsgError(rcvid, ENOSYS) was the key.

Thank you all for the help.