MsgSendPulse blocked in NET_REPLY state

QNX Newsgroups (Archives) qnx.rtos
1

I’ve encountered a strange deadlock in the application.

After looking closer I’ve noticed that a thread holding a mutex is blocked
on a MsgSendPulse_r() when sending a pulse to a channel on another node. It
had been blocked for more than 12 hours, though documentation says it a
non-blocking call.

When I tried to cut a coredump of io-net, the node went down.

Please look at information below:

  1. Thread #5 is blocked with state NET_REPLY.
  2. It sends a pulse to fd #10, which points to process #94228 on node #48,
    though pidin net shows there is no such node. Why don’t we get an error,
    ESRCH, in this case?
  3. sin -p 3018784 fds cannot extract any information aboyt fd #10 (which
    is not strange, because it asks the server to provide this information, and
    the server no longer exists)

Can you explain why the connection was not closed and why no error code was
returned and the thread was blocked instead?

This all applies to QNX 6.3, QNet lite.
I will try to reproduce the situation.

Thank you,
Roman

\

pidin -p 3018784

pid tid name prio STATE Blocked
3018784 1 …/bin/player.bin 10o CONDVAR 816eb54
3018784 2 …/bin/player.bin 10o CONDVAR 8116da4
3018784 3 …/bin/player.bin 5o READY
3018784 4 …/bin/player.bin 10o CONDVAR 811d084
3018784 5 …/bin/player.bin 50o NET_REPLY
3018784 6 …/bin/player.bin 21o RECEIVE 3
3018784 7 …/bin/player.bin 10o CONDVAR 816eb8c
3018784 8 …/bin/player.bin 10o RECEIVE 12
3018784 9 …/bin/player.bin 10o CONDVAR 816e764
3018784 10 …/bin/player.bin 10o CONDVAR 816e844
3018784 11 …/bin/player.bin 10o MUTEX 3018784-14 #1
3018784 12 …/bin/player.bin 10o CONDVAR 816ea3c
3018784 13 …/bin/player.bin 10o CONDVAR 818d9b4
3018784 14 …/bin/player.bin 10o MUTEX 3018784-05 #1
3018784 15 …/bin/player.bin 10o CONDVAR 8189ce4
3018784 16 …/bin/player.bin 10o CONDVAR 819500c
3018784 17 …/bin/player.bin 10o MUTEX 3018784-14 #1
3018784 18 …/bin/player.bin 10o CONDVAR 818118c
3018784 19 …/bin/player.bin 10o MUTEX 3018784-14 #1

================================================================

$2 = {client = {fd = 10,
handler = 0x80a08fc <CAsyncEntry::AsyncIOHandler(int, ECALLBACKTYPE,
void *)>, ct = CALLBACKTYPE_NONE, param = 0x818b888},
server = {nd = 48, pid = 94228}}

================================================================

sin -p 3018784 fds

player.bin 3018784 776K 628K 124K 2894K 618626
0 167945 WR 0/0 /net/dart.eleks.com/dev/ttyp4
1 167945 WR 0/0 /net/dart.eleks.com/dev/ttyp4
2 167945 WR 0/0 /net/dart.eleks.com/dev/ttyp4
3 3018783 W_ 0/0 /zzzzz/dev/play.100/data/Global/
4 3018783 R 0/40 /zzzzz/dev/play.100/data/Command/
5 3018783 W 0/0 /zzzzz/dev/play.100/data/Command/
6 3018782 R 0/0 /zzzzz/dev/play.100/etc/
7 3018783 W 0/0 /zzzzz/dev/play.100/data/sub_1/
8 3018783 _R 0/0 /zzzzz/dev/play.100/data/sub_1/
9 3018786 R 0/0 /zzzzz/dev/axis.100/data/Monitor/
10 94228
11 3018783 W 0/0 /zzzzz/dev/play.100/data/sub_2/
12 3018783 R 0/0 /zzzzz/dev/play.100/data/sub_2/
13 3018783 W 0/0 /zzzzz/dev/play.100/data/sub_3/
14 3018783 R 0/0 /zzzzz/dev/play.100/data/sub_3/
15 3018789 R 0/0 /zzzzz/dev/port.100/data/Monitor/
16 3018783 W 0/0 /zzzzz/dev/play.100/data/sub_4/
17 3018783 R 0/0 /zzzzz/dev/play.100/data/sub_4/
18 3018783 W 0/0 /zzzzz/dev/play.100/data/sub_5/
19 3018783 R 0/0 /zzzzz/dev/play.100/data/sub_5/
20 3018783 W 0/0 /zzzzz/dev/play.100/data/Monitor/
21 3018786 W 0/0 /zzzzz/dev/axis.100/data/Command/
22 3018786 _R 0/0 /zzzzz/dev/axis.100/data/Monitor/
0s 1
1s 69642
4s 1 __ 0/-1 /zzzzz/mon/procinfo/data/3018784/procinfo
5s 1 __ 0/-1
/zzzzz/mon/procinfo/data/play.100/PLAYER/procinfo
6s 1 __ 0/-1
/zzzzz/mon/procinfo/data/3018784/threadinfo
7s 1 __ 0/-1
/zzzzz/mon/procinfo/data/play.100/PLAYER/threadinfo
8s 1 __ 0/-1
/zzzzz/mon/procinfo/data/3018784/threadtextinfo
9s 1 __ 0/-1
/zzzzz/mon/procinfo/data/play.100/PLAYER/threadtextinfo
10s 1 __ 0/-1 /zzzzz/mon/procinfo/data/3018784/logdata
11s 1 __ 0/-1
/zzzzz/mon/procinfo/data/play.100/PLAYER/logdata
13s 1 __ 0/-1 /zzzzz/dev/play.100/profiles/

