Subject: Re: rmmod mol
From: Bill Fink (billfink@capu.net)
Date: Thu Nov 16 2000 - 21:21:58 MST
Samuel,
I put some more debug printout in debugger_cleanup in debugger/nub.c.
I then started and shutdown MOL 10 more times, with the following
result:
* 5 times the last line printed was "doing delete_async_handler",
which would indicate that the problem is in delete_async_handler.
* 4 times the shutdown and all cleanup completed successfully.
* 1 time the shutdown terminated earlier with the last line
being "did elfloader_cleanup", which would indicate the
problem was in the following mem_cleanup.
I'm not sure at this point whether there are multiple problems or
it's really a timing problem with some external event causing the
termination of do_cleanup at different points in time. I don't
know what else to check, but if there is anything else I can do,
I'm willing to try the next time I have some spare time. Overall,
however, it's not that major a problem, and you already gave me
a reasonable workaround earlier by using kunload to allow doing
a "rmmod mol".
-Bill
> On Thu, 16 Nov 2000, Bill Fink wrote:
>
> Samuel,
>
> I did as you suggested and put "did xxx_cleanup" messages after
> each cleanup function call in do_cleanup in emulation/main.c.
> I then started up MOL 20 times followed by a special shutdown.
> The results are the following:
>
> * 15 times, the last line printed was "did promif_cleanup",
> indicating the problem was in debugger_cleanup.
>
> * 4 times, the shutdown and MOL cleanup was totally
> successful.
>
> * 1 anomalous result had the last line being "did mem_cleanup",
> the following function being os_interface_cleanup. I'm now
> wondering if I transcribed this result correctly, since it
> was one of the earliest results, and all the other cases
> either terminated with "did promif_cleanup" or went all
> the way to successful completion.
>
> This is as far as I've tracked it so far. I see that debugger_cleanup
> is defined in both debugger/init.c and debugger/nub.c. I'm not sure
> which one to put further debug print statements into at this point.
> I know, I know. Just try one and it'll be obvious, but I just haven't
> had the time yet. I just wanted to keep you updated on my progress
> so far.
>
> -Bill Fink
>
>
>
> > On Sat, 11 Nov 2000, Samuel Rydh wrote:
> >
> > On Sat, Nov 11, 2000 at 01:16:11PM -0500, Bill Fink wrote:
> > > A followup to the above. Here's the output of saving the MOL
> > > session using F12:
> > >
> > > Unsafe state detected
> > > cleaning up...
> > > Terminating threads...
> > > DONE
> > >
> > > First, is the "Unsafe state detected" message anything to worry
> > > about? I noticed this when I first started using this new feature
> > > but never bothered to ask about it before. BTW, I find the new
> > > save feature extremely handy, especially on my relatively slow
> > > 6500 system at home.
> >
> > Nope. It is just diagnostic output not yet disabled.
> >
> > > Second, after doing the save, the module count for mol is 0,
> > > so the problem only manifests itself during an actual shutdown,
> > > which seems rather odd.
> >
> > So this always happens after a shutdown? Then MOL probably crashes
> > in one of the cleanup handlers. You could try inserting printfs
> > in do_cleanup() in emulation/main.c to verify that _kernel_cleanup()
> > really is called.
This archive was generated by hypermail 2a24 : Thu Nov 16 2000 - 21:22:32 MST