simply porting the default hello world to OSv and loading it with wrk would help exibit the issue.
2017-08-02 8:26 GMT+02:00 Nadav Har'El <n...@scylladb.com>: > > On Wed, Aug 2, 2017 at 7:18 AM, Hawx Chen <yingjheng.c...@gmail.com> > wrote: > >> Hi Nadav, thank you for your reply. >> I already finished the Patch V3 and then will update it soon. Then I want >> to summarize the tests and related modification in Patch V3. >> >> I tested the Patch in different ways: >> 1. I inserted "abort()" in the gettid() system call @linux.cc and then >> tested it through the tst-syscall.so. According to the output, the patch >> works as expected. >> [backtrace] >> 0x000000000022d578 <abort(char const*, ...)+270> >> 0x00000000005a3fb6 <gettid+8> >> 0x00000000005a4be4 <syscall+1549> >> 0x00000000005a6751 <syscall_wrapper+121> >> 0x000000000048a697 <syscall_entry+71> >> 0x0000100000c00c2a <???+12586026> >> > > Thanks. So far looks good, but you should run in gdb "osv syms" to allow > it to figure out the symbol inside the test's shared object > (0x0000100000c00c2a). > > >> 0x00000000006422eb <osv::application::run_main()+329> >> 0x0000000000641da4 <osv::application::main()+108> >> 0x00000000006417b9 <???+6559673> >> 0x00000000006417de <???+6559710> >> 0x00000000006a7ce2 <???+6978786> >> 0x00000000006aa82d <???+6989869> >> 0x000000000044ce37 <std::function<void ()>::operator()() const+49> >> 0x00000000005c2d6d <sched::thread::main()+27> >> 0x00000000005bec46 <thread_main_c+38> >> 0x000000000048a622 <???+4761122> >> >> 2. I also tested this patch through "make check", It passed completely. >> OK (116 tests run, 193.676 s) >> >> 3. "make arch=aarch64" is compiled successfully, too. >> ... >> LINK zfs.so >> MKBOOTFS build/release.aarch64/bootfs.bin >> AS bootfs.s >> LINK loader.elf >> LIBOSV.SO >> STRIP loader.elf -> loader-stripped.elf >> DD build/release.aarch64/loader.img preboot.bin >> DD build/release.aarch64/loader.img loader-stripped.elf >> IMGEDIT build/release.aarch64/loader.img >> ... >> >> 4. About the Golang issue, #850, it still doesn't work; >> > > As you can see in the issue's discussion I was never sure that #850 was > related to the stack issue at all. > > The stack issue was quite visible whenever you tried to do something > "serious" with Go, e.g., I believe Benoit (CCed) tried an HTTP server which > consistently crashed under the load. Benoit, maybe you remember an easy way > to reproduce this problem? > > If would be good if you could find something that fails before your patch, > and succeeds after it (this is a good general advice for any patches). > > >> moreover, one exception occurs. >> It has the wrong alignment, I am still figuring this phenomena whether it >> is caused by one new entry in thread_control_block. >> Or it is related another issues. >> >> Assertion failed: align_check(user_tls_size, (size_t)64) >> (arch/x64/arch-switch.hh: setup_tcb: 138) >> > > Wierd. This is a relatively recent change (for Gcc 7 support). This > assertion should not fail because object::initial_tls_size() does > _initial_tls_size = align_up(_initial_tls_size, (size_t)64) > so could the assertion later failed? > I assume you have all the latest code from master, including the patch to > core/elf.cc which added the above align_up call? > > I wonder if we now have a problem with with sizeof(tcb) being misaligned. > I didn't think we would, but maybe I missed something (although I don't see > how this explains this specific assertion failure). > > -- 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. For more options, visit https://groups.google.com/d/optout.
