io-net dump, consistently, from a telnet session

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

Support,

RTP 6.1, Regular TCP/IP (only, no qnet), tulip network driver
Pentium/133, 64meg, cheap video (VGA Only)
Dump at http://www.2imagineit.net/qnx6/io-net.core.gz
Running code available if required

I’ve been porting the Intel UPnP SDK using Samba and several telnet
sessions and everything has gone well up to this point. I finally got
all the code, exception handling, undefined stuff, etc resolved so the
code runs.

The first few times I ended up rebooting the system (ack, 6 years QNX4
and I reboot to change hardware - 6 days on Nto…) until I finally managed
to track down what was happening:

The application (sample UPnP TV device) starts multiple threads including
a mini web server, multicast listener, threads as-needed for
inbound requests, …

Running from a telnet session (Kermit 95, QNX protocol) it would get about
half-way through the initialization setup (it varied where it aborted)
during
which time the init thread made calls that invoked other threads (HTTP
requests to internal web server, sending multicast announcements, …
30 seconds later my telnet sessions were gone and CPU was at 100%.

During this time the application was “spewing” debug data - but at a rate
considerable less than what a ‘find /’ would give - and it doesn’t die.

io-net aborted, inetd and nmbd started spinning.

If I run this from pty’s in Photon everything runs just fine… I backed
all
the way down to:
ionet -ptcpip
mount -Tio-net -opci=0 /lib/dll/devn-tulip.so
ifconfig en0 172.31.1.18 netmask 255.255.255.0 up
inetd

Run application
… io-net dies.

I guess the good part of this is I now know how to fully start networking
from scratch on Nto :wink:

Happy hunting, let me know if you need more (including the SDK).

Jay

2

Ding!

I get the impression that none of the developers or support people read
this group.

Jay

Jay Hogg <jh@fastlane.net.r-e-m-o-v-e> wrote in article
<9kjusk$2rh$1@inn.qnx.com>…

Support,

RTP 6.1, Regular TCP/IP (only, no qnet), tulip network driver
Pentium/133, 64meg, cheap video (VGA Only)
Dump at > http://www.2imagineit.net/qnx6/io-net.core.gz
Running code available if required

I’ve been porting the Intel UPnP SDK using Samba and several telnet
sessions and everything has gone well up to this point. I finally got
all the code, exception handling, undefined stuff, etc resolved so the
code runs.

The first few times I ended up rebooting the system (ack, 6 years QNX4
and I reboot to change hardware - 6 days on Nto…) until I finally
managed
to track down what was happening:

The application (sample UPnP TV device) starts multiple threads including
a mini web server, multicast listener, threads as-needed for
inbound requests, …

Running from a telnet session (Kermit 95, QNX protocol) it would get
about
half-way through the initialization setup (it varied where it aborted)
during
which time the init thread made calls that invoked other threads (HTTP
requests to internal web server, sending multicast announcements, …
30 seconds later my telnet sessions were gone and CPU was at 100%.

During this time the application was “spewing” debug data - but at a rate
considerable less than what a ‘find /’ would give - and it doesn’t die.

io-net aborted, inetd and nmbd started spinning.

If I run this from pty’s in Photon everything runs just fine… I backed
all
the way down to:
ionet -ptcpip
mount -Tio-net -opci=0 /lib/dll/devn-tulip.so
ifconfig en0 172.31.1.18 netmask 255.255.255.0 up
inetd
login
Run application
… io-net dies.

I guess the good part of this is I now know how to fully start networking
from scratch on Nto > :wink:

Happy hunting, let me know if you need more (including the SDK).

Jay
\

3

Jay Hogg <nobody@nowhere.com> wrote:

Ding!

I get the impression that none of the developers or support people read
this group.

Actually - a better statement would be that many people are on vacation. :wink:

I took a look at the corefile, to check to see if it was a driver issue
(which it doesn’t appear to be), and then passed it over to the right people
in protocols to poke at. :wink:

chris

\

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

4

Thanks Chris. All somebody had to do was mention “On Vacation - Next week”

  • I’ve been
    around long enough to have dozens of messages answered like this.

I wouldn’t be jumping up and down as much but it kinda stopped me dead in
my
tracks because every time I blink I wacked io-net and it gets really
frustrating
walking across the room to restart it, re-open telnet sessions and recover
edits, restart gdb, … Lousy video card in the system and lack of desk
space
keep us separated.

Besides, I didn’t think I should be able to bail io-net at will :wink:

Thanks again,
Jay

Chris McKillop <cdm@qnx.com> wrote in article
<9ks0a7$8ef$2@nntp.qnx.com>…

Jay Hogg <> nobody@nowhere.com> > wrote:

Ding!

I get the impression that none of the developers or support people read
this group.


Actually - a better statement would be that many people are on vacation.
:wink:

I took a look at the corefile, to check to see if it was a driver issue
(which it doesn’t appear to be), and then passed it over to the right
people
in protocols to poke at. > :wink:

chris

\



cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL

5

“Jay Hogg” <nobody@nowhere.com> wrote in message
news:01c12068$f1104ef0$c80b11ac@j_hogg1…

Thanks Chris. All somebody had to do was mention “On Vacation - Next week”

  • I’ve been
    around long enough to have dozens of messages answered like this.

I wouldn’t be jumping up and down as much but it kinda stopped me dead in
my
tracks because every time I blink I wacked io-net and it gets really
frustrating
walking across the room to restart it, re-open telnet sessions and recover
edits, restart gdb, … Lousy video card in the system and lack of desk
space
keep us separated.

Besides, I didn’t think I should be able to bail io-net at will > :wink:

Yeah unlike QNX4 if any of the io-net component crash it takes io-net
with it. In QNX4 you could have Socket crash and still have FLEET
to fall back on.

I’ve heard you could start two instances of io-net, so maybe it’s
possible to have one io-net handle qnet and the other tcp/ip but
I beleive they would have to run on different network card.



Thanks again,
Jay

Chris McKillop <> cdm@qnx.com> > wrote in article
9ks0a7$8ef$> 2@nntp.qnx.com> >…
Jay Hogg <> nobody@nowhere.com> > wrote:

Ding!

I get the impression that none of the developers or support people
read
this group.


Actually - a better statement would be that many people are on vacation.
:wink:

I took a look at the corefile, to check to see if it was a driver issue
(which it doesn’t appear to be), and then passed it over to the right
people
in protocols to poke at. > :wink:

chris

\



cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL

6

Don’t see anything obvious in the dump. Can I get the app
itself?

-seanb

Jay Hogg <jh@fastlane.net.r-e-m-o-v-e> wrote:
: Support,

: RTP 6.1, Regular TCP/IP (only, no qnet), tulip network driver
: Pentium/133, 64meg, cheap video (VGA Only)
: Dump at http://www.2imagineit.net/qnx6/io-net.core.gz
: Running code available if required

: Happy hunting, let me know if you need more (including the SDK).

: Jay

7

Continuing this thought…

I brought up another machine (running from CD, also tulip) and ran the
same program… same result. io-net and friends died.

Jay

Chris McKillop wrote in message <9ks0a7$8ef$2@nntp.qnx.com>…

Jay Hogg <> nobody@nowhere.com> > wrote:

Ding!

I get the impression that none of the developers or support people read
this group.


Actually - a better statement would be that many people are on vacation. > :wink:

I took a look at the corefile, to check to see if it was a driver issue
(which it doesn’t appear to be), and then passed it over to the right
people
in protocols to poke at. > :wink:

chris

\

cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL

8

Sean,

Sorry for the delay… this message just showed up today on my viewer!

I dropped a 2.7meg file in my QUICS account (jshogg) as ‘tosean.pax.gz’.

It is compiled Nt0 6.1 (libc.so.2)

Unzip/pax it - there are 2 packages within it:

  1. uuid - libuuid.so for the upnp

  2. upnp (as upnp-test since I was hacking)

  3. You need to makde sure uuid/libuuid.so and upnp/bin/libupnp.so are
    available in the library path.

  4. cd upnp-test/sample/tvdevice

  5. edit goctrlpt and godevice (shell scripts) to have a valid IP

  6. run godevice. It will “appear” to be up running. 50/50 chance io-net
    is still running.

  7. If this still works try ‘goctrlpt’ on another console. Commands are
    pretty simple within the example code.

I’ve actually had it up running a number of times over the last 2 weeks
but never for any length of time.

If you need to recompile it (it has a lot of verbose useless debug) there
is a make_all.sh script at the root level of the upnp tree that does work.
Options are available in a config.h file (manual edit, .pdf included has
some info).

Let me know if you need more info. The email I originally posted with
is invalid (I moved and forgot it) - I can be reached quickest at
jay (dot) hogg (at) T (dash) netix (dot) com

Thanks for the help, good luck hunting!
Jay


Sean Boudreau wrote in message <9ku9v0$lv1$1@nntp.qnx.com>…

Don’t see anything obvious in the dump. Can I get the app
itself?

-seanb

Jay Hogg <> jh@fastlane.net.r-e-m-o-v-e> > wrote:
: Support,

: RTP 6.1, Regular TCP/IP (only, no qnet), tulip network driver
: Pentium/133, 64meg, cheap video (VGA Only)
: Dump at > http://www.2imagineit.net/qnx6/io-net.core.gz
: Running code available if required

snip

: Happy hunting, let me know if you need more (including the SDK).

: Jay

9

Sean,

Plot thickens and I’ve got a lot more information.

io-net is dying on a call to sendto() in ssdplib.c/NewRequestHandler().
The open/fcntl()/sendto()/close is contained in this function that is
running as a pthread. The sendto() call had no error checking on it
and when I added some this was the result:

(on a manual restart after io-net dumped)
io-net -ptcpip &
mount -Tio-net -opci=0 /lib/dll/devn-tulip.dll
ifconfig en0 172.31.1.18 netmask 255.255.255.0
… The app “runs” but no multicasting happens and I get a
-265 (Host Unreachable) from the sendto() call.
sin_len=0 sin_family=2 sin_port=1900 sin_addr=239.255.255.250

Now…
route add default 172.31.1.1
The app executes up to the sendto() call then io-net
dumps… on the pty that started it there is “m_copym”
and I hope that is the hint you are looking for :slight_smile:

In all fairness, although I still don’t believe io-net should
ever dump, the upnp library is a nasty collection of code from
different places with different standards and bad assumptions
made in code. The most obvious I ran into recently (and fixed,
but not in your source) was sockadd_in was never
zero’d and sin_len was always garbage.

I am doing a major cleanup/convert to c++/fix stupid errors/
MUCH better debug tracing/etc and I can forward you the
work-in-progress if this still isn’t enough.

Jay

Sean Boudreau wrote in message <9ku9v0$lv1$1@nntp.qnx.com>…

Don’t see anything obvious in the dump. Can I get the app
itself?

-seanb

Jay Hogg <> jh@fastlane.net.r-e-m-o-v-e> > wrote:
: Support,

: RTP 6.1, Regular TCP/IP (only, no qnet), tulip network driver
: Pentium/133, 64meg, cheap video (VGA Only)
: Dump at > http://www.2imagineit.net/qnx6/io-net.core.gz
: Running code available if required

snip

: Happy hunting, let me know if you need more (including the SDK).

: Jay