Closed caltry closed 11 years ago
I have seen that before when I was getting stack corruption or I did something wonky with the build. I don't recall the details though. Are you seeing this with the source on github?
On Mon, Dec 17, 2012 at 11:12 PM, David Larsen notifications@github.comwrote:
Right now I'm running into some problems with creating and reading from queues at start up (my machine doesn't get the "press a key to run a program" message). It looks like few of the functions which interact with queues are set up to handle errors, which gives us some really weird behavior. I've run into a number of problems with resched() trying to grab a thread off of an invalid queue and crashing:
thrcurrent = dequeue(readylist); thrnew = &thrtab[thrcurrent]; thrnew->state = THRCURR;
If dequeue returns SYSERR (== -1) here, we get really weird behavior. I think we should have panicked before we even got to this point, so I'll be going around trying to make these queue interactions more robust.
— Reply to this email directly or view it on GitHubhttps://github.com/jetcom/xinu-arm/issues/2.
I run into this problem (not getting to the "press a key to run a program" prompt) without any modifications to the 'interrupts' branch. I've tracked this down to a QEMU bug on my host system; it doesn't look like XINU or the build environment are the source of my problem.
Right now I'm running into some problems with creating and reading from queues at start up (my machine doesn't get the "press a key to run a program" message). It looks like few of the functions which interact with queues are set up to handle errors, which gives us some really weird behavior. I've run into a number of problems with resched() trying to grab a thread off of an invalid queue and crashing:
If dequeue returns SYSERR (== -1) here, we get really weird behavior. I think we should have panicked before we even got to this point, so I'll be going around trying to make these queue interactions more robust.