From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 26 00:48:33 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F22B216A4CE for ; Wed, 26 Jan 2005 00:48:32 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D36643D54 for ; Wed, 26 Jan 2005 00:48:30 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: by wproxy.gmail.com with SMTP id 58so482793wri for ; Tue, 25 Jan 2005 16:48:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=jL+WrM12VWrN80PkgmvFF+ZH9N8ixoYN7oy0y92CsN4R9IKbO6tmkzMQQD05Oft3ujhslfDxH11zhklTYtIuDTvMcn/pXriEwaN+sx/sTz6lV+nm2nramE9AY1l6rISsBsXrZoPo45ZCCIdtT6zj6UKkZ1fA2y/iJhUosUdowF4= Received: by 10.54.29.62 with SMTP id c62mr321629wrc; Tue, 25 Jan 2005 16:48:23 -0800 (PST) Received: by 10.54.57.76 with HTTP; Tue, 25 Jan 2005 16:48:23 -0800 (PST) Message-ID: <34cb7c84050125164896b0d03@mail.gmail.com> Date: Wed, 26 Jan 2005 00:48:23 +0000 From: Peter Edwards To: Julian Elischer In-Reply-To: <41F6C27D.3040302@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1106669661.9523.7.camel@jose.hostarica.net> <1106686056.4973.6.camel@jose.hostarica.net> <41F6C27D.3040302@elischer.org> X-Mailman-Approved-At: Wed, 26 Jan 2005 13:31:17 +0000 cc: freebsd-hackers@freebsd.org cc: Yan Yu cc: jose@hostarica.com Subject: Re: seg fault on kse_release () (fwd) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Peter Edwards List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2005 00:48:33 -0000 On Tue, 25 Jan 2005 14:04:45 -0800, Julian Elischer 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.