Re: bug in task server startup code

[Bas Wijnen]

On Sun, Aug 15, 2004 at 07:18:29PM -0300, address@hidden wrote:
> I don't think it's related to this bug you've found, since it would make
> an address 0 invalid access. In mem_add_task (or something like that), a
> piece of code like:
> 
> first_task->prev = task;
> first_task = task;

It's not related indeed, because it doesn't get that far yet, but it's still a
bug less to find when it does :-)

> I've seen address 4 being invalid accessed by tasks running over L4 when
> using Doug Leas' malloc. I thinks this occurred when mmap did not return
> the mmaped address.

It makes sense to get (near) NULL pointer dereferences if malloc returns NULL
and you don't check it.  However, I don't think this is the problem here.

I did some more testing, added output code to wortel/startup.c (which is the
startup code of all tasks started by wortel except physmem, so only the task
server at the moment) and tried to see if the mappings it request from physmem
(its startup and memory container) arrive with their correct data (I added
some print statements to physmem as well.)

Well, they don't.  startup.c pagefaulted on the check, so I checked the result
of the ipc which received the mapping.  It failed with error code 9, meaning
"message overflow in the receive phase.  A message overflow can occur [string
related stuff] and if a map/grant of an fpage fails because the system has not
enough page-table space available." (L4 Reference Manual X.2 page 62)

I am surprised by this.  If the page tables are too small already, then how
can they be large enough for a normal system.  It would probably help if
wortel grants pages to physmem instead of mapping them, but the limit seems to
be reached much too soon, and while such a solution might make it bootable, it
doesn't make it a usuable system.  It may be a good idea nontheless, though.
I don't think wortel should hold all memory in the system.  It doesn't use it
anyway.

Two last notes: If the mapping didn't succeed at all, the previous test
(printing the bytes at the entry point) should have page faulted as well.  It
didn't it just gave me different bytes than I expected.  The mappings to
started tasks, such as the task server, are not at their "real" address, as I
thought before, so that most probably was a mapping problem.  I didn't find it
yet though, and don't know if I can reproduce it.  I'll try that.

Failing ipcs may corrupt the database of a capability server.  In this case,
physmem thinks task has received the pages, because it is not notified of the
failed ipc.  

Thanks,
Bas

-- 
I encourage sending me encrypted e-mail.
Please send the central message of e-mails as plain text in the message body,
   not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
for more information, see http://129.125.47.90/e-mail.html

pgpMkZIqnNBNi.pgp
Description: PGP signature