sp1 Server Timeout


(Rakshit Muthappa Padetira) #1

Running the sp1 test on local machine succeeds (goes to completion and prints success) but fails on the test161 server. The status as seen on the results page of test161 is

started
monitor: no progress for 10 s in kernel mode
shutdown: unexpected shutdown

why would this happen


(Geoffrey Challen) #2

That looks like a deadlock.


(Jihai Xu) #3

Same error here. Passed the first submission. After finishing the stoplight without nothing changed in whalemating.c, the submission showed sp1 failed. But the whalemating.c passes every time in local test161 run. What could the problem be? If there is a deadlock, local test161 cannot detect the deadlock issue?


(Geoffrey Challen) #4

We haven’t integrated the new deadlock detection in OS/161 2.0.3 into test161 yet and probably won’t this semester. The only way it has of detecting deadlock is observing that the kernel has sat for a while without continuing.

I’d double check that your implementation handles all cases properly: males arriving first, females first, etc. I’d also double-check to make sure that you haven’t altered our testing code in some way, and that you’re running with the same level of concurrency.


(Jihai Xu) #5

Weird, I submit again with the same commit and get 10 point on sp1.
Maybe my code contains error and sometime test161 cannot detect them.


(Geoffrey Challen) #6

That’s certainly possible.


(Scott Haseley) #7

test161 uses a different random seed each time it runs, and since the test code uses the random_yielder() function, there is some non-determinism. You may be deadlocking due to some race condition or some invalid assumption you’re making, and it only gets triggered on certain runs with certain seeds. Ideally, we would run this several times in a row to ensure more stability, which we might have to do in the future.