Fork(), spawnv() and system() hang under QNX 6.2

QNX Newsgroups (Archives) qdn.public.porting
1

We have been having trouble with spawnv(), system(), and fork() on QNX 6.2.
The new child process would hang on startup and the execution of the parent
process is also blocked. We have oberved the similar behavior for all three
commands.

We wonder if any of you have any solutions available to the problem. We
tried these commands in small test programs and they all seem to work fine,
But they don’t work in the program we are trying to port from QNX 4.25.
Ocassionally, spawnv and system work but we have never got fork to work.
Using gdb we found they all hang in libc.so.2.

thanks

Shouqin Huo

Quantum Magnetics, Inc

huo@qm.com

2

There is quite a long thread in qdn.public.qnxrtp.os (spawnlp is Send
Blocked)
discussing this.

In general, all these calls will try to DUP open fds to their child. A VERY
COMMON
mistake is you did a ConnectAttach() without _NTO_SIDE_CHANNEL
before you spawn/fork. This put the returned coid into “opened fd” range,
and during spawn/fork(), the system try to DUP these coids and get blocked.

-xtang

Shouqin Huo <huo@qm.com> wrote in message news:avkjs4$60i$1@inn.qnx.com…

We have been having trouble with spawnv(), system(), and fork() on QNX
6.2.
The new child process would hang on startup and the execution of the
parent
process is also blocked. We have oberved the similar behavior for all
three
commands.

We wonder if any of you have any solutions available to the problem. We
tried these commands in small test programs and they all seem to work
fine,
But they don’t work in the program we are trying to port from QNX 4.25.
Ocassionally, spawnv and system work but we have never got fork to work.
Using gdb we found they all hang in libc.so.2.

thanks

Shouqin Huo

Quantum Magnetics, Inc

huo@qm.com

3

Thanks. This starts to make sense now.

Our problem is that we are using the name_attach/name_open mechanism to
establish links between processes. There does not seem to be a way to
specify the _NTO_SIDE_CHANNEL flag with name_attach.

– Shouqin Huo
“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:avklf6$3ce$1@nntp.qnx.com…

There is quite a long thread in qdn.public.qnxrtp.os (spawnlp is Send
Blocked)
discussing this.

In general, all these calls will try to DUP open fds to their child. A
VERY
COMMON
mistake is you did a ConnectAttach() without _NTO_SIDE_CHANNEL
before you spawn/fork. This put the returned coid into “opened fd” range,
and during spawn/fork(), the system try to DUP these coids and get
blocked.

-xtang

Shouqin Huo <> huo@qm.com> > wrote in message news:avkjs4$60i$> 1@inn.qnx.com> …
We have been having trouble with spawnv(), system(), and fork() on QNX
6.2.
The new child process would hang on startup and the execution of the
parent
process is also blocked. We have oberved the similar behavior for all
three
commands.

We wonder if any of you have any solutions available to the problem. We
tried these commands in small test programs and they all seem to work
fine,
But they don’t work in the program we are trying to port from QNX 4.25.
Ocassionally, spawnv and system work but we have never got fork to work.
Using gdb we found they all hang in libc.so.2.

thanks

Shouqin Huo

Quantum Magnetics, Inc

huo@qm.com

\

4

Shouqin Huo <huo@qm.com> wrote in message news:avkp2q$bhl$1@inn.qnx.com…

Thanks. This starts to make sense now.

Our problem is that we are using the name_attach/name_open mechanism to
establish links between processes. There does not seem to be a way to
specify the _NTO_SIDE_CHANNEL flag with name_attach.

_NTO_SIDE_CHANNEL is a ConnectAttach() flag, which in your case,
is done in name_open() be default. So, you probably have other connection.

-xtang

– Shouqin Huo
“Xiaodan Tang” <> xtang@qnx.com> > wrote in message
news:avklf6$3ce$> 1@nntp.qnx.com> …
There is quite a long thread in qdn.public.qnxrtp.os (spawnlp is Send
Blocked)
discussing this.

In general, all these calls will try to DUP open fds to their child. A
VERY
COMMON
mistake is you did a ConnectAttach() without _NTO_SIDE_CHANNEL
before you spawn/fork. This put the returned coid into “opened fd”
range,
and during spawn/fork(), the system try to DUP these coids and get
blocked.

