Date: Wed, 19 Jan 2000 09:45:24 +0100 From: Martin Cracauer <cracauer@cons.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Iani Brankov <ian@bulinfo.net>, hackers@FreeBSD.ORG, Jason Evans <jasone@canonware.com> Subject: Re: The stack size for a process? Message-ID: <20000119094523.A79669@cons.org> In-Reply-To: <200001180327.TAA18698@apollo.backplane.com>; from Matthew Dillon on Mon, Jan 17, 2000 at 07:27:11PM -0800 References: <200001180055.TAA17507@pcnet1.pcnet.com> <3883D1BB.391C9F0C@bulinfo.net> <20000117183902.B27689@sturm.canonware.com> <3883D60A.BA0BAF37@bulinfo.net> <200001180327.TAA18698@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In <200001180327.TAA18698@apollo.backplane.com>, Matthew Dillon wrote:
> :Jason Evans wrote:
> :> Thread stacks have a default size of 64kB. libc_r now uses growable stacks
> :> with "guard pages" between stacks to try to catch stack overflow. It looks
> :> like it did you some good. =)
>
> Heh heh. I have a feeling that we're going to see more of these sorts
> of problems crop up (over-extending stacks, making assumptions about
> compiler optimizations) as more and more people try to do threads
> programming and fewer and fewer of them have the small-systems
> background to realize that there are in fact stack and compiler
> optimization issuesl
I would be nice if we could print a more verbose message
("Use the UNIX API, fool!" :-)
Difficult in first place for the current userspace threads, since the
kernel (which had to print the message) doesn't know that this
particular page was a thread stack guard page. [Matt you know this,
but read on]
But how about an interface from userlevel to the kernel that can be
used to submit error messages that the kernel should print in case of
page faults?
I'm think of something like madvice(2):
int maperrmsg(void *addr, size_t len, const char *msg, int where);
When a page fault happens for a page that has been marked that way,
the kernel looks up the pointer and if it points to valid space, the
message is printed somewhere, indicated by the last argument (console,
syslog or tty controlling the process).
Regarding bloat, if we restrict the semantics so that addr and len
must exactly match an existing mapped region (len could then possibly
be "auto"), we could get away with an additional char pointer in
struct vm_map_entry, not in every page.
I'd really like this. In addition to catching most of the new thread
user cases, we could also use it for malloc() guard page systems like
efence. With a little macroism you could have something like
"guard page for malloc region allocated from foo.c, line 327 violated"
(in the efence port, not the default malloc(), of course)
I think I could implement this, but I'd like a reality check first.
What did I forget?
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/
BSD User Group Hamburg, Germany http://www.bsdhh.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000119094523.A79669>