==============================================================

pidin net

ND Node CPU Release FreeMem BootTime
0 console 1 X86 6.3.0 26Mb/123Mb May 18 12:48:26 EEST
2004
1 axis_sew 1 X86 6.3.0 92Mb/119Mb Jun 29 01:25:32 EEST
2004
2 axis_hitachi 1 X86 6.3.0 93Mb/119Mb Jun 29 01:26:33 EEST
2004
12 dart 1 X86 6.3.0 986Mb/1022Mb Jun 25 15:28:48 EEST
2004
34 test_srv 1 X86 6.3.0 86Mb/254Mb Jun 28 21:04:12 EEST
2004
477 axis_test_1 1 X86 6.3.0 95Mb/119Mb Jun 28 03:12:05 EEST
2004
497 axis_test_2 1 X86 6.3.0 89Mb/119Mb Jun 28 03:10:16 EEST
2004

==============================================================

2

Is this released 6.3.0 or is this one of the 6.3 beta? This sounds very like
a bug
of QNET that fixed in the 6.3.0 beta time period.

-xtang


Roman Pavluyk <john@eleks.lviv.ua> wrote in message
news:cbreeo$1pu$1@inn.qnx.com…

I’ve encountered a strange deadlock in the application.

After looking closer I’ve noticed that a thread holding a mutex is blocked
on a MsgSendPulse_r() when sending a pulse to a channel on another node.
It
had been blocked for more than 12 hours, though documentation says it a
non-blocking call.

When I tried to cut a coredump of io-net, the node went down.

Please look at information below:

  1. Thread #5 is blocked with state NET_REPLY.
  2. It sends a pulse to fd #10, which points to process #94228 on node #48,
    though pidin net shows there is no such node. Why don’t we get an error,
    ESRCH, in this case?
  3. sin -p 3018784 fds cannot extract any information aboyt fd #10 (which
    is not strange, because it asks the server to provide this information,
    and
    the server no longer exists)

Can you explain why the connection was not closed and why no error code
was
returned and the thread was blocked instead?

This all applies to QNX 6.3, QNet lite.
I will try to reproduce the situation.

Thank you,
Roman

\

pidin -p 3018784

pid tid name prio STATE Blocked
3018784 1 …/bin/player.bin 10o CONDVAR 816eb54
3018784 2 …/bin/player.bin 10o CONDVAR 8116da4
3018784 3 …/bin/player.bin 5o READY
3018784 4 …/bin/player.bin 10o CONDVAR 811d084
3018784 5 …/bin/player.bin 50o NET_REPLY
3018784 6 …/bin/player.bin 21o RECEIVE 3
3018784 7 …/bin/player.bin 10o CONDVAR 816eb8c
3018784 8 …/bin/player.bin 10o RECEIVE 12
3018784 9 …/bin/player.bin 10o CONDVAR 816e764
3018784 10 …/bin/player.bin 10o CONDVAR 816e844
3018784 11 …/bin/player.bin 10o MUTEX 3018784-14 #1
3018784 12 …/bin/player.bin 10o CONDVAR 816ea3c
3018784 13 …/bin/player.bin 10o CONDVAR 818d9b4
3018784 14 …/bin/player.bin 10o MUTEX 3018784-05 #1
3018784 15 …/bin/player.bin 10o CONDVAR 8189ce4
3018784 16 …/bin/player.bin 10o CONDVAR 819500c
3018784 17 …/bin/player.bin 10o MUTEX 3018784-14 #1
3018784 18 …/bin/player.bin 10o CONDVAR 818118c
3018784 19 …/bin/player.bin 10o MUTEX 3018784-14 #1

================================================================

$2 = {client = {fd = 10,
handler = 0x80a08fc <CAsyncEntry::AsyncIOHandler(int, ECALLBACKTYPE,
void *)>, ct = CALLBACKTYPE_NONE, param = 0x818b888},
server = {nd = 48, pid = 94228}}

================================================================

sin -p 3018784 fds

player.bin 3018784 776K 628K 124K 2894K
618626
0 167945 WR 0/0 /net/dart.eleks.com/dev/ttyp4
1 167945 WR 0/0 /net/dart.eleks.com/dev/ttyp4
2 167945 WR 0/0 /net/dart.eleks.com/dev/ttyp4
3 3018783 W_ 0/0 /zzzzz/dev/play.100/data/Global/
4 3018783 R 0/40 /zzzzz/dev/play.100/data/Command/
5 3018783 W 0/0 /zzzzz/dev/play.100/data/Command/
6 3018782 R 0/0 /zzzzz/dev/play.100/etc/
7 3018783 W 0/0 /zzzzz/dev/play.100/data/sub_1/
8 3018783 _R 0/0 /zzzzz/dev/play.100/data/sub_1/
9 3018786 R 0/0 /zzzzz/dev/axis.100/data/Monitor/
10 94228
11 3018783 W 0/0 /zzzzz/dev/play.100/data/sub_2/
12 3018783 R 0/0 /zzzzz/dev/play.100/data/sub_2/
13 3018783 W 0/0 /zzzzz/dev/play.100/data/sub_3/
14 3018783 R 0/0 /zzzzz/dev/play.100/data/sub_3/
15 3018789 R 0/0 /zzzzz/dev/port.100/data/Monitor/
16 3018783 W 0/0 /zzzzz/dev/play.100/data/sub_4/
17 3018783 R 0/0 /zzzzz/dev/play.100/data/sub_4/
18 3018783 W 0/0 /zzzzz/dev/play.100/data/sub_5/
19 3018783 R 0/0 /zzzzz/dev/play.100/data/sub_5/
20 3018783 W 0/0 /zzzzz/dev/play.100/data/Monitor/
21 3018786 W 0/0 /zzzzz/dev/axis.100/data/Command/
22 3018786 _R 0/0 /zzzzz/dev/axis.100/data/Monitor/
0s 1
1s 69642
4s 1 __ 0/-1
/zzzzz/mon/procinfo/data/3018784/procinfo
5s 1 __ 0/-1
/zzzzz/mon/procinfo/data/play.100/PLAYER/procinfo
6s 1 __ 0/-1
/zzzzz/mon/procinfo/data/3018784/threadinfo
7s 1 __ 0/-1
/zzzzz/mon/procinfo/data/play.100/PLAYER/threadinfo
8s 1 __ 0/-1
/zzzzz/mon/procinfo/data/3018784/threadtextinfo
9s 1 __ 0/-1
/zzzzz/mon/procinfo/data/play.100/PLAYER/threadtextinfo
10s 1 __ 0/-1
/zzzzz/mon/procinfo/data/3018784/logdata
11s 1 __ 0/-1
/zzzzz/mon/procinfo/data/play.100/PLAYER/logdata
13s 1 __ 0/-1 /zzzzz/dev/play.100/profiles/

==============================================================

pidin net

ND Node CPU Release FreeMem BootTime
0 console 1 X86 6.3.0 26Mb/123Mb May 18 12:48:26
EEST
2004
1 axis_sew 1 X86 6.3.0 92Mb/119Mb Jun 29 01:25:32
EEST
2004
2 axis_hitachi 1 X86 6.3.0 93Mb/119Mb Jun 29 01:26:33
EEST
2004
12 dart 1 X86 6.3.0 986Mb/1022Mb Jun 25 15:28:48
EEST
2004
34 test_srv 1 X86 6.3.0 86Mb/254Mb Jun 28 21:04:12
EEST
2004
477 axis_test_1 1 X86 6.3.0 95Mb/119Mb Jun 28 03:12:05
EEST
2004
497 axis_test_2 1 X86 6.3.0 89Mb/119Mb Jun 28 03:10:16
EEST
2004

