> 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). _______________________________________________ Help-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-hurd