Open nyh opened 7 years ago
Unfortunately a similar failure with identical backtrace of tst-kill.so, in Jenkins run http://jenkins.cloudius-systems.com:8080/job/osv-build-nightly/1230/console:
TEST tst-kill.so OSv v0.24-436-g024e92a
Aborted
[backtrace]
0x0000000000449b2c <osv::generate_signal(siginfo&, exception_frame*)+140>
0x0000000000449b5a <osv::handle_mmap_fault(unsigned long, int, exception_frame*)+26>
0x0000000000328e73 <mmu::vm_fault(unsigned long, exception_frame*)+163>
0x0000000000388a48 <page_fault+136>
0x00000000003878d6 <???+3700950>
0x00001000000049ba <???+18874>
0x00000000004135cd <osv::application::run_main(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, int, char**)+381>
0x0000000000415de2 <osv::application::run_main()+674>
0x000000000020c22e <osv::application::main()+110>
0x000000000041622b <osv::application::start_and_join(waiter*)+331>
I still can't reproduce this on my machine.
Seemingly same crash in tst-pthread-clock.so - http://jenkins.cloudius-systems.com:8080/job/osv-build-nightly/1239/console
TEST tst-pthread-clock.so OSv v0.24-447-gc203748
Aborted
[backtrace]
0x0000000000449cec <osv::generate_signal(siginfo&, exception_frame*)+140>
0x0000000000449d1a <osv::handle_mmap_fault(unsigned long, int, exception_frame*)+26>
0x0000000000328a03 <mmu::vm_fault(unsigned long, exception_frame*)+163>
0x00000000003885d8 <page_fault+136>
0x0000000000387466 <???+3699814>
0x00001000000049ba <???+18874>
0x000000000041365d <osv::application::run_main(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, int, char**)+381>
0x0000000000415e72 <osv::application::run_main()+674>
0x000000000020c1fe <osv::application::main()+110>
...
This is probably a general bug, having nothing to do with these specific tests.
On the latest build, we see a new failure - http://jenkins.cloudius-systems.com:8080/job/osv-build/1280/console
Since the following build succeeded (see http://jenkins.cloudius-systems.com:8080/job/osv-build/1281/consoleFull), and since the latest patch had nothing to do with this test (it only modified the httpserver module), this appears to be yet another rare sporadic bug :-(
Unfortunately, I can't reproduce this failure on my local machine, despite trying 500 times, so I can't provide a better stack trace.