==============================================================
\

3

Thank you very much for you answer.

It’s about beta, we’re getting 6.3 release these days.

I haven’t seen any information about fixing similar bug in RC release notes.
Can you point me to bug number, and, actually, a list of bugs fixed in QNet
between first beta and release? We observed some strange anomalities, and
it’d be nice to know that a bug has been fixed rather than to guess :slight_smile:

Robert Krten stressed similar issue in one of his postings – “get latest
version” is not a sufficient answer in many cases, customers want to know
what exactly was wrong and what exactly has been fixed, when a vendor tells
that a system has to be updated. This is industry requirement, not mine
personal, please understand :slight_smile: We faced this situation only once so far, and
this makes me worry about test coverage of the system. Who knows what other
bugs have not been encountered?

Thank you again for your answer,
Roman


“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:cbutn1$nj1$1@inn.qnx.com…

Is this released 6.3.0 or is this one of the 6.3 beta? This sounds very
like
a bug
of QNET that fixed in the 6.3.0 beta time period.

-xtang


Roman Pavluyk <> john@eleks.lviv.ua> > wrote in message
news:cbreeo$1pu$> 1@inn.qnx.com> …
I’ve encountered a strange deadlock in the application.

After looking closer I’ve noticed that a thread holding a mutex is
blocked
on a MsgSendPulse_r() when sending a pulse to a channel on another node.
It
had been blocked for more than 12 hours, though documentation says it a
non-blocking call.

When I tried to cut a coredump of io-net, the node went down.

Please look at information below:

  1. Thread #5 is blocked with state NET_REPLY.
  2. It sends a pulse to fd #10, which points to process #94228 on node
    #48,
    though pidin net shows there is no such node. Why don’t we get an
    error,
    ESRCH, in this case?
  3. sin -p 3018784 fds cannot extract any information aboyt fd #10
    (which
    is not strange, because it asks the server to provide this information,
    and
    the server no longer exists)

Can you explain why the connection was not closed and why no error code
was
returned and the thread was blocked instead?

This all applies to QNX 6.3, QNet lite.
I will try to reproduce the situation.

Thank you,
Roman

\

pidin -p 3018784

pid tid name prio STATE Blocked
3018784 1 …/bin/player.bin 10o CONDVAR 816eb54
3018784 2 …/bin/player.bin 10o CONDVAR 8116da4
3018784 3 …/bin/player.bin 5o READY
3018784 4 …/bin/player.bin 10o CONDVAR 811d084
3018784 5 …/bin/player.bin 50o NET_REPLY
3018784 6 …/bin/player.bin 21o RECEIVE 3
3018784 7 …/bin/player.bin 10o CONDVAR 816eb8c
3018784 8 …/bin/player.bin 10o RECEIVE 12
3018784 9 …/bin/player.bin 10o CONDVAR 816e764
3018784 10 …/bin/player.bin 10o CONDVAR 816e844
3018784 11 …/bin/player.bin 10o MUTEX 3018784-14 #1
3018784 12 …/bin/player.bin 10o CONDVAR 816ea3c
3018784 13 …/bin/player.bin 10o CONDVAR 818d9b4
3018784 14 …/bin/player.bin 10o MUTEX 3018784-05 #1
3018784 15 …/bin/player.bin 10o CONDVAR 8189ce4
3018784 16 …/bin/player.bin 10o CONDVAR 819500c
3018784 17 …/bin/player.bin 10o MUTEX 3018784-14 #1
3018784 18 …/bin/player.bin 10o CONDVAR 818118c
3018784 19 …/bin/player.bin 10o MUTEX 3018784-14 #1

================================================================

$2 = {client = {fd = 10,
handler = 0x80a08fc <CAsyncEntry::AsyncIOHandler(int, ECALLBACKTYPE,
void *)>, ct = CALLBACKTYPE_NONE, param = 0x818b888},
server = {nd = 48, pid = 94228}}

================================================================

sin -p 3018784 fds