-xtang

Shouqin Huo <> huo@qm.com> > wrote in message
news:avkjs4$60i$> 1@inn.qnx.com> …
We have been having trouble with spawnv(), system(), and fork() on QNX
6.2.
The new child process would hang on startup and the execution of the
parent
process is also blocked. We have oberved the similar behavior for all
three
commands.

We wonder if any of you have any solutions available to the problem.
We
tried these commands in small test programs and they all seem to work
fine,
But they don’t work in the program we are trying to port from QNX
4.25.
Ocassionally, spawnv and system work but we have never got fork to
work.
Using gdb we found they all hang in libc.so.2.

thanks

Shouqin Huo

Quantum Magnetics, Inc

huo@qm.com



\

5

Shouqin Huo <huo@qm.com> wrote:

Thanks. This starts to make sense now.

Our problem is that we are using the name_attach/name_open mechanism to
establish links between processes. There does not seem to be a way to
specify the _NTO_SIDE_CHANNEL flag with name_attach.

The name_open() will automatically set the _NTO_SIDE_CHANNEL index
parameter for its ConnectAttach() call.

For example, if I print out the coid returned by a name_open(), I get:
1073741825, which is 0x40000001 – the side channel range.

If I proceed to spawn from this, it works fine.

My test programs:

#include <stdio.h>
#include <errno.h>
#include <sys/iofunc.h>
#include <sys/dispatch.h>

int main()
{
int ret;
name_attach_t *attach;

attach = name_attach( NULL, “myname”, 0 );
if( NULL == attach )
{
printf(“failed 1st, errno %d\n”, errno );
}
else
{
printf(“succeeded first\n”);
}
sleep(5000);
}

#include <stdio.h>
#include <errno.h>
#include <process.h>
#include <sys/iofunc.h>
#include <sys/dispatch.h>

int main()
{
int ret;
int coid;

coid = name_open( “myname”, 0 );
if( coid == -1 )
{
printf(“failed, errno %d\n”, errno );
exit(0);
}
printf(“coid is %d, %x\n”, coid, coid );

ret = spawnl( P_NOWAIT, “/bin/echo”, “echo”, “hello there”, NULL );
printf(“spawn returned %d, errno %d\n”, ret, errno );
sleep(50);
}

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

6

David

thanks. I went through my code and made sure that every ConnectAttach is
called with the flag, _NTO_SIDE_CHANNEL and it started working. (I had a
timer that called ConnectAttach without the flag.)

Thanks again.

Shouqin Huo

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:avksng$7gj$1@nntp.qnx.com…

Shouqin Huo <> huo@qm.com> > wrote:
Thanks. This starts to make sense now.

Our problem is that we are using the name_attach/name_open mechanism to
establish links between processes. There does not seem to be a way to
specify the _NTO_SIDE_CHANNEL flag with name_attach.

The name_open() will automatically set the _NTO_SIDE_CHANNEL index
parameter for its ConnectAttach() call.

For example, if I print out the coid returned by a name_open(), I get:
1073741825, which is 0x40000001 – the side channel range.

If I proceed to spawn from this, it works fine.

My test programs:

#include <stdio.h
#include <errno.h
#include <sys/iofunc.h
#include <sys/dispatch.h

int main()
{
int ret;
name_attach_t *attach;

attach = name_attach( NULL, “myname”, 0 );
if( NULL == attach )
{
printf(“failed 1st, errno %d\n”, errno );
}
else
{
printf(“succeeded first\n”);
}
sleep(5000);
}

#include <stdio.h
#include <errno.h
#include <process.h
#include <sys/iofunc.h
#include <sys/dispatch.h

int main()
{
int ret;
int coid;

coid = name_open( “myname”, 0 );
if( coid == -1 )
{
printf(“failed, errno %d\n”, errno );
exit(0);
}
printf(“coid is %d, %x\n”, coid, coid );

ret = spawnl( P_NOWAIT, “/bin/echo”, “echo”, “hello there”, NULL );
printf(“spawn returned %d, errno %d\n”, ret, errno );
sleep(50);
}

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.