On 20000830T204113+0200, Hans Aberg wrote:
> -- But I have forgotten what exactly a "segmentation fault" means; doesn't
> it just mean "memory problems"?

It means an invalid memory access (read/write outside the process'
allocated virtual memory space, or write access to readonly parts of
the memory space, or read access to any writeonly(!) parts).  Usually it
means a bug in the code but it can also be caused by overly large stack
allocations such as huge C-function-local arrays - or by stack overflow.

> On UNIX it would be better if it sent Hugs a signal when stack memory start
> running out; does anybody out there know of such a UNIX command? (I figure
> that GHC implements its own stack, and can therefore check it from time to
> time.)

The SIGSEGV (segmentation fault) signal is sent and it can (in principle
at least) be caught.  I believe that's how Emacs for example recovers
from it (it asks if you want to dump core and if you want to abort,
IIRC, not seen emacs segv in a long time).

> I am lookin into a book about the Mach kernel ("Programming Under Mach" by
> Boykin, Kirsen, Langerman & LoVerso), and it says (p 100) UNIX systems have
> a system call sbrk() which adjusts the demarkation line between the stack
> and heap.

In modern systems (at least on Linux, don't really know about others)
sbrk() is a low-level system call that enlarges the process' BSS section.
Usually, the BSS segment sits on top of the TEXT and DATA sections at
the low end of the virtual address space, and the stack lies at the high
end off the same space.  Normally there is a huge gap between the top
of BSS and top of the stack, and this gap is where the mmap system call
allocates virtual address space for memory-mapped files.

Usage of the sbrk() system call is forbidden if you use malloc(), since
malloc() internally uses sbrk() and you can royally screw malloc()'s
data structures if you mess with sbrk() yourself.

> But most UNIX's nowadays run a Mach kernel or an equivalent (or at least
> BSD UNIX, SUN and Linux). 

What do you mean by a Mach equivalent?  IIRC none of those you mention
are microkernels or derivatives of Mach.  (GNU HURD runs on top of GNU
Mach, but that's an entirely different story.)

-- 
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%

Reply via email to