player.bin 3018784 776K 628K 124K 2894K
618626
0 167945 WR 0/0 /net/dart.eleks.com/dev/ttyp4
1 167945 WR 0/0 /net/dart.eleks.com/dev/ttyp4
2 167945 WR 0/0 /net/dart.eleks.com/dev/ttyp4
3 3018783 W_ 0/0 /zzzzz/dev/play.100/data/Global/
4 3018783 R 0/40 /zzzzz/dev/play.100/data/Command/
5 3018783 W 0/0 /zzzzz/dev/play.100/data/Command/
6 3018782 R 0/0 /zzzzz/dev/play.100/etc/
7 3018783 W 0/0 /zzzzz/dev/play.100/data/sub_1/
8 3018783 _R 0/0 /zzzzz/dev/play.100/data/sub_1/
9 3018786 R 0/0 /zzzzz/dev/axis.100/data/Monitor/
10 94228
11 3018783 W 0/0 /zzzzz/dev/play.100/data/sub_2/
12 3018783 R 0/0 /zzzzz/dev/play.100/data/sub_2/
13 3018783 W 0/0 /zzzzz/dev/play.100/data/sub_3/
14 3018783 R 0/0 /zzzzz/dev/play.100/data/sub_3/
15 3018789 R 0/0 /zzzzz/dev/port.100/data/Monitor/
16 3018783 W 0/0 /zzzzz/dev/play.100/data/sub_4/
17 3018783 R 0/0 /zzzzz/dev/play.100/data/sub_4/
18 3018783 W 0/0 /zzzzz/dev/play.100/data/sub_5/
19 3018783 R 0/0 /zzzzz/dev/play.100/data/sub_5/
20 3018783 W 0/0 /zzzzz/dev/play.100/data/Monitor/
21 3018786 W 0/0 /zzzzz/dev/axis.100/data/Command/
22 3018786 _R 0/0 /zzzzz/dev/axis.100/data/Monitor/
0s 1
1s 69642
4s 1 __ 0/-1
/zzzzz/mon/procinfo/data/3018784/procinfo
5s 1 __ 0/-1
/zzzzz/mon/procinfo/data/play.100/PLAYER/procinfo
6s 1 __ 0/-1
/zzzzz/mon/procinfo/data/3018784/threadinfo
7s 1 __ 0/-1
/zzzzz/mon/procinfo/data/play.100/PLAYER/threadinfo
8s 1 __ 0/-1
/zzzzz/mon/procinfo/data/3018784/threadtextinfo
9s 1 __ 0/-1
/zzzzz/mon/procinfo/data/play.100/PLAYER/threadtextinfo
10s 1 __ 0/-1
/zzzzz/mon/procinfo/data/3018784/logdata
11s 1 __ 0/-1
/zzzzz/mon/procinfo/data/play.100/PLAYER/logdata
13s 1 __ 0/-1 /zzzzz/dev/play.100/profiles/

==============================================================

pidin net

ND Node CPU Release FreeMem BootTime
0 console 1 X86 6.3.0 26Mb/123Mb May 18 12:48:26
EEST
2004
1 axis_sew 1 X86 6.3.0 92Mb/119Mb Jun 29 01:25:32
EEST
2004
2 axis_hitachi 1 X86 6.3.0 93Mb/119Mb Jun 29 01:26:33
EEST
2004
12 dart 1 X86 6.3.0 986Mb/1022Mb Jun 25 15:28:48
EEST
2004
34 test_srv 1 X86 6.3.0 86Mb/254Mb Jun 28 21:04:12
EEST
2004
477 axis_test_1 1 X86 6.3.0 95Mb/119Mb Jun 28 03:12:05
EEST
2004
497 axis_test_2 1 X86 6.3.0 89Mb/119Mb Jun 28 03:10:16
EEST
2004

==============================================================


\

4

I’m surprised that you’re worried about it seeing that it is a beta version
that you seem to have been using. It’s a BETA for crying out loud. This
means there is more testing to do. It’s not the released version of QNX.

This isn’t a matter of ‘getting the latest version’. This is a matter of
‘getting the release version’. Which is the responsable thing to do, by
the way, even if you didn’t find any problems.

Why would you be upset with finding a bug in a beta version that was fixed
in the release? Why would you even care about what was fixed in the beta
version? I don’t expect the release notes to indicate bugs/fixes between
6.3 beta and 6.3 release…I could care less about the fixes that occured in
the beta, I care about the fixes/changes between 6.2.1 and 6.3. Are you
sure you’re not embarrassed about being caught using a beta version?

