seg fault on kse_release () (fwd)

[Peter Edwards]

On Tue, 25 Jan 2005 14:04:45 -0800, Julian Elischer <julian at elischer.org> wrote:
> 
> 
> Jose Hidalgo Herrera wrote:
> 
> >The line causing the SEGFAULT is
> >rc = pthread_create(&threads[t], NULL, PrintHello, (void *)t);
> >
> >Why?, because t is declared as:
> >int t;
> >then you say:
> >args for start_routine in pthread_create are located in the address: t
> >
> >This will be what you want:
> >rc = pthread_create(&threads[t], NULL, PrintHello, (void *) & t);

Yan is actually (almost) correct. He's is casting the int to a pointer
type for the sake of the pthreads interface: the pointer is never
dereferenced, and shouldn't cause a segfault. The lack of cast in
"PrintHello" is probably the worst transgression.

(Consider: "t" is a local variable, and its address won't change for
any thread in the loop of "CreateThread". The code may have some type
transgressions, but it's reasonably well formed)

> probably we shouldn't crash the system however.. (it is crashing right?
> that wasn't so clear to me).

Given the stack trace, that's not happening (though I'll let Yan give
the definitive answer). The stack trace includes "kse_sched_single()",
which is a routine from libpthread, not the kernel (there's a
kse_release symbol in libpthread and the kernel.)

> >>what confuses me is that, if the system is out of memory, then i should
> >>see the error returned from pthread_create() or calloc(), but not SEG
> >>fault, or i must have missed something?

(warning: there are many over-simplifications ahead)
You should also be aware that FreeBSD can overcommit memory.
Effectively, this means that a successful result from "malloc(X)" does
not mean the system guarantees that X bytes of (real) memory are
actually available: it means that this chunk of your process's address
space has been carved out for you: the system may "over commit". The
reasons and history for this are complex, but essentially, the kernel
can either be generous, and open user programs up to faulting
asynchronously (read: segfaulting if there no free memory at the time
you first access a page), or be conservative - carefully track memory,
possibly wasting resources (RAM or paging space) in order to guarantee
that allocated memory is allways accessable. "SVR4" OSes like Solaris
will generally not over commit, and guarantee synchronous failure for
memory allocation, but will be more wasteful of resources. While BSD
derived systems will indeed overcommit, at the expense of opening up
user programs to the possibility of coping with pagefaults if they are
not well behaved in terms of their memory usage. (I hope that's
reasonably objective: _please_, everyone, don't offer opinions on
what's "better" without creating a new thread)

Cheers,
Peadar.