From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 25 19:04:00 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 7F53E16A4CE for ; Tue, 25 Jan 2005 19:04:00 +0000 (GMT) Received: from panther.cs.ucla.edu (Panther.CS.UCLA.EDU [131.179.128.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 344EE43D2D for ; Tue, 25 Jan 2005 19:04:00 +0000 (GMT) (envelope-from yanyu@CS.UCLA.EDU) Received: from localhost (yanyu@localhost)j0PJ3wq11175; Tue, 25 Jan 2005 11:03:58 -0800 (PST) Date: Tue, 25 Jan 2005 11:03:58 -0800 (PST) From: Yan Yu To: Peter Edwards In-Reply-To: <34cb7c840501250728a1ecb9b@mail.gmail.com> Message-ID: References: <34cb7c840501250728a1ecb9b@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Wed, 26 Jan 2005 13:31:17 +0000 cc: freebsd-hackers@freebsd.org Subject: Re: seg fault on kse_release () (fwd) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2005 19:04:00 -0000 HI, Thanks for all the info! > kse_release() in this context isn't kernel code, its from libpthread. > The kernel equivalent of a segfault would generate a panic. > > Just in case: you're attempting to allocate more than 5000 threads: > Each one from main tries to recursively create 5000 more, and so on. > Also note that because you are not calling pthread_join() (and aren't > creating "detatched" threads) you're leaking memory as each thread > exits. that is a good point.. in this specific case, at the end of my thread, it is a while (1) loop, so normally the thread i am creating will never exit, it is supposed to be a malicious prog to STRESS the system.. I will try the things you are suggesting, keep you posted. thanks for all the pointers! yan > Now, if it's actually dying on the 5000ish thread mark: > > Also, each thread will allocate a stack + some extra overhead. The > default stack size is 64K. That means you're allocating 312MB of stack > space, and 5000 x some constant on top of that. That might exceed your > process's data segment size (though I'm not sure that limit is imposed > entirely by FreeBSDs malloc: I suspect it isn't) > > It's certainly a lot of memory for a 32-bit process. You could try > increasing your data segment size with ulimit(1), or decreasing the > stack size per thread with > pthread_attr_init/pthread_attr_setstacksize(). > > Also: gdb for corefiles may have been broken in 5.3, showing the > backtrace of the wrong stack. (I fixed one problem post release, but > I'm not sure if it was introduced before or after. Can you either run > the program from gdb (so you debug a live process rather than a > corefile), or try updating gdb? >