There is no reason to worry about the ‘test coverage of the system’ when you
are using software that is in beta, betas BY DEFINITIION are known/expected
to have problems.

If any one is at fault here, it is the person who didin’t explain to
management that a beta version of QNX was being used for development and
that there would be problems until the release version was out.

You’ll be much happier when you get your release version installed and
running…good luck.

Kevin


“Roman Pavluyk” <john@eleks.lviv.ua> wrote in message
news:cbv5tc$86$1@inn.qnx.com…

Thank you very much for you answer.

It’s about beta, we’re getting 6.3 release these days.

I haven’t seen any information about fixing similar bug in RC release
notes.
Can you point me to bug number, and, actually, a list of bugs fixed in
QNet
between first beta and release? We observed some strange anomalities, and
it’d be nice to know that a bug has been fixed rather than to guess > :slight_smile:

Robert Krten stressed similar issue in one of his postings – “get latest
version” is not a sufficient answer in many cases, customers want to know
what exactly was wrong and what exactly has been fixed, when a vendor
tells
that a system has to be updated. This is industry requirement, not mine
personal, please understand > :slight_smile: > We faced this situation only once so far,
and
this makes me worry about test coverage of the system. Who knows what
other
bugs have not been encountered?

Thank you again for your answer,
Roman


“Xiaodan Tang” <> xtang@qnx.com> > wrote in message
news:cbutn1$nj1$> 1@inn.qnx.com> …
Is this released 6.3.0 or is this one of the 6.3 beta? This sounds very
like
a bug
of QNET that fixed in the 6.3.0 beta time period.

-xtang


Roman Pavluyk <> john@eleks.lviv.ua> > wrote in message
news:cbreeo$1pu$> 1@inn.qnx.com> …
I’ve encountered a strange deadlock in the application.

After looking closer I’ve noticed that a thread holding a mutex is
blocked
on a MsgSendPulse_r() when sending a pulse to a channel on another
node.
It
had been blocked for more than 12 hours, though documentation says it
a
non-blocking call.

When I tried to cut a coredump of io-net, the node went down.

Please look at information below:

  1. Thread #5 is blocked with state NET_REPLY.
  2. It sends a pulse to fd #10, which points to process #94228 on node
    #48,
    though pidin net shows there is no such node. Why don’t we get an
    error,
    ESRCH, in this case?
  3. sin -p 3018784 fds cannot extract any information aboyt fd #10
    (which
    is not strange, because it asks the server to provide this
    information,
    and
    the server no longer exists)

Can you explain why the connection was not closed and why no error
code
was
returned and the thread was blocked instead?

This all applies to QNX 6.3, QNet lite.
I will try to reproduce the situation.

Thank you,
Roman

\

pidin -p 3018784

pid tid name prio STATE Blocked
3018784 1 …/bin/player.bin 10o CONDVAR 816eb54
3018784 2 …/bin/player.bin 10o CONDVAR 8116da4
3018784 3 …/bin/player.bin 5o READY
3018784 4 …/bin/player.bin 10o CONDVAR 811d084
3018784 5 …/bin/player.bin 50o NET_REPLY
3018784 6 …/bin/player.bin 21o RECEIVE 3
3018784 7 …/bin/player.bin 10o CONDVAR 816eb8c
3018784 8 …/bin/player.bin 10o RECEIVE 12
3018784 9 …/bin/player.bin 10o CONDVAR 816e764
3018784 10 …/bin/player.bin 10o CONDVAR 816e844
3018784 11 …/bin/player.bin 10o MUTEX 3018784-14 #1
3018784 12 …/bin/player.bin 10o CONDVAR 816ea3c
3018784 13 …/bin/player.bin 10o CONDVAR 818d9b4
3018784 14 …/bin/player.bin 10o MUTEX 3018784-05 #1
3018784 15 …/bin/player.bin 10o CONDVAR 8189ce4
3018784 16 …/bin/player.bin 10o CONDVAR 819500c
3018784 17 …/bin/player.bin 10o MUTEX 3018784-14 #1
3018784 18 …/bin/player.bin 10o CONDVAR 818118c
3018784 19 …/bin/player.bin 10o MUTEX 3018784-14 #1

================================================================

$2 = {client = {fd = 10,
handler = 0x80a08fc <CAsyncEntry::AsyncIOHandler(int,
ECALLBACKTYPE,
void *)>, ct = CALLBACKTYPE_NONE, param = 0x818b888},
server = {nd = 48, pid = 94228}}

