From owner-freebsd-threads@FreeBSD.ORG Mon Sep 22 11:07:05 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 AFAC51065670 for ; Mon, 22 Sep 2008 11:07:05 +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 9F87F8FC2C for ; Mon, 22 Sep 2008 11:07:05 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m8MB75sQ015536 for ; Mon, 22 Sep 2008 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m8MB74ZT015532 for freebsd-threads@FreeBSD.org; Mon, 22 Sep 2008 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 22 Sep 2008 11:07:04 GMT Message-Id: <200809221107.m8MB74ZT015532@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, 22 Sep 2008 11:07:05 -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/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 bin/32295 threads 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 38 problems total. From owner-freebsd-threads@FreeBSD.ORG Wed Sep 24 21:34:14 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 0F7B41065689 for ; Wed, 24 Sep 2008 21:34:14 +0000 (UTC) (envelope-from dixit@netapp.com) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by mx1.freebsd.org (Postfix) with ESMTP id EA4C08FC16 for ; Wed, 24 Sep 2008 21:34:13 +0000 (UTC) (envelope-from dixit@netapp.com) X-IronPort-AV: E=Sophos;i="4.33,303,1220252400"; d="scan'208";a="60394433" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 24 Sep 2008 14:05:52 -0700 Received: from dixit-lxp.nane.netapp.com ([10.97.16.124]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id m8OL5p0u002532; Wed, 24 Sep 2008 14:05:52 -0700 (PDT) Message-ID: <48DAABAF.9030709@netapp.com> Date: Wed, 24 Sep 2008 17:05:51 -0400 From: Amol Dixit User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: freebsd-threads@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: davidxu@freebsd.org Subject: SIGTRAP during thr_new syscall 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, 24 Sep 2008 21:34:14 -0000 Hi, I am seeing an unexpected SIGTRAP being reported to gdbserver when the debugged process creates a new thread via the _pthread_create() call of libthr library. [libthr/thread/thr_create.c,v 1.22.4.1, Freebsd 6.0] Gdbserver has internally set a breakpoint on address of _thread_bp_create() so that it gets notified on thread creation and is expecting a SIGTRAP at address (stop pc) of _thread_bp_create(). But instead SIGTRAP happens as a side-effect of thr_new() system call and the stop pc at that point is that of routine thread_start() which is the starting function of new thread. So gdbserver cannot match expected breakpoint (ie. _thread_bp_create) and is confused. For testing purpose, if I call _thread_bp_create() before thr_new() in _pthread_create(), I get the _expected_ SIGTRAP with address of _thread_bp_create. But that is not the fix. Does anyone have any idea about this SIGTRAP being reported to tracing process gdbserver as part of thr_new? Where is it originating from and why? Thanks, Amol From owner-freebsd-threads@FreeBSD.ORG Thu Sep 25 03:43: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 3CC84106568E for ; Thu, 25 Sep 2008 03:43: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 2131F8FC1A; Thu, 25 Sep 2008 03:43:38 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from apple.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m8P3hXne087691; Thu, 25 Sep 2008 03:43:34 GMT (envelope-from davidxu@freebsd.org) Message-ID: <48DB0950.3060405@freebsd.org> Date: Thu, 25 Sep 2008 11:45:20 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20080612) MIME-Version: 1.0 To: Amol Dixit References: <48DAABAF.9030709@netapp.com> In-Reply-To: <48DAABAF.9030709@netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-threads@freebsd.org Subject: Re: SIGTRAP during thr_new syscall 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: Thu, 25 Sep 2008 03:43:38 -0000 Amol Dixit wrote: > Hi, > I am seeing an unexpected SIGTRAP being reported to gdbserver when the > debugged process creates a new thread via the _pthread_create() call of > libthr library. [libthr/thread/thr_create.c,v 1.22.4.1, Freebsd 6.0] > Gdbserver has internally set a breakpoint on address of > _thread_bp_create() so that it gets notified on thread creation and is > expecting a SIGTRAP at address (stop pc) of _thread_bp_create(). But > instead SIGTRAP happens as a side-effect of thr_new() system call and > the stop pc at that point is that of routine thread_start() which is the > starting function of new thread. So gdbserver cannot match expected > breakpoint (ie. _thread_bp_create) and is confused. > For testing purpose, if I call _thread_bp_create() before thr_new() in > _pthread_create(), I get the _expected_ SIGTRAP with address of > _thread_bp_create. But that is not the fix. > Does anyone have any idea about this SIGTRAP being reported to tracing > process gdbserver as part of thr_new? Where is it originating from and why? > Thanks, > Amol > I found kernel clears trap flag for new process but not for new thread in cpu_fork(), you may try following patch: Index: i386/i386/vm_machdep.c =================================================================== --- i386/i386/vm_machdep.c (revision 183337) +++ i386/i386/vm_machdep.c (working copy) @@ -413,6 +413,15 @@ bcopy(td0->td_frame, td->td_frame, sizeof(struct trapframe)); /* + * If the current thread has the trap bit set (i.e. a debugger had + * single stepped the process to the system call), we need to clear + * the trap flag from the new frame. Otherwise, the new thread will + * receive a (likely unexpected) SIGTRAP when it executes the first + * instruction after returning to userland. + */ + td->td_frame->tf_eflags &= ~PSL_T; + + /* * Set registers for trampoline to user mode. Leave space for the * return address on stack. These are the kernel mode register values. */ From owner-freebsd-threads@FreeBSD.ORG Thu Sep 25 09:03:29 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 76E861065698; Thu, 25 Sep 2008 09:03:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 1BF8A8FC25; Thu, 25 Sep 2008 09:03:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Kimkv-0007ia-T9; Thu, 25 Sep 2008 12:03:25 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m8P93IWS046462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2008 12:03:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m8P93ISe082511; Thu, 25 Sep 2008 12:03:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id m8P93Ipv082510; Thu, 25 Sep 2008 12:03:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 25 Sep 2008 12:03:18 +0300 From: Kostik Belousov To: David Xu Message-ID: <20080925090318.GK47828@deviant.kiev.zoral.com.ua> References: <48DAABAF.9030709@netapp.com> <48DB0950.3060405@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TXy4g9tqilp80iv6" Content-Disposition: inline In-Reply-To: <48DB0950.3060405@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1Kimkv-0007ia-T9 c32cfc9690d7367b0bf7b45060e18447 X-Terabit: YES Cc: freebsd-threads@freebsd.org, Amol Dixit Subject: Re: SIGTRAP during thr_new syscall 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: Thu, 25 Sep 2008 09:03:29 -0000 --TXy4g9tqilp80iv6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 25, 2008 at 11:45:20AM +0800, David Xu wrote: > Amol Dixit wrote: > >Hi, > >I am seeing an unexpected SIGTRAP being reported to gdbserver when the= =20 > >debugged process creates a new thread via the _pthread_create() call of= =20 > >libthr library. [libthr/thread/thr_create.c,v 1.22.4.1, Freebsd 6.0] > >Gdbserver has internally set a breakpoint on address of=20 > >_thread_bp_create() so that it gets notified on thread creation and is= =20 > >expecting a SIGTRAP at address (stop pc) of _thread_bp_create(). But=20 > >instead SIGTRAP happens as a side-effect of thr_new() system call and=20 > >the stop pc at that point is that of routine thread_start() which is the= =20 > >starting function of new thread. So gdbserver cannot match expected=20 > >breakpoint (ie. _thread_bp_create) and is confused. > >For testing purpose, if I call _thread_bp_create() before thr_new() in= =20 > >_pthread_create(), I get the _expected_ SIGTRAP with address of=20 > >_thread_bp_create. But that is not the fix. > >Does anyone have any idea about this SIGTRAP being reported to tracing= =20 > >process gdbserver as part of thr_new? Where is it originating from and w= hy? > >Thanks, > >Amol > > >=20 > I found kernel clears trap flag for new process but not for new thread > in cpu_fork(), you may try following patch: >=20 > Index: i386/i386/vm_machdep.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- i386/i386/vm_machdep.c (revision 183337) > +++ i386/i386/vm_machdep.c (working copy) > @@ -413,6 +413,15 @@ > bcopy(td0->td_frame, td->td_frame, sizeof(struct trapframe)); >=20 > /* > + * If the current thread has the trap bit set (i.e. a debugger had > + * single stepped the process to the system call), we need to clear > + * the trap flag from the new frame. Otherwise, the new thread will > + * receive a (likely unexpected) SIGTRAP when it executes the first > + * instruction after returning to userland. > + */ > + td->td_frame->tf_eflags &=3D ~PSL_T; > + > + /* > * Set registers for trampoline to user mode. Leave space for the > * return address on stack. These are the kernel mode register=20 > values. > */ Should this be done for amd64 version of the cpu_set_upcall() as well ? --TXy4g9tqilp80iv6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkjbU9UACgkQC3+MBN1Mb4i9WwCgnoViT90RmMZWfWDut0g7TIMN 3BoAn2HgBS5mBYiy4GdDcFKVxUZP1HAd =zxDa -----END PGP SIGNATURE----- --TXy4g9tqilp80iv6-- From owner-freebsd-threads@FreeBSD.ORG Fri Sep 26 19:19:10 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 07D881065686 for ; Fri, 26 Sep 2008 19:19:10 +0000 (UTC) (envelope-from dchhetri@panasas.com) Received: from laguna.int.panasas.com (gw-ca.panasas.com [66.104.249.162]) by mx1.freebsd.org (Postfix) with ESMTP id E455D8FC1D for ; Fri, 26 Sep 2008 19:19:09 +0000 (UTC) (envelope-from dchhetri@panasas.com) Received: from [172.17.132.94] ([172.17.132.94]) by laguna.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Sep 2008 12:05:55 -0700 Message-ID: <48DD32D2.2060304@panasas.com> Date: Fri, 26 Sep 2008 12:06:58 -0700 From: Dilip Chhetri User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-threads@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2008 19:05:55.0703 (UTC) FILETIME=[E72D3070:01C9200A] Subject: getting stack trace for other thread on the same process : libthr 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, 26 Sep 2008 19:19:10 -0000 Question -------- My program is linked with libthr in FreeBSD-7.0. The program has in the order of 20 threads, and a designated monitoring thread at some point wants to know what are other/stuck threads doing. This needs to be done by printing stack backtrace for the thread to stdout. I understand pthread_t structure has pointer to the target thread's stack, but to get the trace I need to know value of stack-pointer register and base-pointer register. I looked at the code and I don't find any mechanism by which I could read the target threads register context (because it all resides within kernel thread structure). Further code study reveals that kernel_thread->td_frame contains the register context for a thread, but is valid only when the thread is executing/sleeping inside the kernel. Is there anything I'm missing here ? Is there an easy way to traverse stack for some thread with in the same process. I considered/considering following approaches, a) use PTRACE ruled out, because you can't trace the process from within the same process b) somehow temporarily stop the target-thread and read td_frame by traversing kernel data structure through /dev/kmem. After doing stack traversal resume the target thread. Detailed problem background -------------------------- We have this process X with ~20 threads, each processing some requests. One of them is designated as monitoring/dispatcher thread. When a new request arrives, dispatcher thread tries to queue the task to idle thread. But if all threads are busy processing requests, the dispatcher thread is supposed to print the stack back trace for each of the busy thread. This is our *debugging* mechanism to find potential fault-points. In FreeBSD-4.6.2, we hacked libc_r:pthread_t to achieve our goal. But in FreeBSD-7.0, we decided to use libthr and hack doesn't seem to be easy. Target setup ------------ * SMP : around 8 CPU * process : it's going to be run as root and have around ~20 threads From owner-freebsd-threads@FreeBSD.ORG Fri Sep 26 22:01:42 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 C2F4110656D2 for ; Fri, 26 Sep 2008 22:01:42 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from mailrelay006.isp.belgacom.be (mailrelay006.isp.belgacom.be [195.238.6.172]) by mx1.freebsd.org (Postfix) with ESMTP id 60CEA8FC31 for ; Fri, 26 Sep 2008 22:01:42 +0000 (UTC) (envelope-from tijl@ulyssis.org) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMEADny3EhR92WB/2dsb2JhbACBYrsmgWY Received: from 129.101-247-81.adsl-dyn.isp.belgacom.be (HELO kalimero.kotnet.org) ([81.247.101.129]) by relay.skynet.be with ESMTP; 26 Sep 2008 23:32:35 +0200 Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.14.3/8.14.3) with ESMTP id m8QLVU3T012523; Fri, 26 Sep 2008 23:31:30 +0200 (CEST) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: Dilip Chhetri Date: Fri, 26 Sep 2008 23:31:27 +0200 User-Agent: KMail/1.9.10 References: <48DD32D2.2060304@panasas.com> In-Reply-To: <48DD32D2.2060304@panasas.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809262331.29353.tijl@ulyssis.org> Cc: freebsd-threads@freebsd.org Subject: Re: getting stack trace for other thread on the same process : libthr 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, 26 Sep 2008 22:01:42 -0000 On Friday 26 September 2008 21:06:58 Dilip Chhetri wrote: > Question > -------- > My program is linked with libthr in FreeBSD-7.0. The program has > in the order of 20 threads, and a designated monitoring thread at > some point wants to know what are other/stuck threads doing. This > needs to be done by printing stack backtrace for the thread to > stdout. > > I understand pthread_t structure has pointer to the target > thread's stack, but to get the trace I need to know value of > stack-pointer register and base-pointer register. I looked at the > code and I don't find any mechanism by which I could read the target > threads register context (because it all resides within kernel thread > structure). Further code study reveals that kernel_thread->td_frame > contains the register context for a thread, but is valid only when > the thread is executing/sleeping inside the kernel. > > Is there anything I'm missing here ? Is there an easy way to > traverse stack for some thread with in the same process. > > I considered/considering following approaches, > a) use PTRACE > ruled out, because you can't trace the process from within the > same process > > b) somehow temporarily stop the target-thread and read td_frame by > traversing kernel data structure through /dev/kmem. After doing > stack traversal resume the target thread. > > > Detailed problem background > -------------------------- > We have this process X with ~20 threads, each processing some > requests. One of them is designated as monitoring/dispatcher thread. > When a new request arrives, dispatcher thread tries to queue the task > to idle thread. But if all threads are busy processing requests, the > dispatcher thread is supposed to print the stack back trace for each > of the busy thread. This is our *debugging* mechanism to find > potential fault-points. > > In FreeBSD-4.6.2, we hacked libc_r:pthread_t to achieve our goal. > But in FreeBSD-7.0, we decided to use libthr and hack doesn't seem to > be easy. > > Target setup > ------------ > * SMP : around 8 CPU > * process : it's going to be run as root and have around ~20 threads You could try registering a signal handler for SIGUSR1 that prints a stack backtrace using the stack pointer in the sigcontext and then call pthread_kill(SIGUSR1) on whichever thread you want a backtrace of.