bblum / landslide-simics Goto Github PK

for example, to catch a non-firing tell-thread-switch, we can assert that init never calls readline, that init never calls exec, etc.

implement the fix detailed in http://lwn.net/Articles/69419/#CommAnchor69826

by defining a macro in common.h

• mov anything,%esp

for example: notice when init goes to exec the shell, and replace the exec arguments with the name of the test case, bypassing the shell entirely. will need to rip out all other logic pertaining to the shell.

presumably would require a PAGE_FAULT_HANDLER= option

...printing a "our state and kernel scheduler state diverged, incorrect annotations??", rather than overflowing the stack.

if we had higher order functions, it would be easy to be like,

fn found_a_bug(fn print_addl_info(fn print(fmt, ...)))

to be used like

do found_a_bug |print_fn| {
    print_fn("allocated at %s", alloced_trace);
    print_fn("freed at %s", freed_trace);
}

my students today lost some time for forgetting to change within_function/without_function. instead, the defaults should be per-test-case, with something like if [ "$TEST_CASE" = "...." ]; ....

Last spring I moved the line

s->cur_agent->blocked_on_tid = target_tid;

to inside the if statement if (s->cur_agent->blocked_on_addr == -1), in commit a5223ff. I don't know why I did this, and it breaks pobbles mutexes, so I am moving it back out again. What is the deal?

Until then I may just have to say, yielding mutexes are not supported (unless they are identical to pobbles).

the flaw with the thread_fork example for annotations is "if you had to annotate preempt-me-here, didn't you already know the bug was there?", which is traditionally justified by an explanation that is somewhat of a lie in that landslide does not actually do that, although it could.

make it do that.

currently the glue scripts decide what filename to use for HTML output in 1 place, when you first begin running landslide (in config.simics).

in the future, landslide will need to continue running after finding a bug, potentially emitting several preemption traces for one run. the current html filename logic will be inadequate.

if interrupts-off gets leaked indefinitely past the context switch exit point, landslide will not be able to continue its schedule-in-flight approach. interrupts may remain off until the inadvertently-switched-to thread does a voluntary reschedule of its own, which will cause all kinds of landslide asserts to trip "some time later".

this happened with 2 groups in S14.

it would be much better if landslide could somehow decide "the thread has returned out of the context switcher, and a schedule is in-flight and this thread is not our target, and interrupts have been off for too long".

Currently TRYLOCK_SUCCESS_VAL just assumes the -1/0 protocol that POBBLES uses. This will probably fail horribly for kernels that use false/true.

as dave says:

Landslide could be set up so that instead of running against whatever is in the current directory it would instead run against a specific git/hg hash in a repo in 410 AFS space. Then you could look at their next couple of commits to see how they fixed a given problem!

I am suggesting that when a student runs Landslide you log the revision and what it told them. Then you can later see how they changed their code.

The stack overflow can only happen in presence of another bug which causes the scheduler to try to fly to a nonrunnable thread. So it would otherwise be an infinite loop. So this is a minor bug. But see comment:

720                                 // XXX: this seems to get taken too soon? change
721                                 // it somehow to cause_.._immediately. and then
722                                 // see the asserts/comments in the action
723                                 // handling_timer sections above.
724                                 /* some kernels (pathos) still have interrupts
725                                  * off or scheduler locked at this point; so
726                                  * properties of !R */
727                                 if (interrupts_enabled(ls->cpu0) &&
728                                     kern_ready_for_timer_interrupt(ls->cpu0)) {
729                                         lsprintf(DEV, "keeping schedule in-"
730                                                   "flight at 0x%x\n", ls->eip);
731                                         cause_timer_interrupt(ls->cpu0);
732                                         s->entering_timer = true;
733                                         s->delayed_in_flight = false;

"current 4 RQ [5] SQ {} DQ (4,6)" is confusing!

[SCHEDULE]      A timer tick that wasn't ours (0x1014d5).
[TEST]          Somebody's alive: Interrupts off.

of course interrupts are off -- you just entered the timer interrupt handler. it really wants to know the state of interrupts before the timer handler was entered, which naturally would be on. probably need to deal with this by passing anybody_alive a flag saying whether to skip checking EFL_IF - hacky, but it's not like we could TRAVEL BACK IN TIME or anything ;)

the problem with this is that calling estimate() actually performs updates of the value across the history of the current branch before outputting the estimated value, so it is not stable to call it multiple times in the same branch.

so before implementing this, will need to figure out a solution to deal with emitting multiple foundabug traces across a single exploration.

just hardcode a check in symtable_lookup and say, like, <unknown assembly file>

even though there are a lot of different values used

otherwise a confusing eip can get printed in a data race report

if interrupts-off state gets leaked, two context switches can go by before interrupts will come back on, and landslide will not have been able to save_setjmp to maintain the 1-thread-per-transition invariant.

can we somehow detect this, and found_a_bug when it happens.

otherwise, we will trip the invariant assertion in arbiter, in a cryptic and unhelpful way.

In arbiter.c, landslide will attempt to count idle as one of the available choices at any decision point is BUG_ON_THREADS_WEDGED is set to 0 (which is the default). This came up when trying to run a sleep test.

it should just use a flag, like any other self-respecting state machine.

it's also a stability/performance risk, since within_function itself is pretty bad.