From bugmaster at FreeBSD.org Mon Nov 3 03:07:01 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 3 03:09:09 2008 Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org Message-ID: <200811031107.mA3B704q011066@freefall.freebsd.org> 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 emaste at freebsd.org Tue Nov 4 06:40:04 2008 From: emaste at freebsd.org (Ed Maste) Date: Tue Nov 4 06:40:09 2008 Subject: threads/128180: pthread_cond_broadcast(3) lost wakeup Message-ID: <200811041440.mA4Ee31J084489@freefall.freebsd.org> The following reply was made to PR threads/128180; it has been noted by GNATS. From: Ed Maste To: bug-followup@FreeBSD.org, kurt@intricatesoftware.com Cc: Subject: Re: threads/128180: pthread_cond_broadcast(3) lost wakeup Date: Tue, 4 Nov 2008 09:09:38 -0500 > The test program doesn't look correct to me. It seems possible > for only a few of the threads (as little as 2) to do all the > work. Thread 1 can start doing work, then wait for a broadcast. > Thread 2 can start doing his work, then broadcast waking thread 1. It looks to me like the "tickets" and "finished" globals should make the test program operate correctly. If the scenario you describe happens, thread 1 will just enter pthread_cond_wait again and wait for the broadcast from the primordial thread. From alfred at freebsd.org Tue Nov 4 07:41:14 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Tue Nov 4 07:41:20 2008 Subject: threads/128180: pthread_cond_broadcast(3) lost wakeup In-Reply-To: <200811041440.mA4Ee31J084489@freefall.freebsd.org> References: <200811041440.mA4Ee31J084489@freefall.freebsd.org> Message-ID: <20081104154113.GP60438@elvis.mu.org> * Ed Maste [081104 06:40] wrote: > The following reply was made to PR threads/128180; it has been noted by GNATS. > > From: Ed Maste > To: bug-followup@FreeBSD.org, kurt@intricatesoftware.com > Cc: > Subject: Re: threads/128180: pthread_cond_broadcast(3) lost wakeup > Date: Tue, 4 Nov 2008 09:09:38 -0500 > > > The test program doesn't look correct to me. It seems possible > > for only a few of the threads (as little as 2) to do all the > > work. Thread 1 can start doing work, then wait for a broadcast. > > Thread 2 can start doing his work, then broadcast waking thread 1. > > It looks to me like the "tickets" and "finished" globals should make > the test program operate correctly. If the scenario you describe > happens, thread 1 will just enter pthread_cond_wait again and wait > for the broadcast from the primordial thread. This bug may have been fixed in 6-stable and 6.4. http://svn.freebsd.org/viewvc/base?view=revision&revision=184172 Can you try upgrading? -- - Alfred Perlstein From emaste at freebsd.org Tue Nov 4 10:15:52 2008 From: emaste at freebsd.org (Ed Maste) Date: Tue Nov 4 10:15:58 2008 Subject: threads/128180: pthread_cond_broadcast(3) lost wakeup In-Reply-To: <20081104154113.GP60438@elvis.mu.org> References: <200811041440.mA4Ee31J084489@freefall.freebsd.org> <20081104154113.GP60438@elvis.mu.org> Message-ID: <20081104180349.GA9527@sandvine.com> On Tue, Nov 04, 2008 at 07:41:13AM -0800, Alfred Perlstein wrote: > This bug may have been fixed in 6-stable and 6.4. > > http://svn.freebsd.org/viewvc/base?view=revision&revision=184172 > > Can you try upgrading? I tried with the changes from r184172, but I'm still able to reproduce the problem using the test app in the PR. With your change it does seem to run for on average about 10 times as long before it hangs though. -Ed From emaste at freebsd.org Tue Nov 4 10:20:04 2008 From: emaste at freebsd.org (Ed Maste) Date: Tue Nov 4 10:20:12 2008 Subject: threads/128180: pthread_cond_broadcast(3) lost wakeup Message-ID: <200811041820.mA4IK3ja048431@freefall.freebsd.org> The following reply was made to PR threads/128180; it has been noted by GNATS. From: Ed Maste To: Cc: bug-followup@FreeBSD.org Subject: Re: threads/128180: pthread_cond_broadcast(3) lost wakeup Date: Tue, 4 Nov 2008 13:16:52 -0500 (I posted this to freebsd-threads@; sending to bug-followup for the benefit of the PR.) On Tue, Nov 04, 2008 at 07:41:13AM -0800, Alfred Perlstein wrote: > This bug may have been fixed in 6-stable and 6.4. > > http://svn.freebsd.org/viewvc/base?view=revision&revision=184172 > > Can you try upgrading? I tested the changes in r184172, but I'm still able to reproduce the problem using the test app. With the change it does seem to run for on average about 10 times as long before it hangs though. From alfred at freebsd.org Tue Nov 4 11:02:21 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Tue Nov 4 11:02:34 2008 Subject: threads/128180: pthread_cond_broadcast(3) lost wakeup In-Reply-To: <20081104180349.GA9527@sandvine.com> References: <200811041440.mA4Ee31J084489@freefall.freebsd.org> <20081104154113.GP60438@elvis.mu.org> <20081104180349.GA9527@sandvine.com> Message-ID: <20081104190221.GT60438@elvis.mu.org> * Ed Maste [081104 10:03] wrote: > On Tue, Nov 04, 2008 at 07:41:13AM -0800, Alfred Perlstein wrote: > > > This bug may have been fixed in 6-stable and 6.4. > > > > http://svn.freebsd.org/viewvc/base?view=revision&revision=184172 > > > > Can you try upgrading? > > I tried with the changes from r184172, but I'm still able to reproduce > the problem using the test app in the PR. With your change it does > seem to run for on average about 10 times as long before it hangs though. Hmm... I'll look into it. -- - Alfred Perlstein From davidxu at freebsd.org Tue Nov 4 21:15:26 2008 From: davidxu at freebsd.org (David Xu) Date: Tue Nov 4 21:15:31 2008 Subject: threads/128180: pthread_cond_broadcast(3) lost wakeup In-Reply-To: <20081104190221.GT60438@elvis.mu.org> References: <200811041440.mA4Ee31J084489@freefall.freebsd.org> <20081104154113.GP60438@elvis.mu.org> <20081104180349.GA9527@sandvine.com> <20081104190221.GT60438@elvis.mu.org> Message-ID: <49112C5A.3060105@freebsd.org> Alfred Perlstein wrote: > * Ed Maste [081104 10:03] wrote: >> On Tue, Nov 04, 2008 at 07:41:13AM -0800, Alfred Perlstein wrote: >> >>> This bug may have been fixed in 6-stable and 6.4. >>> >>> http://svn.freebsd.org/viewvc/base?view=revision&revision=184172 >>> >>> Can you try upgrading? >> I tried with the changes from r184172, but I'm still able to reproduce >> the problem using the test app in the PR. With your change it does >> seem to run for on average about 10 times as long before it hangs though. > > Hmm... I'll look into it. > > I think you had fixed it.;-) From kib at FreeBSD.org Wed Nov 5 04:37:25 2008 From: kib at FreeBSD.org (kib@FreeBSD.org) Date: Wed Nov 5 04:37:32 2008 Subject: threads/126950: [patch] rtld(1): rtld malloc is thread-unsafe Message-ID: <200811051237.mA5CbNKa015156@freefall.freebsd.org> Synopsis: [patch] rtld(1): rtld malloc is thread-unsafe State-Changed-From-To: open->closed State-Changed-By: kib State-Changed-When: Wed Nov 5 12:36:48 UTC 2008 State-Changed-Why: Modified fix committed to HEAD and RELENG&. http://www.freebsd.org/cgi/query-pr.cgi?pr=126950 From linimon at FreeBSD.org Sat Nov 8 18:41:44 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat Nov 8 18:41:55 2008 Subject: threads/128265: [hang] deadlock in pthread_create occurs in case if any C++ exception was thrown and succesfully catched Message-ID: <200811090241.mA92fi0N075700@freefall.freebsd.org> Old Synopsis: deadlock in pthread_create occurs in case if any C++ exception was thrown and succesfully catched New Synopsis: [hang] deadlock in pthread_create occurs in case if any C++ exception was thrown and succesfully catched Responsible-Changed-From-To: freebsd-i386->freebsd-threads Responsible-Changed-By: linimon Responsible-Changed-When: Sun Nov 9 02:40:51 UTC 2008 Responsible-Changed-Why: Reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=128265 From kib at FreeBSD.org Sun Nov 9 05:42:43 2008 From: kib at FreeBSD.org (kib@FreeBSD.org) Date: Sun Nov 9 05:42:49 2008 Subject: threads/128265: [hang] deadlock in pthread_create occurs in case if any C++ exception was thrown and succesfully catched Message-ID: <200811091342.mA9DgggS021373@freefall.freebsd.org> Synopsis: [hang] deadlock in pthread_create occurs in case if any C++ exception was thrown and succesfully catched State-Changed-From-To: open->closed State-Changed-By: kib State-Changed-When: Sun Nov 9 13:40:28 UTC 2008 State-Changed-Why: This should be fixed by r183061 on HEAD and its MFC as r184497 on 7. http://www.freebsd.org/cgi/query-pr.cgi?pr=128265 From bugmaster at FreeBSD.org Mon Nov 10 03:06:59 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 10 03:09:18 2008 Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org Message-ID: <200811101106.mAAB6wRC049879@freefall.freebsd.org> 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 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 38 problems total. From davidxu at FreeBSD.org Mon Nov 10 18:15:56 2008 From: davidxu at FreeBSD.org (davidxu@FreeBSD.org) Date: Mon Nov 10 18:16:02 2008 Subject: kern/126128: [patch] pthread_condattr_getpshared is broken Message-ID: <200811110215.mAB2Fs6B032903@freefall.freebsd.org> Synopsis: [patch] pthread_condattr_getpshared is broken State-Changed-From-To: open->closed State-Changed-By: davidxu State-Changed-When: Tue Nov 11 02:13:12 UTC 2008 State-Changed-Why: Fixed. http://www.freebsd.org/cgi/query-pr.cgi?pr=126128 From dreigcht at gmail.com Sun Nov 16 11:20:02 2008 From: dreigcht at gmail.com (Peter) Date: Sun Nov 16 11:20:08 2008 Subject: threads/128922: threads hang with xorg running Message-ID: <200811161918.mAGJI4TI086649@www.freebsd.org> >Number: 128922 >Category: threads >Synopsis: threads hang with xorg running >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-threads >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Nov 16 19:20:01 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Peter >Release: 7.0 >Organization: Private >Environment: FreeBSD 7.0-RELEASE-p5 amd64 >Description: The following program runs perfectly on FreeBSD 6.3 amd64 (with xorg running and without xorg running). But on FreeBSD 7.0 amd64 and 7.1 beta amd64 (only with xorg running) after a few seconds of working the thread "period_thread" hangs printing only one time a second and even less. Moreover, the whole system becomes slow though "top" does not show a heavy load. Tried on Intel E6600 and on Intel E1200 with the same result. Tried with GENERIC kernel "out of the box" and with my kernel configurations with the same result. Tried with 4BSD and ULE schedulers with the same result. #include #include #include #include void* thread(void* q) { const size_t SIZE = 500; volatile double vec[SIZE]; size_t cnt; for(cnt = 0; cnt < 1000000; ++cnt) { size_t i; for(i = 0; i < SIZE; ++i) { vec[i] = 0; } for(i = 0; i < SIZE; ++i) { vec[i] += i; vec[i] -= i; } } } void* period_thread(void* q) { int i; for(i = 0;;++i) { printf("period thread %i\n", i); usleep( 50 * 1000 ); } } int main( int argc, char** argv ) { pthread_t hs; pthread_create(&hs, NULL, period_thread, NULL); for(;;) { const size_t SIZE = 5; pthread_t h[SIZE]; size_t i; for(i = 0; i < SIZE; ++i) { pthread_create( &h[i], NULL, thread, NULL); } for(i = 0; i < SIZE; ++i) { pthread_join(h[i], NULL); } } } >How-To-Repeat: Run the program on FreeBSD 7.0 amd64 or 7.1 beta amd64 in xterm, konsole, etc (xorg running). >Fix: Patch attached with submission follows: #include #include #include #include void* thread(void* q) { const size_t SIZE = 500; volatile double vec[SIZE]; size_t cnt; for(cnt = 0; cnt < 1000000; ++cnt) { size_t i; for(i = 0; i < SIZE; ++i) { vec[i] = 0; } for(i = 0; i < SIZE; ++i) { vec[i] += i; vec[i] -= i; } } } void* period_thread(void* q) { int i; for(i = 0;;++i) { printf("period thread %i\n", i); usleep( 50 * 1000 ); } } int main( int argc, char** argv ) { pthread_t hs; pthread_create(&hs, NULL, period_thread, NULL); for(;;) { const size_t SIZE = 5; pthread_t h[SIZE]; size_t i; for(i = 0; i < SIZE; ++i) { pthread_create( &h[i], NULL, thread, NULL); } for(i = 0; i < SIZE; ++i) { pthread_join(h[i], NULL); } } } >Release-Note: >Audit-Trail: >Unformatted: From dreigcht at gmail.com Sun Nov 16 12:00:46 2008 From: dreigcht at gmail.com (Peter Dreight) Date: Sun Nov 16 12:01:16 2008 Subject: threads hang with xorg running Message-ID: The following program runs perfectly on FreeBSD 6.3 amd64 (with xorg running and without xorg running). But on FreeBSD 7.0 amd64 and 7.1 beta amd64 (only with xorg running - xterm - konsole - etc) after a few seconds of working the thread "period_thread" hangs printing only one time a second and even less. Moreover, the whole system becomes slow though "top" does not show a heavy load. Tried on Intel E6600 and on Intel E1200 with the same result. Tried with GENERIC kernel "out of the box" and with my kernel configurations with the same result. Tried with 4BSD and ULE schedulers with the same result. #include #include #include #include void* heavy_thread(void* q) { const size_t SIZE = 500; volatile double vec[SIZE]; size_t cnt; for(cnt = 0; cnt < 1000000; ++cnt) { size_t i; for(i = 0; i < SIZE; ++i) { vec[i] = 0; } for(i = 0; i < SIZE; ++i) { vec[i] += i; vec[i] -= i; } } } void* period_thread(void* q) { int i; for(i = 0;;++i) { printf("period thread %i\n", i); usleep( 50 * 1000 ); } } int main( int argc, char** argv ) { pthread_t hs; pthread_create(&hs, NULL, period_thread, NULL); for(;;) { const size_t SIZE = 5; pthread_t h[SIZE]; size_t i; for(i = 0; i < SIZE; ++i) { pthread_create( &h[i], NULL, heavy_thread, NULL); } for(i = 0; i < SIZE; ++i) { pthread_join(h[i], NULL); } } } From bugmaster at FreeBSD.org Mon Nov 17 03:06:58 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 17 03:09:21 2008 Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org Message-ID: <200811171106.mAHB6wXA082685@freefall.freebsd.org> 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/128922 threads threads hang with xorg running o threa/128180 threads pthread_cond_broadcast(3) lost wakeup o threa/127225 threads bug in lib/libthr/thread/thr_init.c 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 38 problems total. From dreigcht at gmail.com Tue Nov 18 03:30:05 2008 From: dreigcht at gmail.com (Peter Dreight) Date: Tue Nov 18 03:30:24 2008 Subject: threads/128922: threads hang with xorg running Message-ID: <200811181130.mAIBU58r013984@freefall.freebsd.org> The following reply was made to PR threads/128922; it has been noted by GNATS. From: "Peter Dreight" To: bug-followup@freebsd.org Cc: Subject: Re: threads/128922: threads hang with xorg running Date: Tue, 18 Nov 2008 14:02:17 +0300 ------=_Part_56596_23614366.1227006137300 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Some additional information: The example works fine on FreeBSD 6.3: when linked with libpthread (-lpthread) or when linked with libthr (-lthr) The example works fine on FreeBSD 7.0 and 7.1: when linked with libkse (-lkse) The example does not work and threads hang as I described earlier: when linked with lthr (-lthr or -lpthread that is the same on FreeBSD 7). Therefore it seems to me that there is some problem in the new version of the library "libthr" included in FreeBSD 7.0 and 7.1. ------=_Part_56596_23614366.1227006137300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Some additional information:

The example works fine on FreeBSD 6.3:
   when linked with libpthread (-lpthread)
  or
   when linked with libthr  (-lthr)

The example works fine on FreeBSD 7.0 and 7.1:
    when linked with libkse  (-lkse)

The example does not work and threads hang as I described earlier:
    when linked with lthr (-lthr or -lpthread that is the same on FreeBSD 7).

Therefore it seems to me that there is some problem in the new version
of the library "libthr" included in FreeBSD 7.0 and 7.1.
------=_Part_56596_23614366.1227006137300-- From bugmaster at FreeBSD.org Mon Nov 24 03:07:24 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 24 03:09:21 2008 Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org Message-ID: <200811241107.mAOB7NOv020065@freefall.freebsd.org> 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/128922 threads threads hang with xorg running o threa/128180 threads pthread_cond_broadcast(3) lost wakeup o threa/127225 threads bug in lib/libthr/thread/thr_init.c 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 [patch] 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 38 problems total.