From owner-freebsd-hackers Wed Jan 19 0:45:57 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from gilgamesch.bik-gmbh.de (gilgamesch.bik-gmbh.de [194.233.237.194]) by hub.freebsd.org (Postfix) with ESMTP id 8A92615263 for ; Wed, 19 Jan 2000 00:45:53 -0800 (PST) (envelope-from cracauer@gilgamesch.bik-gmbh.de) Received: (from cracauer@localhost) by gilgamesch.bik-gmbh.de (8.9.3/8.7.3) id JAA81241; Wed, 19 Jan 2000 09:45:24 +0100 (MET) Date: Wed, 19 Jan 2000 09:45:24 +0100 From: Martin Cracauer To: Matthew Dillon Cc: Iani Brankov , hackers@FreeBSD.ORG, Jason Evans Subject: Re: The stack size for a process? Message-ID: <20000119094523.A79669@cons.org> References: <200001180055.TAA17507@pcnet1.pcnet.com> <3883D1BB.391C9F0C@bulinfo.net> <20000117183902.B27689@sturm.canonware.com> <3883D60A.BA0BAF37@bulinfo.net> <200001180327.TAA18698@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <200001180327.TAA18698@apollo.backplane.com>; from Matthew Dillon on Mon, Jan 17, 2000 at 07:27:11PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 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