From owner-freebsd-threads@FreeBSD.ORG Mon May 8 11:02:53 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6577E16A40D for ; Mon, 8 May 2006 11:02:53 +0000 (UTC) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78BA543D49 for ; Mon, 8 May 2006 11:02:44 +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.4/8.13.4) with ESMTP id k48B2h27048484 for ; Mon, 8 May 2006 11:02:43 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k48B2gS3048478 for freebsd-threads@freebsd.org; Mon, 8 May 2006 11:02:42 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 8 May 2006 11:02:42 GMT Message-Id: <200605081102.k48B2gS3048478@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, 08 May 2006 11:02:54 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- s [2005/01/26] threads/76690threads fork hang in child for (-lc_r & -lthr) 1 problem total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/07/18] kern/20016 threads pthreads: Cannot set scheduling timer/Can s [2001/01/20] threads/24472threads libc_r does not honor SO_SNDTIMEO/SO_RCVT s [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 s [2001/11/26] bin/32295 threads pthread dont dequeue signals s [2002/02/01] threads/34536threads accept() blocks other threads o [2002/05/25] kern/38549 threads the procces compiled whith pthread stoppe s [2002/06/27] threads/39922threads [threads] [patch] Threaded applications e o [2002/08/04] kern/41331 threads Pthread library open sets O_NONBLOCK flag s [2003/03/02] threads/48856threads Setting SIGCHLD to SIG_IGN still leaves z s [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/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 s [2005/01/26] threads/76694threads fork cause hang in dup()/close() function p [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/07/22] threads/83914threads [libc] popen() doesn't work in static thr s [2005/08/02] threads/84483threads problems with devel/nspr and -lc_r on 4.x o [2005/08/20] threads/85160threads [libthr] [patch] libobjc + libpthread/lib p [2005/11/19] threads/89262threads [kernel] [patch] multi-threaded process h o [2005/12/12] threads/90278threads libthr, ULE and -current produces >100% W o [2006/01/03] kern/91266 threads [threads] Trying sleep, but thread marked s [2006/03/15] threads/94467threads send(), sendto() and sendmsg() are not co 30 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- s [2000/06/13] kern/19247 threads uthread_sigaction.c does not do anything s [2000/10/21] kern/22190 threads A threaded read(2) from a socketpair(2) f s [2001/09/09] threads/30464threads pthread mutex attributes -- pshared s [2002/05/02] threads/37676threads libc_r: msgsnd(), msgrcv(), pread(), pwri s [2002/07/16] threads/40671threads pthread_cancel doesn't remove thread from s [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/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 [libc_r] [patch] libc_r close() will fail 11 problems total. From owner-freebsd-threads@FreeBSD.ORG Mon May 8 18:16:35 2006 Return-Path: X-Original-To: freebsd-threads@FreeBSD.org Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5CE216A400 for ; Mon, 8 May 2006 18:16:35 +0000 (UTC) (envelope-from mark@noc.mainstreet.net) Received: from noc.mainstreet.net (noc.mainstreet.net [207.5.0.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D4EE43D45 for ; Mon, 8 May 2006 18:16:35 +0000 (GMT) (envelope-from mark@noc.mainstreet.net) Received: from localhost (localhost [127.0.0.1]) by noc.mainstreet.net (Postfix) with ESMTP id 7AC5528549 for ; Mon, 8 May 2006 11:16:35 -0700 (PDT) Received: from noc.mainstreet.net ([127.0.0.1]) by localhost (noc.mainstreet.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40714-02 for ; Mon, 8 May 2006 11:16:34 -0700 (PDT) Received: by noc.mainstreet.net (Postfix, from userid 1002) id CCAA228548; Mon, 8 May 2006 11:16:34 -0700 (PDT) From: Mark Kent To: freebsd-threads@FreeBSD.org Message-Id: <20060508181634.CCAA228548@noc.mainstreet.net> Date: Mon, 8 May 2006 11:16:34 -0700 (PDT) Cc: Subject: different behaviour with different libs 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, 08 May 2006 18:16:35 -0000 Hello, What is the canonical way to compile programs that use posix threads on freebsd 5.4+, with gcc? I've seen comments that say that -pthread, used in 4.x, should go away for 5.x. But, for example, /usr/ports/security/openssl uses -pthread. So, use it? Don't use it? Should I care? And what does it mean when a program works with one thread library and not another? I've got a case like this: libpthread.so.1: chew up cpu, then SEGV libthr.so.1: chew up cpu, but works! libc_r.so.5: works great! This is changed with libmap.conf. Does this point to any particular shady coding practice? Once I know that libc_r is my friend, does this suggest a certain set of compile flags and/or link flags? Thanks, -mark From owner-freebsd-threads@FreeBSD.ORG Fri May 12 12:00:53 2006 Return-Path: X-Original-To: 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 2599416A46D for ; Fri, 12 May 2006 12:00:53 +0000 (UTC) (envelope-from avleeuwen@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8606F43D62 for ; Fri, 12 May 2006 12:00:38 +0000 (GMT) (envelope-from avleeuwen@gmail.com) Received: by wx-out-0102.google.com with SMTP id s19so308841wxc for ; Fri, 12 May 2006 05:00:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=MlC9nHDmp3yTKDx5sxGRm8OI7dvcrvn2y5DpxvPQLh4fqpyZVIi+ISQxEJHObFm4lzTt/TY2gP8jN8EQvQ4libDHQx+dCtgxG/F+meCnqY1ACOIvGude9JOOiL1te0kUStSaZ9fz/jMXGfrW/BZgZVJc3qGhr8hgTY7IcyUhiFg= Received: by 10.70.100.16 with SMTP id x16mr2818239wxb; Fri, 12 May 2006 05:00:36 -0700 (PDT) Received: by 10.70.97.17 with HTTP; Fri, 12 May 2006 05:00:36 -0700 (PDT) Message-ID: Date: Fri, 12 May 2006 14:00:36 +0200 From: "Arjan van Leeuwen" To: threads@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Using libthr causes SIGFPE when running Qt applications in gdb X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: avleeuwen@piwebs.com List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2006 12:00:53 -0000 When using libthr (mapped from libpthread via libmap.conf) on FreeBSD 6.1-RELEASE, I can't run any Qt applications from gdb. Any application I ru= n reports: Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 0x8c93000 (LWP 100120)] 0x2915ddb7 in QLocalePrivate::stringToDouble () from /usr/X11R6/lib/libqt- mt.so.3 (gdb) bt #0 0x2915ddb7 in QLocalePrivate::stringToDouble () from /usr/X11R6/lib/libqt-mt.so.3 #1 0x2917308c in QString::toDouble () from /usr/X11R6/lib/libqt-mt.so.3 #2 0x28e8967b in QFont::fromString () from /usr/X11R6/lib/libqt-mt.so.3 #3 0x28e0d712 in QApplication::x11_apply_settings () from /usr/X11R6/lib/libqt-mt.so.3 #4 0x28e0e63e in qt_set_x11_resources () from /usr/X11R6/lib/libqt-mt.so.3 #5 0x28e126fe in qt_init_internal () from /usr/X11R6/lib/libqt-mt.so.3 #6 0x28e14bac in qt_init () from /usr/X11R6/lib/libqt-mt.so.3 #7 0x28e74231 in QApplication::construct () from /usr/X11R6/lib/libqt- mt.so.3 #8 0x28e7465c in QApplication::QApplication () from /usr/X11R6/lib/libqt- mt.so.3 The applications run fine outside of gdb or when switching back to libpthread. Is this a known problem? If so, is there also a known solution? :) Best regards, Arjan van Leeuwen