Eventual page fault while running tst-kill.so

[raphaelsc]

As the title implies, page fault just happens eventually when running the test.
I started investigating it, but still didn't figure out the actual root of the problem. However, I do have some clues. For example: Defining out the code added into tst-kill.cc introduced by the commit 15dfac3 seems to solve the problem. The code added into kill() is apparently ok, so... Nadav, might it have something to do with concurrency?

OSv instance:

...
running /tests/tst-readdir.so
ok.
running /tests/tst-kill.so
Aborted

[backtrace]
0x3c7af2 osv::generate_signal(siginfo&, exception_frame_)+50
0x3c7b5c osv::handle_segmentation_fault(unsigned long, exception_frame_)+28
0x318e8b mmu::vm_fault(unsigned long, exception_frame*)+219
0x34d315 page_fault+101
0x34bed7 ex_pf+35
0x34ce56 call_signal_handler_thunk+0
0xa000904211000 ???+69275648
0x36cc30 sched::thread::~thread()+0
0x48ec834853fc8949 ???+1409059145

Follow the Backtrace:

(gdb) bt
#0 0x000000000037e0b2 in halt_no_interrupts () at /home/raphaelsc/osv-raphael/arch/x64/processor.hh:241
#1 osv::halt () at /home/raphaelsc/osv-raphael/core/power.cc:28
#2 0x000000000021b810 in abort (fmt=fmt@entry=0x5822b9 "Aborted\n") at /home/raphaelsc/osv-raphael/runtime.cc:131
#3 0x000000000021b890 in abort () at /home/raphaelsc/osv-raphael/runtime.cc:111
#4 0x00000000003c7af2 in osv::generate_signal (siginfo=..., ef=0xffffc000025ca028) at /home/raphaelsc/osv-raphael/libc/signal.cc:60
#5 0x00000000003c7b5c in osv::handle_segmentation_fault (addr=, ef=) at /home/raphaelsc/osv-raphael/libc/signal.cc:75
#6 0x0000000000318d9c in mmu::vm_sigsegv (addr=addr@entry=17592232214528, ef=ef@entry=0xffffc000025ca028)

at /home/raphaelsc/osv-raphael/core/mmu.cc:1093

#7 0x0000000000318e8b in mmu::vm_fault (addr=, addr@entry=17592232215168, ef=ef@entry=0xffffc000025ca028)

at /home/raphaelsc/osv-raphael/core/mmu.cc:1103

#8 0x000000000034d315 in page_fault (ef=0xffffc000025ca028) at /home/raphaelsc/osv-raphael/arch/x64/mmu.cc:35
#9 signal handler called
#10 0x0000100002c08280 in ?? ()
#11 0x000000000036c77b in main (this=0xffffc000025c5000) at /home/raphaelsc/osv-raphael/core/sched.cc:771
#12 sched::thread_main_c (t=0xffffc000025c5000) at /home/raphaelsc/osv-raphael/arch/x64/arch-switch.hh:139
#13 0x000000000034ce56 in thread_main () at /home/raphaelsc/osv-raphael/arch/x64/entry.S:113

[nyh]

On Mon, Mar 24, 2014 at 5:48 PM, Raphael S.Carvalho <
[email protected]> wrote:

As the title implies, page fault just happens eventually when running the
test.
I started investigating it, but still didn't figure out the actual root of
the problem. However, I do have some clues. For example: Defining out the
code added into tst-kill.cc introduced by the commit 15dfac315dfac35986cfbab3899b882a75354cea7266463seems to solve the problem. The code added into kill() is apparently ok,
so... Nadav, might it have something to do with concurrency?

I'm failing to reproduce this bug...

You and Pekka saw this bug, but never told me what sort of output this test
produces before it happens (please run with "-V" to see any output). It the
test already over, or is this crash happening in the middle of the test?

[raphaelsc]

On Mon, Mar 24, 2014 at 3:58 PM, nyh [email protected] wrote:

On Mon, Mar 24, 2014 at 5:48 PM, Raphael S.Carvalho <
[email protected]> wrote:

As the title implies, page fault just happens eventually when running the
test.
I started investigating it, but still didn't figure out the actual root
of
the problem. However, I do have some clues. For example: Defining out the
code added into tst-kill.cc introduced by the commit 15dfac3<
15dfac35986cfbab3899b882a75354cea7266463>seems
to solve the problem. The code added into kill() is apparently ok,
so... Nadav, might it have something to do with concurrency?

I'm failing to reproduce this bug...

You and Pekka saw this bug, but never told me what sort of output this test
produces before it happens (please run with "-V" to see any output). It the
test already over, or is this crash happening in the middle of the test?

In the middle. Please try 'make check' followed by 'scripts/test.py -s'
which runs all the test cases over the same instance.

Edit: I failed to understand which middle you meant. Let me run with -V to check that out.

Reply to this email directly or view it on GitHubhttps://github.com//issues/249#issuecomment-38486110
.

Raphael S. Carvalho

[nyh]

On Mon, Mar 24, 2014 at 9:11 PM, Raphael S.Carvalho <
[email protected]> wrote:

You and Pekka saw this bug, but never told me what sort of output this
test
produces before it happens (please run with "-V" to see any output). It
the
test already over, or is this crash happening in the middle of the test?

In the middle. Please try 'make check' followed by 'scripts/test.py -s'
which runs all the test cases over the same instance.

test.py -s doesn't show verbose output of each test, so how do you know it
crashed in the middle of this test?

I am guessing it crashed at the end of that test and have a guess why.
Can you please do me a favor and add the line

    sleep(1);

As the last line of tst-kill.cc's main(), and see if it solves the bug?

Nadav Har'El
[email protected]

[raphaelsc]

I will do it soon, sorry for the delay. I'm currently working on the issue #247. Oops, mistakenly closed the issue.