From owner-freebsd-threads@FreeBSD.ORG Mon Oct 27 11:07:23 2008 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB0EF1065675 for ; Mon, 27 Oct 2008 11:07:23 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B7FC38FC20 for ; Mon, 27 Oct 2008 11:07:23 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id m9RB7NKp002136 for ; Mon, 27 Oct 2008 11:07:23 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id m9RB7NjK002132 for freebsd-threads@FreeBSD.org; Mon, 27 Oct 2008 11:07:23 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 Oct 2008 11:07:23 GMT Message-Id: <200810271107.m9RB7NjK002132@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 Cc: Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org 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, 27 Oct 2008 11:07:23 -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/128180 threads pthread_cond_broadcast(3) lost wakeup o threa/127225 threads bug in lib/libthr/thread/thr_init.c o threa/126950 threads [patch] rtld(1): rtld malloc is thread-unsafe o kern/126128 threads [patch] pthread_condattr_getpshared is broken 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/118715 threads kse problem o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/116181 threads /dev/io-related io access permissions are not propagat o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat 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/101323 threads fork(2) in threaded programs broken. s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/83914 threads [libc] popen() doesn't work in static threaded program o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/80435 threads panic on high loads o threa/79887 threads [patch] freopen() isn't thread-safe o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/76694 threads fork cause hang in dup()/close() function in child (-l s threa/76690 threads fork hang in child for -lc_r o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/70975 threads [sysvipc] unexpected and unreliable behaviour when usi s threa/69020 threads pthreads library leaks _gc_mutex s threa/49087 threads Signals lost in programs linked with libc_r s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/34536 threads accept() blocks other threads s kern/32295 threads [libc_r] [patch] pthread(3) dont dequeue signals s threa/30464 threads pthread mutex attributes -- pshared s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o 39 problems total. From owner-freebsd-threads@FreeBSD.ORG Tue Oct 28 16:19:28 2008 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6E791065672 for ; Tue, 28 Oct 2008 16:19:28 +0000 (UTC) (envelope-from sbartnikowski@barkinglizards.com) Received: from pluto.phpwebhosting.com (pluto.phpwebhosting.com [69.0.209.128]) by mx1.freebsd.org (Postfix) with SMTP id 7EBA08FC1A for ; Tue, 28 Oct 2008 16:19:28 +0000 (UTC) (envelope-from sbartnikowski@barkinglizards.com) Received: (qmail 30687 invoked from network); 28 Oct 2008 15:52:42 -0000 Received: from unknown (HELO OCTOBER) (216.138.73.11) by pluto.phpwebhosting.com with SMTP; Tue, 28 Oct 2008 11:52:42 -0400 From: "Stephen Bartnikowski" To: Date: Tue, 28 Oct 2008 10:52:45 -0500 Organization: Barking Lizards Technologies Message-ID: <5B0A3FB3D06E41849325AD3EA98CAD55@OCTOBER> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ack5FTfqj+Y3z0v1SliCeTc+JtC5+w== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: deadlock in fork call? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbartnikowski@barkinglizards.com List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2008 16:19:29 -0000 Hi guys, To start, I'm not reporting a bug here. I'm trying to get an idea if I'm on the right track. Also, apologies on the lengthy email. Oh and this likely relevant. I'm running FreeBSD 6.3 RELEASE that I installed on July 21. I don't believe any updates have been performed since. I've got a deadlock situation between a fork call on the main thread and another thread. I already know I'm venturing into shady territory when I fork a multithreaded process. However, I don't have a good understanding of exactly what's going on there, which is where I'm hoping you guys can help. Stack dumps are at the bottom of this email. Idea 1: Thread #5 blows up and in its bad state is stuck on a mutex for whatever reason. Thread #1 in the fork call is attempting to reinitialize each mutex in the process space and deadlocks because Thread #5 is hosed and has one of those mutexes. Idea 2: Thread #5 blows up at the same time that Thread #1 makes the fork call. Since at this point in FreeBSD (6.3), the Giant Lock logic is still in there, and these two threads deadlock each other on pthread_mutexattr_init calls. Note that my forked process logic is followed by an execv call, although I just noticed that if execv fails for whatever reason, I'm likely doing some unsafe logging calls before that forked process quits. Any input on whether Idea 1 or Idea 2 are valid? Thank you! - Stephen Here's the main thread (#1) doing the fork call. It's blocked on that pthread_mutexattr_init call. #0 0x28109198 in pthread_sigmask () from /lib/libpthread.so.2 #1 0x28109148 in sigprocmask () from /lib/libpthread.so.2 #2 0x2811360c in pthread_mutexattr_init () from /lib/libpthread.so.2 #3 0x281062db in fork () from /lib/libpthread.so.2 #4 0x2850e04c in blt::Fork () at wrapunix.cpp:978 #5 0x08073e7b in cerebro::ModuleManager::loadModule (this=0x810af40, rModule=@0x816a200) at ModuleManager.cpp:500 #6 0x08073f54 in cerebro::ModuleManager::loadModules (this=0x810af40, mqipctok=@0x80ef134, piddir=@0x80ef124) at ModuleManager.cpp:536 #7 0x08064e26 in cerebro::Cerebro::main (this=0x80ef100, argc=4, argv=0xbfbfe9d4) at Cerebro.cpp:721 #8 0x08069e6a in main (argc=4, argv=0xbfbfe9d4) at Cerebro.cpp:1934 And here's the second (corrupted) thread (#5), that I'm 90% sure is caused by a third-party logging library, unfortunately. #0 0x28114fbf in pthread_mutexattr_init () from /lib/libpthread.so.2 #1 0x28110e29 in _pthread_mutex_trylock () from /lib/libpthread.so.2 #2 0x28112cc6 in pthread_mutex_lock () from /lib/libpthread.so.2 #3 0x2811d3f5 in __error () from /lib/libpthread.so.2 #4 0x28110e29 in _pthread_mutex_trylock () from /lib/libpthread.so.2 #5 0x28112cc6 in pthread_mutex_lock () from /lib/libpthread.so.2 #6 0x2810831a in _spinunlock () from /lib/libpthread.so.2 #7 0x289c5d22 in _UTF8_init () from /lib/libc.so.6 #8 0x28a42580 in _thread_autoinit_dummy_decl_stub () from /lib/libc.so.6 #9 0x0813c280 in ?? () #10 0xbf8fda38 in ?? () #11 0x289c5cc9 in _UTF8_init () from /lib/libc.so.6 #12 0x28a2f593 in sys_nsig () from /lib/libc.so.6 #13 0x2894e5c4 in ?? () from /usr/lib/libstdc++.so.5 #14 0xbf8fd9c8 in ?? () #15 0x2892db3d in operator delete () from /usr/lib/libstdc++.so.5 #16 0x2892db51 in operator delete () from /usr/lib/libstdc++.so.5 #17 0x288ed6fb in std::string::_Rep::_M_destroy () from /usr/lib/libstdc++.so.5 #18 0x28110e29 in _pthread_mutex_trylock () from /lib/libpthread.so.2 #19 0x2811d3f5 in __error () from /lib/libpthread.so.2 #20 0x280fa170 in ?? () #21 0x00000000 in ?? () #22 0xbf8fdb64 in ?? () #23 0x280d46fc in symlook_obj () from /libexec/ld-elf.so.1 From owner-freebsd-threads@FreeBSD.ORG Tue Oct 28 16:40:26 2008 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A8871065671 for ; Tue, 28 Oct 2008 16:40:26 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 3FB588FC16 for ; Tue, 28 Oct 2008 16:40:26 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 142F81A3C36; Tue, 28 Oct 2008 09:40:26 -0700 (PDT) Date: Tue, 28 Oct 2008 09:40:26 -0700 From: Alfred Perlstein To: Stephen Bartnikowski Message-ID: <20081028164026.GF83037@elvis.mu.org> References: <5B0A3FB3D06E41849325AD3EA98CAD55@OCTOBER> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B0A3FB3D06E41849325AD3EA98CAD55@OCTOBER> User-Agent: Mutt/1.4.2.3i Cc: freebsd-threads@freebsd.org Subject: Re: deadlock in fork call? 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: Tue, 28 Oct 2008 16:40:26 -0000 I'm pretty sure this is fixed in 6-stable. -Alfred * Stephen Bartnikowski [081028 09:19] wrote: > Hi guys, > > To start, I'm not reporting a bug here. I'm trying to get an idea if I'm on > the right track. Also, apologies on the lengthy email. > > Oh and this likely relevant. I'm running FreeBSD 6.3 RELEASE that I > installed on July 21. I don't believe any updates have been performed since. > > I've got a deadlock situation between a fork call on the main thread and > another thread. I already know I'm venturing into shady territory when I > fork a multithreaded process. However, I don't have a good understanding of > exactly what's going on there, which is where I'm hoping you guys can help. > Stack dumps are at the bottom of this email. > > Idea 1: Thread #5 blows up and in its bad state is stuck on a mutex for > whatever reason. Thread #1 in the fork call is attempting to reinitialize > each mutex in the process space and deadlocks because Thread #5 is hosed and > has one of those mutexes. > > Idea 2: Thread #5 blows up at the same time that Thread #1 makes the fork > call. Since at this point in FreeBSD (6.3), the Giant Lock logic is still in > there, and these two threads deadlock each other on pthread_mutexattr_init > calls. > > Note that my forked process logic is followed by an execv call, although I > just noticed that if execv fails for whatever reason, I'm likely doing some > unsafe logging calls before that forked process quits. > > Any input on whether Idea 1 or Idea 2 are valid? > > Thank you! > > - Stephen > > Here's the main thread (#1) doing the fork call. It's blocked on that > pthread_mutexattr_init call. > > #0 0x28109198 in pthread_sigmask () from /lib/libpthread.so.2 > #1 0x28109148 in sigprocmask () from /lib/libpthread.so.2 > #2 0x2811360c in pthread_mutexattr_init () from /lib/libpthread.so.2 > #3 0x281062db in fork () from /lib/libpthread.so.2 > #4 0x2850e04c in blt::Fork () at wrapunix.cpp:978 > #5 0x08073e7b in cerebro::ModuleManager::loadModule (this=0x810af40, > rModule=@0x816a200) at ModuleManager.cpp:500 > #6 0x08073f54 in cerebro::ModuleManager::loadModules (this=0x810af40, > mqipctok=@0x80ef134, piddir=@0x80ef124) at ModuleManager.cpp:536 > #7 0x08064e26 in cerebro::Cerebro::main (this=0x80ef100, argc=4, > argv=0xbfbfe9d4) at Cerebro.cpp:721 > #8 0x08069e6a in main (argc=4, argv=0xbfbfe9d4) at Cerebro.cpp:1934 > > And here's the second (corrupted) thread (#5), that I'm 90% sure is caused > by a third-party logging library, unfortunately. > > #0 0x28114fbf in pthread_mutexattr_init () from /lib/libpthread.so.2 > #1 0x28110e29 in _pthread_mutex_trylock () from /lib/libpthread.so.2 > #2 0x28112cc6 in pthread_mutex_lock () from /lib/libpthread.so.2 > #3 0x2811d3f5 in __error () from /lib/libpthread.so.2 > #4 0x28110e29 in _pthread_mutex_trylock () from /lib/libpthread.so.2 > #5 0x28112cc6 in pthread_mutex_lock () from /lib/libpthread.so.2 > #6 0x2810831a in _spinunlock () from /lib/libpthread.so.2 > #7 0x289c5d22 in _UTF8_init () from /lib/libc.so.6 > #8 0x28a42580 in _thread_autoinit_dummy_decl_stub () from /lib/libc.so.6 > #9 0x0813c280 in ?? () > #10 0xbf8fda38 in ?? () > #11 0x289c5cc9 in _UTF8_init () from /lib/libc.so.6 > #12 0x28a2f593 in sys_nsig () from /lib/libc.so.6 > #13 0x2894e5c4 in ?? () from /usr/lib/libstdc++.so.5 > #14 0xbf8fd9c8 in ?? () > #15 0x2892db3d in operator delete () from /usr/lib/libstdc++.so.5 > #16 0x2892db51 in operator delete () from /usr/lib/libstdc++.so.5 > #17 0x288ed6fb in std::string::_Rep::_M_destroy () from > /usr/lib/libstdc++.so.5 > #18 0x28110e29 in _pthread_mutex_trylock () from /lib/libpthread.so.2 > #19 0x2811d3f5 in __error () from /lib/libpthread.so.2 > #20 0x280fa170 in ?? () > #21 0x00000000 in ?? () > #22 0xbf8fdb64 in ?? () > #23 0x280d46fc in symlook_obj () from /libexec/ld-elf.so.1 > > _______________________________________________ > 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" -- - Alfred Perlstein From owner-freebsd-threads@FreeBSD.ORG Tue Oct 28 17:32:16 2008 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E452106567A for ; Tue, 28 Oct 2008 17:32:16 +0000 (UTC) (envelope-from sbartnikowski@barkinglizards.com) Received: from pluto.phpwebhosting.com (pluto.phpwebhosting.com [69.0.209.128]) by mx1.freebsd.org (Postfix) with SMTP id 0275F8FC13 for ; Tue, 28 Oct 2008 17:32:15 +0000 (UTC) (envelope-from sbartnikowski@barkinglizards.com) Received: (qmail 12804 invoked from network); 28 Oct 2008 17:32:10 -0000 Received: from unknown (HELO OCTOBER) (216.138.73.12) by pluto.phpwebhosting.com with SMTP; Tue, 28 Oct 2008 13:32:10 -0400 From: "Stephen Bartnikowski" To: References: <5B0A3FB3D06E41849325AD3EA98CAD55@OCTOBER> <20081028164026.GF83037@elvis.mu.org> Date: Tue, 28 Oct 2008 12:32:14 -0500 Organization: Barking Lizards Technologies Message-ID: <687C5AD700E9484DABB55D5F92A18C10@OCTOBER> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ack5G99Mrp31EuNGTOqmGpv7DLA/mgABx5Mg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <20081028164026.GF83037@elvis.mu.org> Subject: RE: deadlock in fork call? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbartnikowski@barkinglizards.com List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2008 17:32:16 -0000 Thanks Alfred. I mostly do programming, so I didn't even think to put my admin hat on. Sounds like this patch will do the job. - Stephen > -----Original Message----- > From: Alfred Perlstein [mailto:alfred@freebsd.org] > Sent: Tuesday, October 28, 2008 11:40 AM > To: Stephen Bartnikowski > Cc: freebsd-threads@freebsd.org > Subject: Re: deadlock in fork call? > > I'm pretty sure this is fixed in 6-stable. > > -Alfred > > * Stephen Bartnikowski > [081028 09:19] wrote: > > Hi guys, > > > > To start, I'm not reporting a bug here. I'm trying to get > an idea if > > I'm on the right track. Also, apologies on the lengthy email. > > > > Oh and this likely relevant. I'm running FreeBSD 6.3 RELEASE that I > > installed on July 21. I don't believe any updates have been > performed since. > > > > I've got a deadlock situation between a fork call on the > main thread > > and another thread. I already know I'm venturing into shady > territory > > when I fork a multithreaded process. However, I don't have a good > > understanding of exactly what's going on there, which is > where I'm hoping you guys can help. > > Stack dumps are at the bottom of this email. > > > > Idea 1: Thread #5 blows up and in its bad state is stuck on a mutex > > for whatever reason. Thread #1 in the fork call is attempting to > > reinitialize each mutex in the process space and deadlocks because > > Thread #5 is hosed and has one of those mutexes. > > > > Idea 2: Thread #5 blows up at the same time that Thread #1 > makes the > > fork call. Since at this point in FreeBSD (6.3), the Giant > Lock logic > > is still in there, and these two threads deadlock each other on > > pthread_mutexattr_init calls. > > > > Note that my forked process logic is followed by an execv call, > > although I just noticed that if execv fails for whatever > reason, I'm > > likely doing some unsafe logging calls before that forked > process quits. > > > > Any input on whether Idea 1 or Idea 2 are valid? > > > > Thank you! > > > > - Stephen > > > > Here's the main thread (#1) doing the fork call. It's > blocked on that > > pthread_mutexattr_init call. > > > > #0 0x28109198 in pthread_sigmask () from /lib/libpthread.so.2 > > #1 0x28109148 in sigprocmask () from /lib/libpthread.so.2 > > #2 0x2811360c in pthread_mutexattr_init () from > /lib/libpthread.so.2 > > #3 0x281062db in fork () from /lib/libpthread.so.2 > > #4 0x2850e04c in blt::Fork () at wrapunix.cpp:978 > > #5 0x08073e7b in cerebro::ModuleManager::loadModule > (this=0x810af40, > > rModule=@0x816a200) at ModuleManager.cpp:500 > > #6 0x08073f54 in cerebro::ModuleManager::loadModules > (this=0x810af40, > > mqipctok=@0x80ef134, piddir=@0x80ef124) at ModuleManager.cpp:536 > > #7 0x08064e26 in cerebro::Cerebro::main (this=0x80ef100, argc=4, > > argv=0xbfbfe9d4) at Cerebro.cpp:721 > > #8 0x08069e6a in main (argc=4, argv=0xbfbfe9d4) at Cerebro.cpp:1934 > > > > And here's the second (corrupted) thread (#5), that I'm 90% sure is > > caused by a third-party logging library, unfortunately. > > > > #0 0x28114fbf in pthread_mutexattr_init () from > /lib/libpthread.so.2 > > #1 0x28110e29 in _pthread_mutex_trylock () from > /lib/libpthread.so.2 > > #2 0x28112cc6 in pthread_mutex_lock () from /lib/libpthread.so.2 > > #3 0x2811d3f5 in __error () from /lib/libpthread.so.2 > > #4 0x28110e29 in _pthread_mutex_trylock () from > /lib/libpthread.so.2 > > #5 0x28112cc6 in pthread_mutex_lock () from /lib/libpthread.so.2 > > #6 0x2810831a in _spinunlock () from /lib/libpthread.so.2 > > #7 0x289c5d22 in _UTF8_init () from /lib/libc.so.6 > > #8 0x28a42580 in _thread_autoinit_dummy_decl_stub () from > > /lib/libc.so.6 > > #9 0x0813c280 in ?? () > > #10 0xbf8fda38 in ?? () > > #11 0x289c5cc9 in _UTF8_init () from /lib/libc.so.6 > > #12 0x28a2f593 in sys_nsig () from /lib/libc.so.6 > > #13 0x2894e5c4 in ?? () from /usr/lib/libstdc++.so.5 > > #14 0xbf8fd9c8 in ?? () > > #15 0x2892db3d in operator delete () from /usr/lib/libstdc++.so.5 > > #16 0x2892db51 in operator delete () from /usr/lib/libstdc++.so.5 > > #17 0x288ed6fb in std::string::_Rep::_M_destroy () from > > /usr/lib/libstdc++.so.5 > > #18 0x28110e29 in _pthread_mutex_trylock () from > /lib/libpthread.so.2 > > #19 0x2811d3f5 in __error () from /lib/libpthread.so.2 #20 > 0x280fa170 > > in ?? () > > #21 0x00000000 in ?? () > > #22 0xbf8fdb64 in ?? () > > #23 0x280d46fc in symlook_obj () from /libexec/ld-elf.so.1 > > > > _______________________________________________ > > 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" > > -- > - Alfred Perlstein > From owner-freebsd-threads@FreeBSD.ORG Thu Oct 30 17:41:17 2008 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDFF71065698 for ; Thu, 30 Oct 2008 17:41:17 +0000 (UTC) (envelope-from info@yourkit.com) Received: from mail.yourkit.com (mail.yourkit.com [217.112.36.110]) by mx1.freebsd.org (Postfix) with ESMTP id 309958FC33 for ; Thu, 30 Oct 2008 17:41:16 +0000 (UTC) (envelope-from info@yourkit.com) Received: (qmail 16602 invoked by uid 89); 30 Oct 2008 17:14:34 -0000 Received: by simscan 1.1.0 ppid: 16577, pid: 16599, t: 0.0736s scanners: clamav: 0.87.1/m:34/d:1162 Received: from unknown (HELO localhost) (info@yourkit.com@84.52.73.195) by mail.yourkit.com with ESMTPA; 30 Oct 2008 17:14:34 -0000 Date: Thu, 30 Oct 2008 20:15:53 +0300 From: Vladimir Kondratyev Organization: YourKit, LLC X-Priority: 3 (Normal) Message-ID: <678291552.20081030201553@yourkit.com> To: freebsd-threads@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: getting CPU time for particulat thread X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: info@yourkit.com List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2008 17:41:18 -0000 Hi folks, is there any ability to get CPU time consumed by particular thread? We are porting YourKit Java Profiler (http://www.yourkit.com) to FreeBSD platform. Everything works almost fine, but we cannot find a way how to receive thread CPU times? Any help is greatly appreciated. Thank you in advance. Sincerely, Vladimir Kondratyev YourKit, LLC http://www.yourkit.com "Don't get lost in data, get information!" From owner-freebsd-threads@FreeBSD.ORG Fri Oct 31 01:20:38 2008 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D3851065686 for ; Fri, 31 Oct 2008 01:20:38 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D64238FC0A; Fri, 31 Oct 2008 01:20:37 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from apple.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id m9V1KavP034493; Fri, 31 Oct 2008 01:20:37 GMT (envelope-from davidxu@freebsd.org) Message-ID: <490A5DD2.8030703@freebsd.org> Date: Fri, 31 Oct 2008 09:22:26 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20080612) MIME-Version: 1.0 To: info@yourkit.com References: <678291552.20081030201553@yourkit.com> In-Reply-To: <678291552.20081030201553@yourkit.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-threads@freebsd.org Subject: Re: getting CPU time for particulat thread 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, 31 Oct 2008 01:20:38 -0000 Vladimir Kondratyev wrote: > Hi folks, > > is there any ability to get CPU time consumed by particular thread? > > We are porting YourKit Java Profiler (http://www.yourkit.com) to FreeBSD > platform. Everything works almost fine, but we cannot find a way how to receive > thread CPU times? > > Any help is greatly appreciated. > > Thank you in advance. > > Sincerely, > Vladimir Kondratyev > YourKit, LLC > http://www.yourkit.com > "Don't get lost in data, get information!" > if you just want to get current thread's time, there is a feature in -HEAD branch, call clock_gettime(CLOCK_THREAD_CPUTIME_ID, &ts) to get total cpu time for the current thread. Regards, David Xu