eischen at vigrid.com
Sun Nov 16 16:54:28 PST 2003
On Sun, 16 Nov 2003, Marcel Moolenaar wrote:
> On Sun, Nov 16, 2003 at 04:55:44PM -0500, Daniel Eischen wrote:
> > On Sun, 16 Nov 2003, Marcel Moolenaar wrote:
> > > > The same thread (main thread) is being resumed over and over again
> > > > which shouldn't happen for this simple program.
> > >
> > > Can it be that the thread is deadlocked? There's no forward progress.
> > > There's only context switching...
> > I don't think so. I think the thread stack/frame is corrupted, either
> > because it is copied out or resumed incorrectly. I'll do some more
> > digging.
> I loaded it up in the simulator. The thread is continuously being
> resumed because of a page fault that results in an upcall, which
> ends up in the UTS, which selects the same thread, which causes the
> page fault again.
Is it possible the thread is marked for an upcall when the
page is not yet present?
> The page fault is the result of a bogus address
> that in the debugger results in a SIGILL. However, when we don't
> run in a debugger, the SIGILL doesn't get handled. Hence the non-
> forward progress.
> The extensive debug information I posted earlier is therefore still
> relevant. Now that I have things running in the simulator I'll see
> if I can figure out where things go wrong. Chances are that we now
> have an upcall where we didn't have one before and that it exposes
> incomplete state (such as a thread pointer that hasn't been set).
> The incomplete state causes the corruption we're seeing.
This is kind of what I was thinking too.
> Anyway: I'll be digging too...
I'm not getting threads@ mail any longer, just the CC. Are
More information about the freebsd-threads