To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.rcx.legosOpen lugnet.robotics.rcx.legos in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / RCX / legOS / 3580
3579  |  3581
Subject: 
Re: My problems with adding a Best Fit algorithm for memory management to kernel/mm.c
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Thu, 11 Dec 2003 02:34:34 GMT
Viewed: 
4191 times
  
In lugnet.robotics.rcx.legos, Michael Martelli wrote:

When I did not shut off the RCX between program executions
here is the allocation of memory

Addr PID Size
--------------------

<snip>

AFD6 AD50 000A

<snip>

B648 AFDA 006B

<snip>

I didn't have time to mention this in my earlier post, but this memory dump
points out a potential problem with the way BrickOS allocates memory for
programs.  In the above memory dump, the 0x6B words at 0xB648 represent a
downloaded BrickOS program.  The memory block is owned by PID 0xAFDA which is
the program manager task (that's the block with 0xA words at 0xAFD6).  However,
when you turn the RCX off, BrickOS shuts down the program manager and releases
the memory for its task but not any memory owned by the program manager (since
it is a kernel task).  So, the downloaded program lives on in memory with a
non-existent task as owner.

Now, when you turn the RCX back on, it starts up and allocates memory for the
various kernel tasks.  With a first fit malloc() algorithm, it just so happens
that the tasks get allocated the same memory that was released on power off.  So
everything is peachy.  But, with the worst fit algorithm in place, the program
manager task gets moved to another address and so the downloaded program PID
points to a non-existent task.

In the (extremely) unlikely event a user program starts up a task and it gets
allocated to 0xAFDA, then when this task exits it will also unwittingly free up
the memory used by the downloaded program (unbeknownst to the program manager)
and a crashed OS will no doubt quickly be the result.

Simply changing the PID for downloaded programs to an impossible value (like 1)
would solve the problem.

Mark



Message has 1 Reply:
  Re: My problems with adding a Best Fit algorithm for memory management to kernel/mm.c
 
Mark Riley wrote: [snip] (...) This is easy enough to implement (1 or 2 lines), but raises the question: Should these memory strategies be included with BrickOS (with a config.h flag to control it)? I am sure the educators would rather leave that (...) (21 years ago, 11-Dec-03, to lugnet.robotics.rcx.legos)

Message is in Reply To:
  Re: My problems with adding a Best Fit algorithm for memory management to kernel/mm.c
 
(...) Mark, Thanks for the reply, and sorry I forgot to include some more details I have results from 2 memory scans (the values may be a bit off from each other (i.e. starting addresses, but that is becuase they are from 2 times I ran it, and I (...) (21 years ago, 7-Dec-03, to lugnet.robotics.rcx.legos)

14 Messages in This Thread:



Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact

This Message and its Replies on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR