From owner-freebsd-threads@FreeBSD.ORG Mon Sep 19 11:02:25 2005 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 51D6B16A41F for ; Mon, 19 Sep 2005 11:02:25 +0000 (GMT) (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 1774843D46 for ; Mon, 19 Sep 2005 11:02:25 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j8JB2Op7018258 for ; Mon, 19 Sep 2005 11:02:24 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j8JB2NuC018253 for freebsd-threads@freebsd.org; Mon, 19 Sep 2005 11:02:23 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 19 Sep 2005 11:02:23 GMT Message-Id: <200509191102.j8JB2NuC018253@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter 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, 19 Sep 2005 11:02:25 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2005/01/26] threads/76690threads fork hang in child for (-lc_r & -lthr) o [2005/05/11] threads/80887threads ULE with SMP broke libpthread/libthr on 5 2 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/07/18] kern/20016 threads pthreads: Cannot set scheduling timer/Can o [2000/08/26] kern/20861 threads libc_r does not honor socket timeouts o [2001/01/20] threads/24472threads libc_r does not honor SO_SNDTIMEO/SO_RCVT o [2001/01/25] threads/24632threads libc_r delicate deviation from libc in ha o [2001/01/25] kern/24641 threads pthread_rwlock_rdlock can deadlock o [2001/11/26] bin/32295 threads pthread dont dequeue signals o [2002/02/01] threads/34536threads accept() blocks other threads o [2002/05/25] kern/38549 threads the procces compiled whith pthread stoppe o [2002/06/27] threads/39922threads [PATCH?] Threaded applications executed w o [2002/08/04] kern/41331 threads Pthread library open sets O_NONBLOCK flag o [2003/03/02] threads/48856threads Setting SIGCHLD to SIG_IGN still leaves z o [2003/03/10] threads/49087threads Signals lost in programs linked with libc s [2004/03/15] kern/64313 threads FreeBSD (OpenBSD) pthread implicit set/un o [2004/08/26] threads/70975threads unexpected and unreliable behaviour when o [2004/09/14] threads/71725threads Mysql Crashes frequently giving Sock Erro o [2004/10/05] threads/72353threads Assertion fails in /usr/src/lib/libpthrea o [2004/10/07] threads/72429threads threads blocked in stdio (fgets, etc) are o [2004/10/21] threads/72953threads fork() unblocks blocked signals w/o PTHRE o [2004/12/19] threads/75273threads FBSD 5.3 libpthread (KSE) bug o [2004/12/21] threads/75374threads pthread_kill() ignores SA_SIGINFO flag o [2005/01/26] threads/76694threads fork cause hang in dup()/close() function o [2005/03/10] threads/78660threads Java hangs unkillably in STOP state after o [2005/04/08] threads/79683threads svctcp_create() fails if multiple threads o [2005/04/28] threads/80435threads panic on high loads o [2005/05/19] threads/81258threads Thread specific data is sometimes assigne o [2005/08/02] threads/84483threads problems with devel/nspr and -lc_r on 4.x o [2005/08/10] threads/84778threads libpthread busy loop/hang with Java when o [2005/08/19] threads/85112threads Resource temporarily unavailable reading o [2005/08/20] threads/85160threads [patch] libobjc + libpthread/libthr crash o [2005/09/12] threads/86004threads libthr broken on amd64 30 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/05/26] kern/18824 threads gethostbyname is not thread safe o [2000/06/13] kern/19247 threads uthread_sigaction.c does not do anything o [2000/10/21] kern/22190 threads A threaded read(2) from a socketpair(2) f o [2001/09/09] threads/30464threads pthread mutex attributes -- pshared o [2002/05/02] threads/37676threads libc_r: msgsnd(), msgrcv(), pread(), pwri s [2002/07/16] threads/40671threads pthread_cancel doesn't remove thread from o [2004/07/13] threads/69020threads pthreads library leaks _gc_mutex o [2004/09/21] threads/71966threads Mlnet Core Dumped : Fatal error '_pq_inse o [2004/11/21] threads/74180threads KSE problem. Applications those riched ma o [2005/01/20] threads/76513threads libpthread is not working o [2005/04/13] threads/79887threads [patch] freopen() isn't thread-safe o [2005/05/13] threads/80992threads abort() sometimes not caught by gdb depen o [2005/05/26] threads/81534threads [PATCH] libc_r close() will fail on any f 13 problems total. From owner-freebsd-threads@FreeBSD.ORG Wed Sep 21 07:07:09 2005 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 324EB16A41F; Wed, 21 Sep 2005 07:07:09 +0000 (GMT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D01B943D58; Wed, 21 Sep 2005 07:07:08 +0000 (GMT) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j8L778em073000; Wed, 21 Sep 2005 07:07:08 GMT (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j8L778su072996; Wed, 21 Sep 2005 07:07:08 GMT (envelope-from kris) Date: Wed, 21 Sep 2005 07:07:08 GMT From: Kris Kennaway Message-Id: <200509210707.j8L778su072996@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org Cc: Subject: Re: kern/86029: undefined reference to `_thread_dump_info' 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, 21 Sep 2005 07:07:09 -0000 Synopsis: undefined reference to `_thread_dump_info' Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: kris Responsible-Changed-When: Wed Sep 21 07:06:59 GMT 2005 Responsible-Changed-Why: Assign to threads mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=86029 From owner-freebsd-threads@FreeBSD.ORG Wed Sep 21 07:50:08 2005 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABB3116A41F for ; Wed, 21 Sep 2005 07:50:08 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67EC743D48 for ; Wed, 21 Sep 2005 07:50:08 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j8L7o8Hm076994 for ; Wed, 21 Sep 2005 07:50:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j8L7o8oU076993; Wed, 21 Sep 2005 07:50:08 GMT (envelope-from gnats) Date: Wed, 21 Sep 2005 07:50:08 GMT Message-Id: <200509210750.j8L7o8oU076993@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: David Xu Cc: Subject: Re: kern/86029: undefined reference to `_thread_dump_info' X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Xu List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2005 07:50:08 -0000 The following reply was made to PR kern/86029; it has been noted by GNATS. From: David Xu To: bug-followup@freebsd.org, brlcad@mac.com Cc: Subject: Re: kern/86029: undefined reference to `_thread_dump_info' Date: Wed, 21 Sep 2005 15:40:25 +0800 _thread_dump_info() is an undocumented function and for internal use only in libpthread, why do you want to use it ? David Xu From owner-freebsd-threads@FreeBSD.ORG Wed Sep 21 14:10:15 2005 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD00616A41F for ; Wed, 21 Sep 2005 14:10:15 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 734FC43D46 for ; Wed, 21 Sep 2005 14:10:15 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j8LEAFgg027150 for ; Wed, 21 Sep 2005 14:10:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j8LEAFvr027149; Wed, 21 Sep 2005 14:10:15 GMT (envelope-from gnats) Date: Wed, 21 Sep 2005 14:10:15 GMT Message-Id: <200509211410.j8LEAFvr027149@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: "Daniel M. Eischen" Cc: Subject: Re: kern/86029: undefined reference to `_thread_dump_info' X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Daniel M. Eischen" List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2005 14:10:15 -0000 The following reply was made to PR kern/86029; it has been noted by GNATS. From: "Daniel M. Eischen" To: bug-followup@FreeBSD.org, brlcad@mac.com Cc: Subject: Re: kern/86029: undefined reference to `_thread_dump_info' Date: Wed, 21 Sep 2005 09:48:37 -0400 Yes, this is an internal function (it begins with an underscore). It does not exist in libpthread. This bug should be closed. From owner-freebsd-threads@FreeBSD.ORG Wed Sep 21 14:40:04 2005 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2638816A41F for ; Wed, 21 Sep 2005 14:40:04 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD27843D77 for ; Wed, 21 Sep 2005 14:40:03 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j8LEe3o8029038 for ; Wed, 21 Sep 2005 14:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j8LEe3fZ029034; Wed, 21 Sep 2005 14:40:03 GMT (envelope-from gnats) Date: Wed, 21 Sep 2005 14:40:03 GMT Message-Id: <200509211440.j8LEe3fZ029034@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Christopher Sean Morrison Cc: Subject: Re: kern/86029: undefined reference to `_thread_dump_info' X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christopher Sean Morrison List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2005 14:40:04 -0000 The following reply was made to PR kern/86029; it has been noted by GNATS. From: Christopher Sean Morrison To: David Xu Cc: "Daniel M. Eischen" , bug-followup@freebsd.org Subject: Re: kern/86029: undefined reference to `_thread_dump_info' Date: Wed, 21 Sep 2005 10:33:08 -0400 David, This function was being used by a chunk of low level threading code in the BRL-CAD that has been in use since '98 for dumping out extra state information when thread creation fails. We don't "want" to use it, it just has been used for so long in the code for the very same reason that it's used by the posix threading library -- it's very useful for debugging and investigating failures. For what it's worth, this routine was in fact documented in the OpenBSD notes for c_r as being useful for exactly that purpose. Again, this is nothing new, either -- doesn't make it right, but what are the alternatives? The only difference seems to be the change on this AMD64 box to not utilize -lc_r when -pthread is provided on the compile line. I've got no issue removing the call from our code, but it seems indicative of a larger change to what -pthread means. If -pthread no longer implies linking against c_r for whatever reason, that would be the fundamental difference here that we'll need to accommodate in our build. In that regard, what non-private routine will provide similar details when thread creation fails? Sean On Sep 21, 2005, at 3:40 AM, David Xu wrote: > _thread_dump_info() is an undocumented function and for internal > use only in libpthread, why do you want to use it ? > > David Xu From owner-freebsd-threads@FreeBSD.ORG Wed Sep 21 15:00:35 2005 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9456A16A41F for ; Wed, 21 Sep 2005 15:00:35 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E18A43D5C for ; Wed, 21 Sep 2005 15:00:29 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j8LF0TN8029712 for ; Wed, 21 Sep 2005 15:00:29 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j8LF0SBD029711; Wed, 21 Sep 2005 15:00:28 GMT (envelope-from gnats) Date: Wed, 21 Sep 2005 15:00:28 GMT Message-Id: <200509211500.j8LF0SBD029711@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Christopher Sean Morrison Cc: Subject: Re: kern/86029: undefined reference to `_thread_dump_info' X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christopher Sean Morrison List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2005 15:00:35 -0000 The following reply was made to PR kern/86029; it has been noted by GNATS. From: Christopher Sean Morrison To: "Daniel M. Eischen" Cc: bug-followup@FreeBSD.org Subject: Re: kern/86029: undefined reference to `_thread_dump_info' Date: Wed, 21 Sep 2005 10:50:35 -0400 The issue is not with libpthread (i.e. -lpthread) but with the -pthread option to gcc. The symbol itself is provided via libc_r, not libpthread. As the bug report notes, everything works if I link against -lc_r which was unexpected when already passing -pthread. I'm also not contesting whether we should or shouldn't be using _thread_dump_info at all, it's just the symbol that exposed the issue. The difference here seems to be that gcc's -pthread option on amd64's behaves differently than other systems by not linking against c_r. If this was intentional, then I'd agree that it's not a bug. If it wasn't, the bug would perhaps be that it should be linking against -lc_r. We're seeing several other threading problems on AMD64 and some of them I believe are related to re-entrance issues and stack corruption. Crashes deep inside C library calls are particularly interesting. From other bug report traffic from a month or few ago, it would seem at least some of these issues may be fixed in a later release (we're sitting on 5.4).. Cheers! Sean On Sep 21, 2005, at 9:48 AM, Daniel M. Eischen wrote: > Yes, this is an internal function (it begins with an underscore). > It does not exist in libpthread. This bug should be closed. From owner-freebsd-threads@FreeBSD.ORG Wed Sep 21 17:30:12 2005 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1378F16A41F for ; Wed, 21 Sep 2005 17:30:12 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D316F43D45 for ; Wed, 21 Sep 2005 17:30:11 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j8LHUBC5049080 for ; Wed, 21 Sep 2005 17:30:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j8LHUBju049079; Wed, 21 Sep 2005 17:30:11 GMT (envelope-from gnats) Date: Wed, 21 Sep 2005 17:30:11 GMT Message-Id: <200509211730.j8LHUBju049079@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Daniel Eischen Cc: Subject: Re: kern/86029: undefined reference to `_thread_dump_info' X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2005 17:30:12 -0000 The following reply was made to PR kern/86029; it has been noted by GNATS. From: Daniel Eischen To: Christopher Sean Morrison Cc: David Xu , Subject: Re: kern/86029: undefined reference to `_thread_dump_info' Date: Wed, 21 Sep 2005 13:28:09 -0400 (EDT) On Wed, 21 Sep 2005, Christopher Sean Morrison wrote: > David, > > This function was being used by a chunk of low level threading code in > the BRL-CAD that has been in use since '98 for dumping out extra state > information when thread creation fails. We don't "want" to use it, it > just has been used for so long in the code for the very same reason > that it's used by the posix threading library -- it's very useful for > debugging and investigating failures. That's what SIGINFO is for. Again, that's undocumented and allowed to change, but it's better than calling a library internal function. > For what it's worth, this routine was in fact documented in the OpenBSD > notes for c_r as being useful for exactly that purpose. Again, this is > nothing new, either -- doesn't make it right, but what are the > alternatives? The only difference seems to be the change on this AMD64 > box to not utilize -lc_r when -pthread is provided on the compile line. OpenBSD took our libc_r. If _thread_dump_info() was supposed to be callable from the outside, it would have been named pthread_dump_info_np(). > I've got no issue removing the call from our code, but it seems > indicative of a larger change to what -pthread means. If -pthread no > longer implies linking against c_r for whatever reason, that would be > the fundamental difference here that we'll need to accommodate in our > build. In that regard, what non-private routine will provide similar > details when thread creation fails? -pthread means do whatever is necessary to link in the threads library. In 5.x and subsequent, the threads library is libpthread, not libc_r. pthread_create() should return a useful errno if it can't create a thread. -- DE From owner-freebsd-threads@FreeBSD.ORG Wed Sep 21 18:00:29 2005 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEEA716A41F for ; Wed, 21 Sep 2005 18:00:29 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C99043D48 for ; Wed, 21 Sep 2005 18:00:29 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j8LI0Tws050611 for ; Wed, 21 Sep 2005 18:00:29 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j8LI0StM050610; Wed, 21 Sep 2005 18:00:28 GMT (envelope-from gnats) Date: Wed, 21 Sep 2005 18:00:28 GMT Message-Id: <200509211800.j8LI0StM050610@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Daniel Eischen Cc: Subject: Re: kern/86029: undefined reference to `_thread_dump_info' X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2005 18:00:29 -0000 The following reply was made to PR kern/86029; it has been noted by GNATS. From: Daniel Eischen To: Christopher Sean Morrison Cc: bug-followup@freebsd.org Subject: Re: kern/86029: undefined reference to `_thread_dump_info' Date: Wed, 21 Sep 2005 13:51:13 -0400 (EDT) On Wed, 21 Sep 2005, Christopher Sean Morrison wrote: > The issue is not with libpthread (i.e. -lpthread) but with the > -pthread option to gcc. The symbol itself is provided via libc_r, not > libpthread. As the bug report notes, everything works if I link > against -lc_r which was unexpected when already passing -pthread. I've already responded to this in a previous email. -pthread is doing what it is suppose to, and you shouldn't be using libc_r on 5.x and subsequent because it is not the default threads library (and may be deprecated in the future). -- DE From owner-freebsd-threads@FreeBSD.ORG Wed Sep 21 18:50:08 2005 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CD3016A41F for ; Wed, 21 Sep 2005 18:50:08 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48ED943D45 for ; Wed, 21 Sep 2005 18:50:08 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j8LIo8Nb057705 for ; Wed, 21 Sep 2005 18:50:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j8LIo8DN057704; Wed, 21 Sep 2005 18:50:08 GMT (envelope-from gnats) Date: Wed, 21 Sep 2005 18:50:08 GMT Message-Id: <200509211850.j8LIo8DN057704@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Christopher Sean Morrison Cc: Subject: Re: kern/86029: undefined reference to `_thread_dump_info' X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christopher Sean Morrison List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2005 18:50:08 -0000 The following reply was made to PR kern/86029; it has been noted by GNATS. From: Christopher Sean Morrison To: Daniel Eischen Cc: David Xu , bug-followup@freebsd.org Subject: Re: kern/86029: undefined reference to `_thread_dump_info' Date: Wed, 21 Sep 2005 14:42:12 -0400 On Sep 21, 2005, at 1:28 PM, Daniel Eischen wrote: > That's what SIGINFO is for. Again, that's undocumented and > allowed to change, but it's better than calling a library > internal function. Again, this is really tangent to the whole point of the report, but it does raise ab additional question. If I raise a SIGINFO, is that going to give identical detail about the current threading states? I agree that it's better means to the end. The OpenBSD pthreads(3) manual page does document the signal but I have not had a motivation to change/test that bit of code until now. >> I've got no issue removing the call from our code, but it seems >> indicative of a larger change to what -pthread means. If -pthread no >> longer implies linking against c_r for whatever reason, that would be >> the fundamental difference here that we'll need to accommodate in our >> build. In that regard, what non-private routine will provide similar >> details when thread creation fails? > > -pthread means do whatever is necessary to link in the threads > library. In 5.x and subsequent, the threads library is libpthread, > not libc_r. Which has always been my understanding of -pthread as well. Does this mean then that the C library routines on an AMD64 FreeBSD 5.4 system are supposed to be re-entrant and thread safe? If that's the case, then I probably have another bug report to make. It also doesn't explain the inconsistency with the same rev of FreeBSD on IA32 systems where the same behavior is not exhibited. Cheers! Sean From owner-freebsd-threads@FreeBSD.ORG Wed Sep 21 19:10:14 2005 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 353F916A41F for ; Wed, 21 Sep 2005 19:10:14 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C47FD43D48 for ; Wed, 21 Sep 2005 19:10:13 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j8LJADjn062703 for ; Wed, 21 Sep 2005 19:10:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j8LJADGm062702; Wed, 21 Sep 2005 19:10:13 GMT (envelope-from gnats) Date: Wed, 21 Sep 2005 19:10:13 GMT Message-Id: <200509211910.j8LJADGm062702@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Daniel Eischen Cc: Subject: Re: kern/86029: undefined reference to `_thread_dump_info' X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2005 19:10:14 -0000 The following reply was made to PR kern/86029; it has been noted by GNATS. From: Daniel Eischen To: Christopher Sean Morrison Cc: David Xu , Subject: Re: kern/86029: undefined reference to `_thread_dump_info' Date: Wed, 21 Sep 2005 15:07:16 -0400 (EDT) On Wed, 21 Sep 2005, Christopher Sean Morrison wrote: > On Sep 21, 2005, at 1:28 PM, Daniel Eischen wrote: > > > That's what SIGINFO is for. Again, that's undocumented and > > allowed to change, but it's better than calling a library > > internal function. > > Again, this is really tangent to the whole point of the report, but it > does raise ab additional question. If I raise a SIGINFO, is that going > to give identical detail about the current threading states? I agree > that it's better means to the end. The OpenBSD pthreads(3) manual page > does document the signal but I have not had a motivation to change/test > that bit of code until now. If you're debugging the threads library, you should be looking at its source. SIGINFO just calls _thread_dump_info() (which is not exported in libpthread) and does the same thing. But, SIGINFO was meant more for us to debug the thread library. > Which has always been my understanding of -pthread as well. Does this > mean then that the C library routines on an AMD64 FreeBSD 5.4 system > are supposed to be re-entrant and thread safe? Of course. > If that's the case, > then I probably have another bug report to make. It also doesn't > explain the inconsistency with the same rev of FreeBSD on IA32 systems > where the same behavior is not exhibited. I'm going to close this one. You'll need something that easily regenerates your problem if you file another bug report on it. -- DE From owner-freebsd-threads@FreeBSD.ORG Thu Sep 22 08:10:16 2005 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49BA016A41F for ; Thu, 22 Sep 2005 08:10:16 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05A3143D45 for ; Thu, 22 Sep 2005 08:10:16 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j8M8AFga064419 for ; Thu, 22 Sep 2005 08:10:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j8M8AFkS064418; Thu, 22 Sep 2005 08:10:15 GMT (envelope-from gnats) Date: Thu, 22 Sep 2005 08:10:15 GMT Message-Id: <200509220810.j8M8AFkS064418@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: David Xu Cc: Subject: Re: threads/85160: [patch] libobjc + libpthread/libthr crash problem X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Xu List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2005 08:10:16 -0000 The following reply was made to PR threads/85160; it has been noted by GNATS. From: David Xu To: bug-followup@FreeBSD.org, caelian@gmail.com Cc: Subject: Re: threads/85160: [patch] libobjc + libpthread/libthr crash problem Date: Thu, 22 Sep 2005 16:04:40 +0800 I think it is a problem of ld.so, don't know why it allows code in libpthread to be called before libpthread has initialized it. David Xu From owner-freebsd-threads@FreeBSD.ORG Thu Sep 22 12:20:08 2005 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58C9D16A41F for ; Thu, 22 Sep 2005 12:20:08 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3190243D5F for ; Thu, 22 Sep 2005 12:20:04 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j8MCK41J093927 for ; Thu, 22 Sep 2005 12:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j8MCK4gZ093925; Thu, 22 Sep 2005 12:20:04 GMT (envelope-from gnats) Date: Thu, 22 Sep 2005 12:20:04 GMT Message-Id: <200509221220.j8MCK4gZ093925@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Christopher Sean Morrison Cc: Subject: Re: kern/86029: undefined reference to `_thread_dump_info' X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christopher Sean Morrison List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2005 12:20:08 -0000 The following reply was made to PR kern/86029; it has been noted by GNATS. From: Christopher Sean Morrison To: Daniel Eischen Cc: David Xu , bug-followup@freebsd.org Subject: Re: kern/86029: undefined reference to `_thread_dump_info' Date: Thu, 22 Sep 2005 08:16:26 -0400 On Sep 21, 2005, at 3:07 PM, Daniel Eischen wrote: > If you're debugging the threads library, you should be looking > at its source. SIGINFO just calls _thread_dump_info() (which > is not exported in libpthread) and does the same thing. But, > SIGINFO was meant more for us to debug the thread library. Good to know, sounds like that may be a better solution for this particular situation and esoteric enough to not warrant maintaining the _thread_dump_info() call in order to support older BSD systems that perhaps predate or don't support the SIGINFO behavior. For what it's worth, this bit of code has in fact been used to debug the threading libraries in the past. > I'm going to close this one. You'll need something that > easily regenerates your problem if you file another bug > report on it. Thanks for your suggestions and insight. Cheers! Sean