Re: creating a segfault in a translator (on purpose)

[Neal H. Walfield]

> I was quite
> perplexed about the trivfs_S_io_read section in which
> you mmap a buffer for the data, but you don't have to
> free it.  So I scoured the 'Net, and found out that
> this is the way it is supposed to work; someone else
> will free the memory for me.

That someone is Mach.  What happens is the memory region is
disconnected from your address space.

>  Then my devious mind
> asked, "what happens if I pass back a pointer that
> can't be freed?"  Say I use alloca or automatic
> arrays, what happens then?  Well, it turns out that
> the translator dies (no surprise) with the message
> "Resource Lost".

When Mach removes the region from your address space, it is the
equivalent of an munmap.  As such, you need to supply a region
allocated with mmap (or an equivalent; pedantically, you need to
supply a region allocate with vm_allocate or vm_map).  If you use
alloca or malloc, the kernel does not care: it will still free the
region.  The result is either a missing stack or a whole in your heap
respectively.

>  What you also get is a 16MB core
> file (from the server that tried to free the memory, I
> presume), along with a flaky system that has a
> tendency to reboot itself within a couple of minutes,
> if not immediately.  So I was wondering if the hurd
> hackers out there thought that this was the expected
> behavior, considering that my kernel is v0.3 from the
> J2 disk series.

Yes, dumping core is a great way to kill Mach.  This is a known
problem.  Try disabling core dumps (i.e. set core server to kill
processes or suspend them).