Help from Iulian

[c***@CSIC.UMD.EDU]

I'm pretty sure your
dynamic stack
expansion is busted,
i.e. when you
expand the stack,
the data you read
from the new stack
page is garbage.

Print a message in
the page fault
handler as to where
the fault is (to
make sure it's a
stack expansion
request), and also
make sure you
allocate a fresh
page for the stack
and you glue it
correctly under the
previous stack page
(as I said in the
recitation).
The first stack page
should go at virtual
address FFFFE000,
the second
at FFFFD000, and so
on.

The program counter
where it crashes
won't tell you much
because I'm
almost sure by
reading garbage off
the stack you
accidentally jump
into
a halting/endless
loop.

If this helps,
please print a
message on the
newsgroup and in the

future
ask these question
on the newsgroup so
that others benefit
from the
response (or you get
a response from
someone that has
solved the
problem
already).

Iulian

Hi Iulian,
I have a question

about Project4.
Kursad and I

couldn't seem to

figure out where is
the problem.

Anyway, when I run

"rec.exe 300" in
shell, instead of

crashing, the

program freezes
after several page

faults. And

there's no specific
page where the
system

freezes.
"calling recurse

300

calling recurse

299

...
calling recurse

290

calling rec
"
Do you know where

the problems could
be? Thanks in

advance.

[cs412041]

did you ever get this problem fixed it is the same problem i'm getting
and i'm pretty sure my dynamic stack algorithm works...

--Rohit

[David Hershey]

I'm having this problem also. I put a print statement in
Get_Next_Runnable and run rec.exe 300. Recurse is called about 10
times, at which point I see the print from Get_Next_Runnable. I assume
this means the scheduler (I'm running off of P2 solution) is allowing
another process to run, and it appears that rec.exe is never allowed to
execute again.

I've looked over my stack expansion algorithm several times and to the
best of my knowledge it works properly. I've printed the virtual
address of the base of my stack, the page fault address, and the virtual
address where my new stack page will be mapped. All seem appropriate
for every page fault up to my problem spot.

Has anyone run into this and been able to fix it, or at least have
suggestions as to what the issue might be?

Thanks,
David

[Justin Berman]

The solution to this problem is actually a simple one. If you are using
the p2-solutions scheduling code, then you need to change the thread
queue that get next runaable checks from an array of threadqueues to a
single threadqueue

-Justin

[David Hershey]

Right. My approach was to have the scheduling code only reference
s_runQueue [0]. After making the suggested modification, everything
runs great. Thanks a lot.

David