From owner-freebsd-threads@FreeBSD.ORG Mon Aug 28 11:09:58 2006 Return-Path: X-Original-To: freebsd-threads@FreeBSD.org Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D0A516A5F8 for ; Mon, 28 Aug 2006 11:09:58 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0BEC43E26 for ; Mon, 28 Aug 2006 11:08:44 +0000 (GMT) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k7SB8S8g071693 for ; Mon, 28 Aug 2006 11:08:28 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k7SB8RSC071688 for freebsd-threads@FreeBSD.org; Mon, 28 Aug 2006 11:08:27 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 28 Aug 2006 11:08:27 GMT Message-Id: <200608281108.k7SB8RSC071688@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2006 11:09:58 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s threa/76690 threads fork hang in child for (-lc_r & -lthr) 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/20016 threads pthreads: Cannot set scheduling timer/Cannot set virtu s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s bin/32295 threads pthread dont dequeue signals s threa/34536 threads accept() blocks other threads o kern/38549 threads the procces compiled whith pthread stopped in pthread_ s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/49087 threads Signals lost in programs linked with libc_r s kern/64313 threads FreeBSD (OpenBSD) pthread implicit set/unset O_NONBLOC o threa/70975 threads unexpected and unreliable behaviour when using SYSV se o threa/72353 threads Assertion fails in /usr/src/lib/libpthread/sys/lock.c, o threa/72429 threads threads blocked in stdio (fgets, etc) are not cancella o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag s threa/76694 threads fork cause hang in dup()/close() function in child (-l o threa/79683 threads svctcp_create() fails if multiple threads call at the o threa/80435 threads panic on high loads o threa/83914 threads [libc] popen() doesn't work in static threaded program s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/85160 threads [libthr] [patch] libobjc + libpthread/libthr crash pro p threa/89262 threads [kernel] [patch] multi-threaded process hangs in kerne o threa/90278 threads libthr, ULE and -current produces >100% WCPU with apac o kern/91266 threads [threads] Trying sleep, but thread marked as sleeping s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc f threa/98256 threads gnome-system-monitor core dumps from pthread_testcance s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r o threa/101323 threads fork(2) in threaded programs broken. o threa/101355 threads threaded application spents too much time in _umtx_op 30 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19247 threads uthread_sigaction.c does not do anything wrt SA_NOCLDW s kern/22190 threads A threaded read(2) from a socketpair(2) fd can sometim s threa/30464 threads pthread mutex attributes -- pshared s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/69020 threads pthreads library leaks _gc_mutex o threa/74180 threads KSE problem. Applications those riched maximum possibl o threa/79887 threads [patch] freopen() isn't thread-safe o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/81534 threads [libc_r] [patch] libc_r close() will fail on any fd ty 10 problems total. From owner-freebsd-threads@FreeBSD.ORG Wed Aug 30 14:23:06 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81BB016A4E7; Wed, 30 Aug 2006 14:23:06 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16BB243DA2; Wed, 30 Aug 2006 14:22:56 +0000 (GMT) (envelope-from avg@icyb.net.ua) Received: from [212.40.38.87] (oddity-e.topspin.kiev.ua [212.40.38.87]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA23160; Wed, 30 Aug 2006 17:22:52 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <44F59F3C.3040303@icyb.net.ua> Date: Wed, 30 Aug 2006 17:22:52 +0300 From: Andriy Gapon User-Agent: Thunderbird 1.5.0.5 (X11/20060801) MIME-Version: 1.0 To: freebsd-threads@freebsd.org, ace-users@cse.wustl.edu Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: Sergey Matveychuk Subject: ace/freebsd: THR_NEW_LWP problem with libpthread/pthread_setconcurrency X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2006 14:23:06 -0000 ACE VERSION: 5.5.1 (from FreeBSD port: ace-5.5.1) HOST MACHINE and OPERATING SYSTEM: FreeBSD 6.1-RELEASE-p2 i386 (uniprocessor) COMPILER NAME AND VERSION (AND PATCHLEVEL): gcc version 3.4.4 [FreeBSD] 20050518 (system compiler) libpthread is used as threading library AREA/CLASS/EXAMPLE AFFECTED: ACE threads DOES THE PROBLEM AFFECT: EXECUTION - this is a run-time problem SYNOPSIS: Can not create threads with THR_NEW_LWP flag. DESCRIPTION: ACE_Thread_Manager::spawn(..., THR_NEW_LWP) fails with EAGAIN. It seems that this happens because when creating such threads ACE calls pthread_setconcurrency with incrementally increasing concurrency levels. pthread_setconcurrency of libpthread in turn seems to call kse_create() which fails with EPROCLIM. As I understand this happens because kernel does not allow to have more KSE-s per process as there are processors. This problem is quite noticeable with ACE because THR_NEW_LWP is present in default flags in many places. REPEAT BY: Running any ACE-based program that spawns threads with THR_NEW_LWP and linked to libpthead. SAMPLE FIX/WORKAROUND: Straightforward workaround is to explicitly pass thread flags everywhere and not use THR_NEW_LWP. Maybe this could be patched in ACE sources as a part of FreeBSD port patch step. IMHO, better fixes would be: 1. make ACE_Thread_Manager::spawn() more robust with respect to pthread_setconcurrency() failing with EAGAIN. 2. make FreeBSD libpthread dumb-happy in pthread_setconcurrency(), i.e pretend to always succeed. AFAIK, POSIX leaves it up to implementations to interpret concurrency levels, so making any level be equivalent to default level should be OK. -- Andriy Gapon From owner-freebsd-threads@FreeBSD.ORG Wed Aug 30 14:31:39 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6705C16A4DE; Wed, 30 Aug 2006 14:31:39 +0000 (UTC) (envelope-from brian@openss7.org) Received: from gw.openss7.com (gw.openss7.com [142.179.199.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id A145743D46; Wed, 30 Aug 2006 14:31:17 +0000 (GMT) (envelope-from brian@openss7.org) Received: from ns.pigworks.openss7.net (IDENT:85NxUy40jG/pnmkz0q4mPRCJwzssz39v@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k7UEVGG09991; Wed, 30 Aug 2006 08:31:16 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k7UEVAs24535; Wed, 30 Aug 2006 08:31:10 -0600 To: brian@ns.pigworks.openss7.net Path: edtnps84!newsfeed2.telusplanet.net!newsfeed.telus.net!newsfeed.news2me.com!headwall.stanford.edu!newsreader.wustl.edu!not-for-mail From: Andriy Gapon Newsgroups: comp.soft-sys.ace Date: Wed, 30 Aug 2006 17:22:52 +0300 Organization: Washington University in St. Louis Lines: 50 Message-ID: NNTP-Posting-Host: postmark.cse.wustl.edu Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit X-Trace: newsreader.wustl.edu 1156947796 28759 128.252.166.5 (30 Aug 2006 14:23:16 GMT) X-Complaints-To: usenet@newsreader.wustl.edu NNTP-Posting-Date: Wed, 30 Aug 2006 14:23:16 +0000 (UTC) To: freebsd-threads@freebsd.org, ace-users@cse.wustl.edu X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on postmark.cse.wustl.edu X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.1.4 X-Original-To: ace-users@cse.wustl.edu Delivered-To: ace-users@cse.wustl.edu User-Agent: Thunderbird 1.5.0.5 (X11/20060801) X-BeenThere: ace-users@mail.cse.wustl.edu X-Mailman-Version: 2.1.8 Precedence: list Xref: news.telusplanet.net comp.soft-sys.ace:95828 Cc: Sergey Matveychuk Subject: [ace-users] ace/freebsd: THR_NEW_LWP problem with libpthread/pthread_setconcurrency X-BeenThere: freebsd-threads@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2006 14:31:39 -0000 ACE VERSION: 5.5.1 (from FreeBSD port: ace-5.5.1) HOST MACHINE and OPERATING SYSTEM: FreeBSD 6.1-RELEASE-p2 i386 (uniprocessor) COMPILER NAME AND VERSION (AND PATCHLEVEL): gcc version 3.4.4 [FreeBSD] 20050518 (system compiler) libpthread is used as threading library AREA/CLASS/EXAMPLE AFFECTED: ACE threads DOES THE PROBLEM AFFECT: EXECUTION - this is a run-time problem SYNOPSIS: Can not create threads with THR_NEW_LWP flag. DESCRIPTION: ACE_Thread_Manager::spawn(..., THR_NEW_LWP) fails with EAGAIN. It seems that this happens because when creating such threads ACE calls pthread_setconcurrency with incrementally increasing concurrency levels. pthread_setconcurrency of libpthread in turn seems to call kse_create() which fails with EPROCLIM. As I understand this happens because kernel does not allow to have more KSE-s per process as there are processors. This problem is quite noticeable with ACE because THR_NEW_LWP is present in default flags in many places. REPEAT BY: Running any ACE-based program that spawns threads with THR_NEW_LWP and linked to libpthead. SAMPLE FIX/WORKAROUND: Straightforward workaround is to explicitly pass thread flags everywhere and not use THR_NEW_LWP. Maybe this could be patched in ACE sources as a part of FreeBSD port patch step. IMHO, better fixes would be: 1. make ACE_Thread_Manager::spawn() more robust with respect to pthread_setconcurrency() failing with EAGAIN. 2. make FreeBSD libpthread dumb-happy in pthread_setconcurrency(), i.e pretend to always succeed. AFAIK, POSIX leaves it up to implementations to interpret concurrency levels, so making any level be equivalent to default level should be OK. -- Andriy Gapon From owner-freebsd-threads@FreeBSD.ORG Wed Aug 30 15:19:23 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F59B16A4E0; Wed, 30 Aug 2006 15:19:23 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FD2B43D46; Wed, 30 Aug 2006 15:19:22 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.8/8.13.8/NETPLEX) with ESMTP id k7UFJGw1016129; Wed, 30 Aug 2006 11:19:16 -0400 (EDT) Date: Wed, 30 Aug 2006 11:19:16 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Andriy Gapon In-Reply-To: <44F59F3C.3040303@icyb.net.ua> Message-ID: References: <44F59F3C.3040303@icyb.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-2.0.2 (mail.ntplx.net [204.213.176.10]); Wed, 30 Aug 2006 11:19:17 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: ace-users@cse.wustl.edu, Sergey Matveychuk , freebsd-threads@freebsd.org Subject: Re: ace/freebsd: THR_NEW_LWP problem with libpthread/pthread_setconcurrency X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2006 15:19:23 -0000 On Wed, 30 Aug 2006, Andriy Gapon wrote: > > ACE VERSION: > 5.5.1 (from FreeBSD port: ace-5.5.1) > > HOST MACHINE and OPERATING SYSTEM: > FreeBSD 6.1-RELEASE-p2 i386 (uniprocessor) > > COMPILER NAME AND VERSION (AND PATCHLEVEL): > gcc version 3.4.4 [FreeBSD] 20050518 (system compiler) > libpthread is used as threading library > > AREA/CLASS/EXAMPLE AFFECTED: > ACE threads > > DOES THE PROBLEM AFFECT: > EXECUTION - this is a run-time problem > > SYNOPSIS: > Can not create threads with THR_NEW_LWP flag. > > DESCRIPTION: > ACE_Thread_Manager::spawn(..., THR_NEW_LWP) fails with EAGAIN. It seems > that this happens because when creating such threads ACE calls > pthread_setconcurrency with incrementally increasing concurrency levels. > pthread_setconcurrency of libpthread in turn seems to call kse_create() > which fails with EPROCLIM. As I understand this happens because kernel > does not allow to have more KSE-s per process as there are processors. pthread_setconcurrency() should return EAGAIN, not EPROCLIM. kse_create() may set errno to EPROCLIM, but I don't see how the code in libpthread can return anything other than EAGAIN if kse_create() fails. POSIX states that pthread_setconcurrency() can return EAGAIN, so I think ACE is at fault if it is not handling that properly. I would also think that THR_NEW_LWP should not increment the concurrency, but create a new system scope thread since that seems more in the spirit of "spawning a new thread with a new LWP". > This problem is quite noticeable with ACE because THR_NEW_LWP is present > in default flags in many places. > > REPEAT BY: > Running any ACE-based program that spawns threads with THR_NEW_LWP and > linked to libpthead. > > SAMPLE FIX/WORKAROUND: > Straightforward workaround is to explicitly pass thread flags everywhere > and not use THR_NEW_LWP. Maybe this could be patched in ACE sources as a > part of FreeBSD port patch step. > IMHO, better fixes would be: > 1. make ACE_Thread_Manager::spawn() more robust with respect to > pthread_setconcurrency() failing with EAGAIN. > 2. make FreeBSD libpthread dumb-happy in pthread_setconcurrency(), i.e > pretend to always succeed. AFAIK, POSIX leaves it up to implementations > to interpret concurrency levels, so making any level be equivalent to > default level should be OK. Yes to 1, No to 2, and the third option should be to treat THR_NEW_LWP as creating a new system scope thread. -- DE From owner-freebsd-threads@FreeBSD.ORG Wed Aug 30 15:56:11 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 10B9B16A4DF; Wed, 30 Aug 2006 15:56:11 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id C96D143D58; Wed, 30 Aug 2006 15:56:09 +0000 (GMT) (envelope-from avg@icyb.net.ua) Received: from [212.40.38.87] (oddity-e.topspin.kiev.ua [212.40.38.87]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA24866; Wed, 30 Aug 2006 18:56:02 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <44F5B512.5060708@icyb.net.ua> Date: Wed, 30 Aug 2006 18:56:02 +0300 From: Andriy Gapon User-Agent: Thunderbird 1.5.0.5 (X11/20060801) MIME-Version: 1.0 To: Daniel Eischen References: <44F59F3C.3040303@icyb.net.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ace-users@cse.wustl.edu, Sergey Matveychuk , freebsd-threads@freebsd.org Subject: Re: ace/freebsd: THR_NEW_LWP problem with libpthread/pthread_setconcurrency X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2006 15:56:11 -0000 on 30/08/2006 18:19 Daniel Eischen said the following: > On Wed, 30 Aug 2006, Andriy Gapon wrote: >> DESCRIPTION: >> ACE_Thread_Manager::spawn(..., THR_NEW_LWP) fails with EAGAIN. It seems >> that this happens because when creating such threads ACE calls >> pthread_setconcurrency with incrementally increasing concurrency levels. >> pthread_setconcurrency of libpthread in turn seems to call kse_create() >> which fails with EPROCLIM. As I understand this happens because kernel >> does not allow to have more KSE-s per process as there are processors. > > pthread_setconcurrency() should return EAGAIN, not EPROCLIM. kse_create() > may set errno to EPROCLIM, but I don't see how the code in libpthread > can return anything other than EAGAIN if kse_create() fails. That's exactly what I actually was trying to say, sorry for unclear wording. > POSIX states that pthread_setconcurrency() can return EAGAIN, so I > think ACE is at fault if it is not handling that properly. I > would also think that THR_NEW_LWP should not increment the > concurrency, but create a new system scope thread since that > seems more in the spirit of "spawning a new thread with a new > LWP". Yes, indeed, it seems like a good approach, at least for FreeBSD+libpthread. On the other hand, ACE also defines the following thread flags: THR_SCOPE_SYSTEM, THR_SCOPE_PROCESS. The whole THR_NEW_LWP seems to be inspired by Solaris threads (of old?): http://docs.sun.com/app/docs/doc/805-5080/6j4q7emhv?a=view THR_NEW_LWP--Increases the concurrency level for unbound threads by one. The effect is similar to incrementing concurrency by one with thr_setconcurrency(3T), although THR_NEW_LWP does not affect the level set through the thr_setconcurrency() function. Typically, THR_NEW_LWP adds a new LWP to the pool of LWPs running unbound threads. >> SAMPLE FIX/WORKAROUND: >> Straightforward workaround is to explicitly pass thread flags everywhere >> and not use THR_NEW_LWP. Maybe this could be patched in ACE sources as a >> part of FreeBSD port patch step. >> IMHO, better fixes would be: >> 1. make ACE_Thread_Manager::spawn() more robust with respect to >> pthread_setconcurrency() failing with EAGAIN. >> 2. make FreeBSD libpthread dumb-happy in pthread_setconcurrency(), i.e >> pretend to always succeed. AFAIK, POSIX leaves it up to implementations >> to interpret concurrency levels, so making any level be equivalent to >> default level should be OK. > > Yes to 1, No to 2, and the third option should be to treat THR_NEW_LWP > as creating a new system scope thread. Yes, I also feel that ACE should not try to mimic Solaris threads THR_NEW_LWP and instead treat it as an alias for THR_SCOPE_SYSTEM (or no-flag). At least on FreeBSD. Whether this is to be done through changes in ACE itself or through a patch in the FreeBSD port, I am not sure. -- Andriy Gapon From owner-freebsd-threads@FreeBSD.ORG Wed Aug 30 16:31:40 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3ED3916A4DF; Wed, 30 Aug 2006 16:31:40 +0000 (UTC) (envelope-from brian@openss7.org) Received: from gw.openss7.com (gw.openss7.com [142.179.199.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3999B43D60; Wed, 30 Aug 2006 16:31:26 +0000 (GMT) (envelope-from brian@openss7.org) Received: from ns.pigworks.openss7.net (IDENT:YTT7Vz/9nrPnXsdSmn4lInvmS8hvKbac@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k7UGUJG13107; Wed, 30 Aug 2006 10:30:19 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k7UGUGw26247; Wed, 30 Aug 2006 10:30:16 -0600 To: brian@ns.pigworks.openss7.net Path: edtnps84!newsfeed2.telusplanet.net!newsfeed.telus.net!newsfeed.news2me.com!headwall.stanford.edu!newsreader.wustl.edu!not-for-mail From: Andriy Gapon Newsgroups: comp.soft-sys.ace Date: Wed, 30 Aug 2006 18:56:02 +0300 Organization: Washington University in St. Louis Lines: 60 Message-ID: References: <44F59F3C.3040303@icyb.net.ua> NNTP-Posting-Host: postmark.cse.wustl.edu Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: newsreader.wustl.edu 1156953375 1167 128.252.166.5 (30 Aug 2006 15:56:15 GMT) X-Complaints-To: usenet@newsreader.wustl.edu NNTP-Posting-Date: Wed, 30 Aug 2006 15:56:15 +0000 (UTC) To: Daniel Eischen X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on postmark.cse.wustl.edu X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.1.4 X-Original-To: ace-users@cse.wustl.edu Delivered-To: ace-users@cse.wustl.edu User-Agent: Thunderbird 1.5.0.5 (X11/20060801) In-Reply-To: X-BeenThere: ace-users@mail.cse.wustl.edu X-Mailman-Version: 2.1.8 Precedence: list Xref: news.telusplanet.net comp.soft-sys.ace:95835 Cc: ace-users@cse.wustl.edu, freebsd-threads@freebsd.org, Sergey Matveychuk Subject: Re: [ace-users] ace/freebsd: THR_NEW_LWP problem with libpthread/pthread_setconcurrency X-BeenThere: freebsd-threads@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2006 16:31:40 -0000 on 30/08/2006 18:19 Daniel Eischen said the following: > On Wed, 30 Aug 2006, Andriy Gapon wrote: >> DESCRIPTION: >> ACE_Thread_Manager::spawn(..., THR_NEW_LWP) fails with EAGAIN. It seems >> that this happens because when creating such threads ACE calls >> pthread_setconcurrency with incrementally increasing concurrency levels. >> pthread_setconcurrency of libpthread in turn seems to call kse_create() >> which fails with EPROCLIM. As I understand this happens because kernel >> does not allow to have more KSE-s per process as there are processors. > > pthread_setconcurrency() should return EAGAIN, not EPROCLIM. kse_create() > may set errno to EPROCLIM, but I don't see how the code in libpthread > can return anything other than EAGAIN if kse_create() fails. That's exactly what I actually was trying to say, sorry for unclear wording. > POSIX states that pthread_setconcurrency() can return EAGAIN, so I > think ACE is at fault if it is not handling that properly. I > would also think that THR_NEW_LWP should not increment the > concurrency, but create a new system scope thread since that > seems more in the spirit of "spawning a new thread with a new > LWP". Yes, indeed, it seems like a good approach, at least for FreeBSD+libpthread. On the other hand, ACE also defines the following thread flags: THR_SCOPE_SYSTEM, THR_SCOPE_PROCESS. The whole THR_NEW_LWP seems to be inspired by Solaris threads (of old?): http://docs.sun.com/app/docs/doc/805-5080/6j4q7emhv?a=view THR_NEW_LWP--Increases the concurrency level for unbound threads by one. The effect is similar to incrementing concurrency by one with thr_setconcurrency(3T), although THR_NEW_LWP does not affect the level set through the thr_setconcurrency() function. Typically, THR_NEW_LWP adds a new LWP to the pool of LWPs running unbound threads. >> SAMPLE FIX/WORKAROUND: >> Straightforward workaround is to explicitly pass thread flags everywhere >> and not use THR_NEW_LWP. Maybe this could be patched in ACE sources as a >> part of FreeBSD port patch step. >> IMHO, better fixes would be: >> 1. make ACE_Thread_Manager::spawn() more robust with respect to >> pthread_setconcurrency() failing with EAGAIN. >> 2. make FreeBSD libpthread dumb-happy in pthread_setconcurrency(), i.e >> pretend to always succeed. AFAIK, POSIX leaves it up to implementations >> to interpret concurrency levels, so making any level be equivalent to >> default level should be OK. > > Yes to 1, No to 2, and the third option should be to treat THR_NEW_LWP > as creating a new system scope thread. Yes, I also feel that ACE should not try to mimic Solaris threads THR_NEW_LWP and instead treat it as an alias for THR_SCOPE_SYSTEM (or no-flag). At least on FreeBSD. Whether this is to be done through changes in ACE itself or through a patch in the FreeBSD port, I am not sure. -- Andriy Gapon From owner-freebsd-threads@FreeBSD.ORG Fri Sep 1 14:16:36 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FBA416A4E2; Fri, 1 Sep 2006 14:16:36 +0000 (UTC) (envelope-from vovk@km.ua) Received: from fido.km.ua (fido.km.ua [195.46.36.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A749943D49; Fri, 1 Sep 2006 14:16:35 +0000 (GMT) (envelope-from vovk@km.ua) Received: from eto.tormoz.net (eto.tormoz.net [195.46.36.15]) (authenticated bits=0) by fido.km.ua (8.13.6/8.13.6/add-fido.auth) with ESMTP id k81EGVRw052094; Fri, 1 Sep 2006 17:16:33 +0300 (EEST) (envelope-from vovk@km.ua) From: Vyacheslav Vovk To: freebsd-stable@freebsd.org Date: Fri, 1 Sep 2006 17:16:29 +0300 User-Agent: KMail/1.9.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609011716.30749.vovk@km.ua> X-Virus-Scanned: by amavisd-new Cc: freebsd-threads@freebsd.org Subject: panic: vm_thread_new: kstack allocation failed X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2006 14:16:36 -0000 Hi, Search on conferences has not given the answer, only the reference to similar problems (http://lists.freebsd.org/pipermail/freebsd-stable/2006-June/026010.html), therefore I shall ask here. As well as in the above-stated reference there is highly loaded machine, which periodically panic since 5.4-RELEASE. #kgdb kernel.debug /var/crash/vmcore.4 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undef ined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: panic: vm_thread_new: kstack allocation failed cpuid = 3 Uptime: 7d4h30m58s Dumping 2046 MB (2 chunks) chunk 0: 1MB (158 pages) ... ok chunk 1: 2046MB (523744 pages) 2030 2014 1998 1982 1966 1950 1934 1918 1902 188 6 1870 1854 1838 1822 1806 1790 1774 1758 1742 1726 1710 1694 1678 1662 1646 1630 1614 1598 1582 1566 1550 1534 1518 1502 1486 1470 1454 1438 1422 1406 1390 1374 1358 1342 1326 1310 1294 1278 1262 1246 1230 1214 1198 1182 1166 1150 1134 1118 1 102 1086 1070 1054 1038 1022 1006 990 974 958 942 926 910 894 878 862 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 1 58 142 126 110 94 78 62 46 30 14 0 doadump () at pcpu.h:165 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc04e533d in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc04e5665 in panic ( fmt=0xc0679bd6 "vm_thread_new: kstack allocation failed") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc05f26bb in vm_thread_new (td=0xd2221780, pages=2) at /usr/src/sys/vm/vm_glue.c:347 #4 0xc04ef7c7 in thread_init (mem=0xd2221780, size=372, flags=259) at /usr/src/sys/kern/kern_thread.c:185 #5 0xc05eb29e in slab_zalloc (zone=0xc0c511e0, wait=259) at /usr/src/sys/vm/uma_core.c:861 #6 0xc05ec890 in uma_zone_slab (zone=0xc0c511e0, flags=3) at /usr/src/sys/vm/uma_core.c:2025 #7 0xc05ecac0 in uma_zalloc_bucket (zone=0xc0c511e0, flags=3) at /usr/src/sys/vm/uma_core.c:2134 #8 0xc05ec722 in uma_zalloc_arg (zone=0xc0c511e0, udata=0x0, flags=2) at /usr/src/sys/vm/uma_core.c:1942 #9 0xc04efcb7 in thread_alloc () at uma.h:275 #10 0xc04d3596 in thread_alloc_spare (td=0xd2252d80) at /usr/src/sys/kern/kern_kse.c:1046 #11 0xc04d40e6 in thread_userret (td=0xd2252d80, frame=0xffab5d38) at /usr/src/sys/kern/kern_kse.c:1437 #12 0xc05061da in userret (td=0xd2252d80, frame=0xffab5d38, oticks=0) at /usr/src/sys/kern/subr_trap.c:120 #13 0xc04cecfa in fork_return (td=0xd2252d80, frame=0xffab5d38) at /usr/src/sys/kern/kern_fork.c:834 #14 0xc04cec21 in fork_exit (callout=0xc04cece8 , arg=0xd2252d80, frame=0xffab5d38) at /usr/src/sys/kern/kern_fork.c:805 #15 0xc062909c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208 (kgdb) f 3 #3 0xc05f26bb in vm_thread_new (td=0xd2221780, pages=2) at /usr/src/sys/vm/vm_glue.c:347 347 panic("vm_thread_new: kstack allocation failed"); (kgdb) l 342 * Get a kernel virtual address for this thread's kstack. 343 */ 344 ks = kmem_alloc_nofault(kernel_map, 345 (pages + KSTACK_GUARD_PAGES) * PAGE_SIZE); 346 if (ks == 0) 347 panic("vm_thread_new: kstack allocation failed"); 348 if (KSTACK_GUARD_PAGES != 0) { 349 pmap_qremove(ks, KSTACK_GUARD_PAGES); 350 ks += KSTACK_GUARD_PAGES * PAGE_SIZE; 351 } (kgdb) i loc ksobj = 0xd1b25a50 ks = 0 m = 0x0 ma = {0xc1abe450, 0xc26e8498, 0xd201ce20, 0xffab5b90, 0xc05eca91, 0xc0c61d20, 0xd201ce20, 0x102, 0x80, 0x0, 0xc0c61db0, 0xc0c61d20, 0x0, 0xd0d038c0, 0xc05ec539, 0xffab5bac, 0xffab5bac, 0xc04da4b3, 0x40, 0x2, 0xffab5bd0, 0xc04da579, 0xc0699c00, 0x40, 0x2, 0xc0c6caa0, 0xd2221600, 0x0, 0xc04f800a, 0xd2221754, 0x20, 0xd2221600} i = -769517696 (kgdb) #dmesg Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.1-STABLE #5: Sat Jul 29 19:57:16 EEST 2006 vovk@ic.km.ua:/usr/obj/usr/src/sys/stella acpi_alloc_wakeup_handler: can't alloc wake memory ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Features2=0x4400> Logical CPUs per core: 2 real memory = 2146304000 (2046 MB) avail memory = 2096357376 (1999 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0: Changing APIC ID to 4 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe8000000-0xefffffff at device 0.0 o n pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pcib2: at device 3.0 on pci0 pci2: on pcib2 em0: port 0x9000-0x901f m em 0xf7020000-0xf703ffff,0xf7000000-0xf701ffff irq 18 at device 1.0 on pci2 em0: Ethernet address: 00:11:2f:10:3e:14 pcib3: at device 28.0 on pci0 pci3: on pcib3 aac0: mem 0xf0000000-0xf3ffffff irq 25 at device 3.0 on pci3 aac0: New comm. interface enabled aac0: Adaptec Raid Controller 2.0.0-1 aacp0: on aac0 aacp1: on aac0 pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.4 (no driver attached) pci0: at device 29.5 (no driver attached) pci0: at device 29.7 (no driver attached) pcib4: at device 30.0 on pci0 pci4: on pcib4 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x 376,0xf000-0xf00f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 ichsmb0: port 0x500-0x51f irq 17 at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] smbus0: on ichsmb0 acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: port 0x378-0x37f,0x778-0x77b irq 7 on acpi 0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xca7ff,0xcc000-0xd07ff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, defau lt to deny, logging disabled aacd0: on aac0 aacd0: 69974MB (143307008 sectors) pass0 at aacp0 bus 0 target 0 lun 0 pass0: Fixed unknown SCSI-3 device pass0: 3.300MB/s transfers pass1 at aacp0 bus 0 target 1 lun 0 pass1: Fixed unknown SCSI-3 device pass1: 3.300MB/s transfers SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! Trying to mount root from ufs:/dev/aacd0s1a WARNING: / was not properly dismounted Periodically I update system up to -STABLE, in hope for correction of the problem, however no changes are present. Any ideas for a work around? -- wbr, slava [vovk-uanic] From owner-freebsd-threads@FreeBSD.ORG Fri Sep 1 16:27:17 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA6D216A4DA; Fri, 1 Sep 2006 16:27:17 +0000 (UTC) (envelope-from prvs=julian=392b3a9d5@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE94143D58; Fri, 1 Sep 2006 16:27:16 +0000 (GMT) (envelope-from prvs=julian=392b3a9d5@elischer.org) Received: from unknown (HELO [192.168.2.3]) ([10.251.60.33]) by a50.ironport.com with ESMTP; 01 Sep 2006 09:27:16 -0700 Message-ID: <44F85F63.5020508@elischer.org> Date: Fri, 01 Sep 2006 09:27:15 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vyacheslav Vovk References: <200609011716.30749.vovk@km.ua> In-Reply-To: <200609011716.30749.vovk@km.ua> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, freebsd-threads@freebsd.org Subject: Re: panic: vm_thread_new: kstack allocation failed X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2006 16:27:18 -0000 Vyacheslav Vovk wrote: can you see how many threads thre are in the system? I think you will have to extract this information frome the zone allocator. I just realised there is no effective limit on kernel threads in the system. probably one could cause this with a fork bomb appoach using forks and thread creation. >Unread portion of the kernel message buffer: >panic: vm_thread_new: kstack allocation failed >cpuid = 3 >Uptime: 7d4h30m58s > > > From owner-freebsd-threads@FreeBSD.ORG Fri Sep 1 19:07:39 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8C3C16A4DA; Fri, 1 Sep 2006 19:07:39 +0000 (UTC) (envelope-from vovk@km.ua) Received: from fido.km.ua (fido.km.ua [195.46.36.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B84343D58; Fri, 1 Sep 2006 19:07:38 +0000 (GMT) (envelope-from vovk@km.ua) Received: from [10.0.0.8] (id.km.ua [195.46.36.18]) (authenticated bits=0) by fido.km.ua (8.13.6/8.13.6/add-fido.auth) with ESMTP id k81J7SjH026337; Fri, 1 Sep 2006 22:07:29 +0300 (EEST) (envelope-from vovk@km.ua) Date: Fri, 1 Sep 2006 22:07:57 +0300 From: Vyacheslav Vovk X-Mailer: The Bat! (v3.81.06 Beta) Professional X-Priority: 3 (Normal) Message-ID: <1154543100.20060901220757@km.ua> To: Julian Elischer In-Reply-To: <44F85F63.5020508@elischer.org> References: <200609011716.30749.vovk@km.ua> <44F85F63.5020508@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Cc: freebsd-stable@freebsd.org, freebsd-threads@freebsd.org Subject: Re[2]: panic: vm_thread_new: kstack allocation failed X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vyacheslav Vovk List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2006 19:07:40 -0000 Hello Julian, Friday, September 1, 2006, 7:27:15 PM, you wrote: > Vyacheslav Vovk wrote: > can you see how many threads thre are in the system? > I think you will have to extract this information frome the zone allocator. how to do it practically? > I just realised there is no effective limit on kernel threads in the system. > probably one could cause this with a fork bomb appoach using forks and > thread creation. what can be staying in this fork bomb? -- wbr, slava [vovk-uanic] From owner-freebsd-threads@FreeBSD.ORG Fri Sep 1 19:18:31 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 620BC16A4E2 for ; Fri, 1 Sep 2006 19:18:31 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id D64E243D6A for ; Fri, 1 Sep 2006 19:18:14 +0000 (GMT) (envelope-from kip.macy@gmail.com) Received: by nz-out-0102.google.com with SMTP id 13so609858nzn for ; Fri, 01 Sep 2006 12:18:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=R5uENW+9T2Pg4WnZtHV5aIGcsTYt63NiqkRJ73z8JHm8JKMKGwY4Klepaq6ig3HjaEI4KE6X/GtmrcqPzrM1z33Kb31T6dzvD2rHFGrQphK8lQVerntcdngmrEX6tjQ7IClMATbfnwUBrJtji5/OGVAZmHT3J82fqVoPTlMKon4= Received: by 10.65.59.20 with SMTP id m20mr3191472qbk; Fri, 01 Sep 2006 12:18:13 -0700 (PDT) Received: by 10.65.224.1 with HTTP; Fri, 1 Sep 2006 12:18:13 -0700 (PDT) Message-ID: Date: Fri, 1 Sep 2006 12:18:13 -0700 From: "Kip Macy" To: "Julian Elischer" In-Reply-To: <44F85F63.5020508@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200609011716.30749.vovk@km.ua> <44F85F63.5020508@elischer.org> Cc: freebsd-stable@freebsd.org, freebsd-threads@freebsd.org Subject: Re: panic: vm_thread_new: kstack allocation failed X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2006 19:18:31 -0000 I've seen this when running stress2 with a large number of incarnations. Why don't we return an error to the user? -Kip On 9/1/06, Julian Elischer wrote: > Vyacheslav Vovk wrote: > > can you see how many threads thre are in the system? > I think you will have to extract this information frome the zone allocator. > > I just realised there is no effective limit on kernel threads in the system. > probably one could cause this with a fork bomb appoach using forks and > thread creation. > > >Unread portion of the kernel message buffer: > >panic: vm_thread_new: kstack allocation failed > >cpuid = 3 > >Uptime: 7d4h30m58s > > > > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-threads@FreeBSD.ORG Fri Sep 1 19:30:19 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B08B16A4E2; Fri, 1 Sep 2006 19:30:19 +0000 (UTC) (envelope-from vovk@km.ua) Received: from fido.km.ua (fido.km.ua [195.46.36.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E76243DE0; Fri, 1 Sep 2006 19:29:30 +0000 (GMT) (envelope-from vovk@km.ua) Received: from [10.0.0.8] (id.km.ua [195.46.36.18]) (authenticated bits=0) by fido.km.ua (8.13.6/8.13.6/add-fido.auth) with ESMTP id k81JTPK7033682; Fri, 1 Sep 2006 22:29:26 +0300 (EEST) (envelope-from vovk@km.ua) Date: Fri, 1 Sep 2006 22:29:54 +0300 From: Vyacheslav Vovk X-Mailer: The Bat! (v3.81.06 Beta) Professional X-Priority: 3 (Normal) Message-ID: <693466338.20060901222954@km.ua> To: freebsd-stable@freebsd.org, freebsd-threads@freebsd.org In-Reply-To: <1154543100.20060901220757@km.ua> References: <200609011716.30749.vovk@km.ua> <44F85F63.5020508@elischer.org> <1154543100.20060901220757@km.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Cc: Subject: Re[3]: panic: vm_thread_new: kstack allocation failed X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vyacheslav Vovk List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2006 19:30:19 -0000 Hello Vyacheslav, Friday, September 1, 2006, 10:07:57 PM, you wrote: > Hello Julian, > Friday, September 1, 2006, 7:27:15 PM, you wrote: >> Vyacheslav Vovk wrote: >> can you see how many threads thre are in the system? >> I think you will have to extract this information frome the zone allocator. > how to do it practically? >> I just realised there is no effective limit on kernel threads in the system. >> probably one could cause this with a fork bomb appoach using forks and >> thread creation. > what can be staying in this fork bomb? soft running on this system [19] [root@ic]~#ls /usr/local/etc/rc.d/ apache.sh mysql-server snmpd squid innd radiusd.sh snmptrapd [20] [root@ic]~#cat /etc/libmap.conf cat: /etc/libmap.conf: No such file or directory -- wbr, slava [vovk-uanic] From owner-freebsd-threads@FreeBSD.ORG Fri Sep 1 20:03:38 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C8B216A4DA; Fri, 1 Sep 2006 20:03:38 +0000 (UTC) (envelope-from prvs=julian=392b3a9d5@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 203D543D45; Fri, 1 Sep 2006 20:03:37 +0000 (GMT) (envelope-from prvs=julian=392b3a9d5@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 01 Sep 2006 13:03:37 -0700 Message-ID: <44F89218.9050400@elischer.org> Date: Fri, 01 Sep 2006 13:03:36 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kip Macy References: <200609011716.30749.vovk@km.ua> <44F85F63.5020508@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, freebsd-threads@freebsd.org Subject: Re: panic: vm_thread_new: kstack allocation failed X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2006 20:03:38 -0000 Kip Macy wrote: > I've seen this when running stress2 with a large number of > incarnations. Why don't we return an error to the user? programmer ENOTIME patch welcome! > > -Kip > > On 9/1/06, Julian Elischer wrote: > >> Vyacheslav Vovk wrote: >> >> can you see how many threads thre are in the system? >> I think you will have to extract this information frome the zone >> allocator. >> >> I just realised there is no effective limit on kernel threads in the >> system. >> probably one could cause this with a fork bomb appoach using forks and >> thread creation. >> >> >Unread portion of the kernel message buffer: >> >panic: vm_thread_new: kstack allocation failed >> >cpuid = 3 >> >Uptime: 7d4h30m58s >> > >> > >> > >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to >> "freebsd-stable-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to > "freebsd-threads-unsubscribe@freebsd.org" From owner-freebsd-threads@FreeBSD.ORG Fri Sep 1 20:50:46 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF9B516A512 for ; Fri, 1 Sep 2006 20:50:46 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D31843D6B for ; Fri, 1 Sep 2006 20:50:39 +0000 (GMT) (envelope-from kip.macy@gmail.com) Received: by nz-out-0102.google.com with SMTP id 13so623893nzn for ; Fri, 01 Sep 2006 13:50:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lP0NsDqZWqXZ6lr9okkGfdUAopMgR+2tdFOpjcYjmjVNSKMwU8TbTmtOfL2WIOGSHdTaw/pezaPPkg9Ytm9rfhmbmwqS7IONWDQQnoXhIXy0ipbPPcsPiqf1ZEhROVfKkik+caMwZ69eMSPezoqE2AGjtyOpRgpdixAm9bR9m38= Received: by 10.65.211.13 with SMTP id n13mr3250659qbq; Fri, 01 Sep 2006 13:50:38 -0700 (PDT) Received: by 10.65.224.1 with HTTP; Fri, 1 Sep 2006 13:50:38 -0700 (PDT) Message-ID: Date: Fri, 1 Sep 2006 13:50:38 -0700 From: "Kip Macy" To: "Julian Elischer" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200609011716.30749.vovk@km.ua> <44F85F63.5020508@elischer.org> Cc: freebsd-stable@freebsd.org, freebsd-threads@freebsd.org Subject: Re: panic: vm_thread_new: kstack allocation failed X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2006 20:50:46 -0000 On closer inspection this means that we've run out of KVA. In principle it should be handled more gracefully, but the 1GB KVA limitation is really a 32-bit artifact. It might be worth wading through the kernel memory allocations to see if a subsystem has gone beserk. -Kip On 9/1/06, Kip Macy wrote: > I've seen this when running stress2 with a large number of > incarnations. Why don't we return an error to the user? > > -Kip > > On 9/1/06, Julian Elischer wrote: > > Vyacheslav Vovk wrote: > > > > can you see how many threads thre are in the system? > > I think you will have to extract this information frome the zone allocator. > > > > I just realised there is no effective limit on kernel threads in the system. > > probably one could cause this with a fork bomb appoach using forks and > > thread creation. > > > > >Unread portion of the kernel message buffer: > > >panic: vm_thread_new: kstack allocation failed > > >cpuid = 3 > > >Uptime: 7d4h30m58s > > > > > > > > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > >