Hi Nadav, thank you for the reply. I replied inline. On Tuesday, August 1, 2017 at 11:26:44 PM UTC-7, Nadav Har'El wrote: > > > On Wed, Aug 2, 2017 at 7:18 AM, Hawx Chen <yingjhe...@gmail.com > <javascript:>> 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). > >
The updated backtrace is here. (gdb) bt #0 gettid () at linux.cc:38 #1 0x00000000005a4bd1 in syscall (number=186) at linux.cc:324 #2 0x00000000005a673e in syscall_wrapper (number=186) at linux.cc:360 #3 0x000000000048a698 in syscall_entry () at arch/x64/entry.S:261 #4 0x0000100000c00c2b in main (argc=1, argv=<optimized out>) at /home/hawx/GitHub/osv_mainline/tests/tst-syscall.cc:49 Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thanks to your review, there are something wrong in .CFI configuration. I am trying to figure out them. > > 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). > Of course, I will try to reproduce the phenomena. > > >> 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? > > Yes, I have all the latest code. > 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). > > I will try to figure out the alignment issue, too. -- 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.
