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 [email protected]. 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.
