Did not mean to hijack this patch thread but it seemed related. In reality the issue with running unmodified iperf was caused by a bug in our fopen impl whch I sent a patch for.
On Friday, May 10, 2019 at 4:58:45 PM UTC-4, Waldek Kozaczuk wrote: > > When trying to run unmodified iperf3 3.6 (with these patches applied to > OSv) and using the scripts/manifest_from_host.sh from the other patch I > emailed I get this error per gdb: > > (gdb) bt > #0 0x00000000003acaa2 in processor::cli_hlt () at > arch/x64/processor.hh:247 > #1 arch::halt_no_interrupts () at arch/x64/arch.hh:48 > #2 osv::halt () at arch/x64/power.cc:26 > #3 0x0000000000241614 in abort (fmt=fmt@entry=0x63511b "Aborted\n") at > runtime.cc:132 > #4 0x00000000002027b1 in abort () at runtime.cc:98 > #5 0x0000000000349273 in mmu::vm_sigsegv (ef=0xffff800002adc068, > addr=<optimized out>) at core/mmu.cc:1316 > #6 mmu::vm_sigsegv (addr=<optimized out>, ef=0xffff800002adc068) at > core/mmu.cc:1310 > #7 0x000000000034aa9a in mmu::vm_fault (addr=addr@entry=0, > ef=ef@entry=0xffff800002adc068) at core/mmu.cc:1338 > #8 0x00000000003a68fe in page_fault (ef=0xffff800002adc068) at > arch/x64/mmu.cc:38 > #9 <signal handler called> > #10 0x000000000045a9cd in strlcpy (d=d@entry=0x2000001fdcc0 "", > s=<optimized out>, s@entry=0x0, n=<optimized out>, n@entry=4096) at > libc/string/strlcpy.c:21 > #11 0x000000000043e39f in path_conv (wd=0xffff800001462040 "/", > cpath=cpath@entry=0x0, full=full@entry=0x2000001fed00 "") at > fs/vfs/vfs_task.cc:74 > #12 0x000000000043e5d8 in task_conv (t=<optimized out>, > cpath=cpath@entry=0x0, acc=<optimized out>, full=full@entry=0x2000001fed00 > "") at fs/vfs/vfs_task.cc:149 > #13 0x000000000043426f in open (pathname=pathname@entry=0x0, flags=0) at > fs/vfs/main.cc:136 > #14 0x00000000004534f2 in fopen (filename=0x0, mode=0x100000092604 "r") at > libc/stdio/fopen.c:22 > #15 0x000010000014e925 in BIO_new_file () > #16 0x0000100000086b01 in load_privkey_from_file (file=0x0) at > iperf_auth.c:182 > #17 0x000010000007c518 in iperf_parse_arguments (test=0xffffa00001cf4c00, > argc=2, argv=0xffffa00001ce9200) at iperf_api.c:1175 > #18 0x00001000000682fe in main (argc=2, argv=0xffffa00001ce9200) at > main.c:100 > #19 0x000000000042f6dd in osv::application::run_main > (this=0xffffa00001c3c610) at /usr/include/c++/8/bits/stl_vector.h:805 > #20 0x000000000042f80f in __libc_start_main (main=0x100000068295 <main>) > at core/app.cc:37 > #21 0x00001000000681da in _start () > > Here is how I build and run: > ./scripts/manifest_from_host.sh -w iperf3 && ./scripts/build > --append-manifest > ./scripts/run.py -e '/tools/iperf3 -s' > > Per this fragment of iperf3 code - > https://github.com/esnet/iperf/blob/88f3ad87f38762081a6d7127890ff5c3a052b06a/src/iperf_api.c#L1164-L1176 > > - it tries to call load_privkey_from_file () even though > server_rsa_private_key > is null. Is it an indicator of some subtle bug in my patch? On Linux it > works just fine. > > However if I add a PEM file and execute same iperf3 on OSv like that (btw > the "some_users_file" does not even exist on OSv): > ./scripts/run.py -e '--verbose /iperf3 -s --rsa-private-key-path > /etc/private.pem --authorized-users-path some_users_file' > > iperf starts: > OSv v0.53.0-14-gf07aa8e1 > eth0: 192.168.122.15 > Booted up in 393.29 ms > warning: this system does not seem to support IPv6 - trying IPv4 > ----------------------------------------------------------- > Server listening on 5201 > ----------------------------------------------------------- > > Not sure what is going on .. > > Waldek > > > On Tuesday, April 30, 2019 at 11:49:47 PM UTC-4, Waldek Kozaczuk wrote: >> >> Waldemar Kozaczuk (2): >> Move getopt* files to libc folder and convert to C++ >> Enhance getopt family of functions to work with PIEs >> >> Makefile | 4 +- >> core/elf.cc | 14 +++ >> include/osv/elf.hh | 4 + >> libc/misc/getopt.cc | 125 +++++++++++++++++++++ >> libc/misc/getopt_long.cc | 88 +++++++++++++++ >> modules/tests/Makefile | 9 +- >> tests/tst-getopt.cc | 232 +++++++++++++++++++++++++++++++++++++++ >> 7 files changed, 473 insertions(+), 3 deletions(-) >> create mode 100644 libc/misc/getopt.cc >> create mode 100644 libc/misc/getopt_long.cc >> create mode 100644 tests/tst-getopt.cc >> >> -- >> 2.20.1 >> >> -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/d5ff332d-5d83-446a-a4ce-593f4e1f49ca%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
