From owner-freebsd-threads@FreeBSD.ORG Mon May 13 11:06:53 2013 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 068839E8 for ; Mon, 13 May 2013 11:06:53 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id ED037859 for ; Mon, 13 May 2013 11:06:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4DB6qgC076032 for ; Mon, 13 May 2013 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4DB6qoh076030 for freebsd-threads@FreeBSD.org; Mon, 13 May 2013 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 13 May 2013 11:06:52 GMT Message-Id: <201305131106.r4DB6qoh076030@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 11:06:53 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o threa/168417 threads pthread_getcpuclockid() does not work to specification o threa/163512 threads libc defaults to single threaded o threa/160708 threads possible security problem with RLIMIT_VMEM o threa/150959 threads [libc] Stub pthread_once in libc should call _libc_onc o threa/148515 threads Memory / syslog strangeness in FreeBSD 8.x ( possible o threa/141721 threads rtprio(1): (id|rt)prio priority resets when new thread o threa/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 o threa/128922 threads threads hang with xorg running o threa/122923 threads 'nice' does not prevent background process from steali o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/30464 threads [patch] pthread mutex attributes -- pshared 17 problems total. From owner-freebsd-threads@FreeBSD.ORG Tue May 14 09:52:16 2013 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D8B40CC9 for ; Tue, 14 May 2013 09:52:16 +0000 (UTC) (envelope-from phk@freebsd.org) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A52B3E84 for ; Tue, 14 May 2013 09:52:16 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 36E1B89FC9 for ; Tue, 14 May 2013 09:52:10 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.6/8.14.6) with ESMTP id r4E9q94x079160 for ; Tue, 14 May 2013 09:52:10 GMT (envelope-from phk@freebsd.org) To: threads@freebsd.org Subject: pthread_key_create() should avoid key#0 From: Poul-Henning Kamp Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 14 May 2013 09:52:09 +0000 Message-ID: <79159.1368525129@critter.freebsd.dk> X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 09:52:16 -0000 I think this patch would be a good idea, it avoids allocing a thread specific key with numeric value zero, which helps expose cases where a key hasn't been allocated in the first place. Index: libkse/thread/thr_spec.c =================================================================== --- libkse/thread/thr_spec.c (revision 248293) +++ libkse/thread/thr_spec.c (working copy) @@ -59,7 +59,7 @@ /* Lock the key table: */ THR_LOCK_ACQUIRE(curthread, &_keytable_lock); - for (i = 0; i < PTHREAD_KEYS_MAX; i++) { + for (i = 1; i < PTHREAD_KEYS_MAX; i++) { if (_thread_keytable[i].allocated == 0) { _thread_keytable[i].allocated = 1; @@ -84,7 +84,7 @@ struct pthread *curthread = _get_curthread(); int ret = 0; - if ((unsigned int)key < PTHREAD_KEYS_MAX) { + if (key > 0 && (unsigned int)key < PTHREAD_KEYS_MAX) { /* Lock the key table: */ THR_LOCK_ACQUIRE(curthread, &_keytable_lock); Index: libthr/thread/thr_spec.c =================================================================== --- libthr/thread/thr_spec.c (revision 248293) +++ libthr/thread/thr_spec.c (working copy) @@ -61,7 +61,7 @@ /* Lock the key table: */ THR_LOCK_ACQUIRE(curthread, &_keytable_lock); - for (i = 0; i < PTHREAD_KEYS_MAX; i++) { + for (i = 1; i < PTHREAD_KEYS_MAX; i++) { if (_thread_keytable[i].allocated == 0) { _thread_keytable[i].allocated = 1; @@ -86,7 +86,7 @@ struct pthread *curthread = _get_curthread(); int ret = 0; - if ((unsigned int)key < PTHREAD_KEYS_MAX) { + if (key > 0 && (unsigned int)key < PTHREAD_KEYS_MAX) { /* Lock the key table: */ THR_LOCK_ACQUIRE(curthread, &_keytable_lock); -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-threads@FreeBSD.ORG Wed May 15 09:06:15 2013 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0EF87470; Wed, 15 May 2013 09:06:15 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 01579A33; Wed, 15 May 2013 09:06:15 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4F96DYK084352; Wed, 15 May 2013 09:06:14 GMT (envelope-from davidxu@freebsd.org) Message-ID: <51935024.3080107@freebsd.org> Date: Wed, 15 May 2013 17:06:44 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130416 Thunderbird/17.0.5 MIME-Version: 1.0 To: Poul-Henning Kamp Subject: Re: pthread_key_create() should avoid key#0 References: <79159.1368525129@critter.freebsd.dk> In-Reply-To: <79159.1368525129@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 09:06:15 -0000 On 2013/05/14 17:52, Poul-Henning Kamp wrote: > > I think this patch would be a good idea, it avoids allocing > a thread specific key with numeric value zero, which helps > expose cases where a key hasn't been allocated in the first > place. > > > Index: libkse/thread/thr_spec.c > =================================================================== > --- libkse/thread/thr_spec.c (revision 248293) > +++ libkse/thread/thr_spec.c (working copy) > @@ -59,7 +59,7 @@ > > /* Lock the key table: */ > THR_LOCK_ACQUIRE(curthread, &_keytable_lock); > - for (i = 0; i < PTHREAD_KEYS_MAX; i++) { > + for (i = 1; i < PTHREAD_KEYS_MAX; i++) { > > if (_thread_keytable[i].allocated == 0) { > _thread_keytable[i].allocated = 1; > @@ -84,7 +84,7 @@ > struct pthread *curthread = _get_curthread(); > int ret = 0; > > - if ((unsigned int)key < PTHREAD_KEYS_MAX) { > + if (key > 0 && (unsigned int)key < PTHREAD_KEYS_MAX) { > /* Lock the key table: */ > THR_LOCK_ACQUIRE(curthread, &_keytable_lock); > > Index: libthr/thread/thr_spec.c > =================================================================== > --- libthr/thread/thr_spec.c (revision 248293) > +++ libthr/thread/thr_spec.c (working copy) > @@ -61,7 +61,7 @@ > > /* Lock the key table: */ > THR_LOCK_ACQUIRE(curthread, &_keytable_lock); > - for (i = 0; i < PTHREAD_KEYS_MAX; i++) { > + for (i = 1; i < PTHREAD_KEYS_MAX; i++) { > > if (_thread_keytable[i].allocated == 0) { > _thread_keytable[i].allocated = 1; > @@ -86,7 +86,7 @@ > struct pthread *curthread = _get_curthread(); > int ret = 0; > > - if ((unsigned int)key < PTHREAD_KEYS_MAX) { > + if (key > 0 && (unsigned int)key < PTHREAD_KEYS_MAX) { > /* Lock the key table: */ > THR_LOCK_ACQUIRE(curthread, &_keytable_lock); > > while key#0 is avoided, I would like to see we still support PTHREAD_KEYS_MAX keys. I am working on it. From owner-freebsd-threads@FreeBSD.ORG Wed May 15 21:19:08 2013 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0F9BB37B for ; Wed, 15 May 2013 21:19:08 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) by mx1.freebsd.org (Postfix) with ESMTP id CDCD4BF1 for ; Wed, 15 May 2013 21:19:07 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 9774F12013B; Wed, 15 May 2013 23:18:51 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 7F24528493; Wed, 15 May 2013 23:18:51 +0200 (CEST) Date: Wed, 15 May 2013 23:18:51 +0200 From: Jilles Tjoelker To: Radio =?utf-8?B?bcWCb2R5Y2ggYmFuZHl0w7N3?= Subject: Re: Getting ENOMEM with pthread_mutex_init Message-ID: <20130515211851.GA29110@stack.nl> References: <5184F113.805@o2.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5184F113.805@o2.pl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 21:19:08 -0000 On Sat, May 04, 2013 at 01:29:23PM +0200, Radio młodych bandytów wrote: > I'm having troubles that I seem unable to resolve. > My programs creates and destroys mutexes repeatably (and, obviously, > uses them in between). Around the 60th lock created, I always get ENOMEM. > I have free memory, lots of it. All locks get released properly. > The relevant pieces of code: > #define MUTEX pthread_mutex_t > inline MUTEX create_mutex() > { > MUTEX mutex; > int ret = pthread_mutex_init(&mutex, NULL); > if(ret != 0) > throw std::runtime_error("Failed to create a mutex"); > return mutex; > } > inline void destroy_mutex(MUTEX *mutex) > { > int ret = pthread_mutex_destroy(mutex); > if(ret != 0) > throw std::runtime_error("Failed to destroy a mutex"); > } > Scheduler::Scheduler(char* in, > char* out, > BlockInfo* metadata, > size_t isize, > size_t block_size, > size_t iters, > size_t min_work_size) : > in(in), > current_in(in), > out(out), > current_out(out), > metadata(metadata), > current_metadata(metadata), > size(isize), > size_left(isize), > block_size(block_size), > iters_left(iters) > { > lock = create_mutex(); > work_size = (min_work_size / block_size) * block_size; > if (work_size < min_work_size) > work_size += block_size; > } > Scheduler::~Scheduler() > { > destroy_mutex(&lock); > } > Any suggestions? It is probably not the cause of your problem but using a copy of a pthread_mutex_t for synchronization is not allowed. pthread_mutex_init() should be called on the pthread_mutex_t that is part of the Scheduler. -- Jilles Tjoelker From owner-freebsd-threads@FreeBSD.ORG Fri May 17 18:47:41 2013 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0D00B722 for ; Fri, 17 May 2013 18:47:41 +0000 (UTC) (envelope-from radiomlodychbandytow@o2.pl) Received: from moh3-ve3.go2.pl (moh3-ve3.go2.pl [193.17.41.87]) by mx1.freebsd.org (Postfix) with ESMTP id C5D98F88 for ; Fri, 17 May 2013 18:47:40 +0000 (UTC) Received: from moh3-ve3.go2.pl (unknown [10.0.0.158]) by moh3-ve3.go2.pl (Postfix) with ESMTP id 7266DB5A71F for ; Fri, 17 May 2013 20:47:29 +0200 (CEST) Received: from unknown (unknown [10.0.0.74]) by moh3-ve3.go2.pl (Postfix) with SMTP for ; Fri, 17 May 2013 20:47:29 +0200 (CEST) Received: from unknown [93.175.66.185] by poczta.o2.pl with ESMTP id ESrzpU; Fri, 17 May 2013 20:47:29 +0200 Message-ID: <51967B40.9060409@o2.pl> Date: Fri, 17 May 2013 20:47:28 +0200 From: =?UTF-8?B?UmFkaW8gbcWCb2R5Y2ggYmFuZHl0w7N3?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130407 Thunderbird/17.0.5 MIME-Version: 1.0 To: Jilles Tjoelker Subject: Re: Getting ENOMEM with pthread_mutex_init References: <5184F113.805@o2.pl> <20130515211851.GA29110@stack.nl> In-Reply-To: <20130515211851.GA29110@stack.nl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-O2-Trust: 1, 37 X-O2-SPF: neutral Cc: freebsd-threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 18:47:41 -0000 On 15/05/2013 23:18, Jilles Tjoelker wrote: > On Sat, May 04, 2013 at 01:29:23PM +0200, Radio młodych bandytów wrote: >> I'm having troubles that I seem unable to resolve. >> My programs creates and destroys mutexes repeatably (and, obviously, >> uses them in between). Around the 60th lock created, I always get ENOMEM. >> I have free memory, lots of it. All locks get released properly. > >> The relevant pieces of code: > >> #define MUTEX pthread_mutex_t >> inline MUTEX create_mutex() >> { >> MUTEX mutex; >> int ret = pthread_mutex_init(&mutex, NULL); >> if(ret != 0) >> throw std::runtime_error("Failed to create a mutex"); >> return mutex; >> } > >> inline void destroy_mutex(MUTEX *mutex) >> { >> int ret = pthread_mutex_destroy(mutex); >> if(ret != 0) >> throw std::runtime_error("Failed to destroy a mutex"); >> } > >> Scheduler::Scheduler(char* in, >> char* out, >> BlockInfo* metadata, >> size_t isize, >> size_t block_size, >> size_t iters, >> size_t min_work_size) : >> in(in), >> current_in(in), >> out(out), >> current_out(out), >> metadata(metadata), >> current_metadata(metadata), >> size(isize), >> size_left(isize), >> block_size(block_size), >> iters_left(iters) >> { >> lock = create_mutex(); >> work_size = (min_work_size / block_size) * block_size; >> if (work_size < min_work_size) >> work_size += block_size; >> } >> Scheduler::~Scheduler() >> { >> destroy_mutex(&lock); >> } > >> Any suggestions? > > It is probably not the cause of your problem but using a copy of a > pthread_mutex_t for synchronization is not allowed. pthread_mutex_init() > should be called on the pthread_mutex_t that is part of the Scheduler. > Thanks for the suggestion. I just tried it and it didn't help though... -- Twoje radio