network_test crashes after long run about nanos HOT 4 CLOSED

thats certainly progress. network test was built on the same house of cards as stage3.

the two courses of action here are either to pull in your heap work into the unix process
space or to bring up another network stress test program.

I think* it might be more forward looking and informative to pursue the latter option, but
one aspect of my staggering accumulation of uncompleted work is that we lost
dynamic loading at some point...that was going to be temporary but I should file a bug on that

from nanos.

I'd opt to do both, namely:

1. Make network_test into a regression tool. Have it run for some finite period of time - short enough to integrate into CI, for example - and return a pass/fail code. We could perhaps try qemu's userspace networking stack to completely bypass brctl / tunctl / sudo and get a self-contained test running with a canonical make test. Forget about a return value from qemu for now (as you noted there's some more work to do to fix that), just consider it a pass if network_test passes. (Perhaps webs can quit on a magic http request so we don't need to find and kill qemu.) Getting this into CI would really help prevent regressions. Toss out hello world and make webs the standard build.

2. Add a flag to network_test for running interactively and thus indefinitely. Have it give some sort of output to indicate progress, maybe an uptime, the number of successfully opened and closed connections, an error count and the heap size. Here we can observe memory utilization. Maybe the http responses can send back stats from the kernel side too. (Might be time to think about making a /proc-type interface to the tuple space?)

3. Bring another program into the mix. I'm all for fixing mmap(), ld.so and other vm issues - they are high priority - but if we're not there yet or would be blocked on it, can we build statically for the time being?

Without really surveying the options, I might suggest starting by looking at https://github.com/esnet/iperf

from nanos.

would like to resolve, but there are really two outstanding actions here:

o concretize network test so that it runs in a short fixed interval and gives
a basic pass/fail indication on the tree

o fix remaining memory issues - with the new process space heaps it
leaks quite slowly, but at 5M uniboots it starts to exhaust memory and
that causes linux to really go sideways (stupid linux)

from nanos.

Can not be reproduced now.

from nanos.