================================================================

sin -p 3018784 fds

player.bin 3018784 776K 628K 124K 2894K
618626
0 167945 WR 0/0 /net/dart.eleks.com/dev/ttyp4
1 167945 WR 0/0 /net/dart.eleks.com/dev/ttyp4
2 167945 WR 0/0 /net/dart.eleks.com/dev/ttyp4
3 3018783 W_ 0/0 /zzzzz/dev/play.100/data/Global/
4 3018783 R 0/40 /zzzzz/dev/play.100/data/Command/
5 3018783 W 0/0 /zzzzz/dev/play.100/data/Command/
6 3018782 R 0/0 /zzzzz/dev/play.100/etc/
7 3018783 W 0/0 /zzzzz/dev/play.100/data/sub_1/
8 3018783 _R 0/0 /zzzzz/dev/play.100/data/sub_1/
9 3018786 R 0/0 /zzzzz/dev/axis.100/data/Monitor/
10 94228
11 3018783 W 0/0 /zzzzz/dev/play.100/data/sub_2/
12 3018783 R 0/0 /zzzzz/dev/play.100/data/sub_2/
13 3018783 W 0/0 /zzzzz/dev/play.100/data/sub_3/
14 3018783 R 0/0 /zzzzz/dev/play.100/data/sub_3/
15 3018789 R 0/0 /zzzzz/dev/port.100/data/Monitor/
16 3018783 W 0/0 /zzzzz/dev/play.100/data/sub_4/
17 3018783 R 0/0 /zzzzz/dev/play.100/data/sub_4/
18 3018783 W 0/0 /zzzzz/dev/play.100/data/sub_5/
19 3018783 R 0/0 /zzzzz/dev/play.100/data/sub_5/
20 3018783 W 0/0 /zzzzz/dev/play.100/data/Monitor/
21 3018786 W 0/0 /zzzzz/dev/axis.100/data/Command/
22 3018786 _R 0/0 /zzzzz/dev/axis.100/data/Monitor/
0s 1
1s 69642
4s 1 __ 0/-1
/zzzzz/mon/procinfo/data/3018784/procinfo
5s 1 __ 0/-1
/zzzzz/mon/procinfo/data/play.100/PLAYER/procinfo
6s 1 __ 0/-1
/zzzzz/mon/procinfo/data/3018784/threadinfo
7s 1 __ 0/-1
/zzzzz/mon/procinfo/data/play.100/PLAYER/threadinfo
8s 1 __ 0/-1
/zzzzz/mon/procinfo/data/3018784/threadtextinfo
9s 1 __ 0/-1
/zzzzz/mon/procinfo/data/play.100/PLAYER/threadtextinfo
10s 1 __ 0/-1
/zzzzz/mon/procinfo/data/3018784/logdata
11s 1 __ 0/-1
/zzzzz/mon/procinfo/data/play.100/PLAYER/logdata
13s 1 __ 0/-1 /zzzzz/dev/play.100/profiles/

==============================================================

pidin net

ND Node CPU Release FreeMem BootTime
0 console 1 X86 6.3.0 26Mb/123Mb May 18 12:48:26
EEST
2004
1 axis_sew 1 X86 6.3.0 92Mb/119Mb Jun 29 01:25:32
EEST
2004
2 axis_hitachi 1 X86 6.3.0 93Mb/119Mb Jun 29 01:26:33
EEST
2004
12 dart 1 X86 6.3.0 986Mb/1022Mb Jun 25 15:28:48
EEST
2004
34 test_srv 1 X86 6.3.0 86Mb/254Mb Jun 28 21:04:12
EEST
2004
477 axis_test_1 1 X86 6.3.0 95Mb/119Mb Jun 28 03:12:05
EEST
2004
497 axis_test_2 1 X86 6.3.0 89Mb/119Mb Jun 28 03:10:16
EEST
2004

==============================================================




\

5

I would agree with you completely.

Just one small remark – if network in 6.2.1 was working properly, we would
never try 6.3 beta. QNet lite beta was much more stable that QNet 6.2.x
release. That’s why I cannot fully accept your statements about comparison
of beta and release quality.

Regarding changes and fixes between 6.2.1 and 6.3. Since QNet was completely
rewritten, I am not sure anything can be compared.

BR,
Roman