You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(6) |
2
(7) |
3
(7) |
4
(5) |
5
|
|
6
|
7
|
8
|
9
(5) |
10
(4) |
11
(5) |
12
(1) |
|
13
(2) |
14
(1) |
15
(2) |
16
(5) |
17
|
18
|
19
|
|
20
|
21
(1) |
22
(8) |
23
(1) |
24
|
25
|
26
(1) |
|
27
(5) |
28
|
29
(15) |
30
(9) |
31
(12) |
|
|
|
From: Konstantin S. <kon...@gm...> - 2009-12-09 23:09:07
|
Thanks a lot, Greg. I think your explanation is enough to fix the problem in Helgrind/DRD/TSan --kcc On Thu, Dec 10, 2009 at 1:36 AM, Greg Parker <gp...@ap...> wrote: > On Dec 9, 2009, at 1:50 PM, Konstantin Serebryany wrote: > > On Wed, Dec 9, 2009 at 11:42 PM, Greg Parker <gp...@ap...> wrote: > >> On Dec 9, 2009, at 9:13 AM, Alexander Potapenko wrote: > >>> > >>> drd: drd_thread.c:584 (vgDrd_thread_set_vg_running_tid): Assertion > >>> vg_tid != VG_INVALID_THREADID' failed. > >>> ==68403== at 0xF009DCBD: ??? > >>> ==68403== by 0xF009DF71: ??? > >> > >> First guess: either Valgrind or those tools aren't correctly handling > the thread-creation mechanisms used by NSOperationQueue. Work queues don't > go through the normal thread entry points. > > > > You mean that NSOperationQueue can create a thread w/o calling > pthread_create()? > > That's right. (There's also pthread_create_suspended_np(), but I don't know > of anyone who uses that.) > > > > Than yes, the tools don't know anything about that. > > Could you point to any piece of documentation and/or source code which > explains how threads are created by NSOperationQueue? > > Valgrind works at the kernel interface. At this level, pthreads mostly > don't exist; the kernel deals in Mach threads, and pthreads are built on top > by Libc. In particular, there is no pthread_create() system call. > > Workqueue threads are another kernel construct used to support > NSOperationQueue and Grand Central Dispatch. Most of the time a workqueue > thread does get a pthread built atop it, just like most Mach threads are > wrapped in a pthread. But the construction process is different, and does > not call Libc's pthread_create(). > > Workqueue threads are created at the kernel's whim. They simply appear in > the process without an explicit user-space request. Each workqueue thread > starts its execution de novo in a function provided by Libc, which builds > the pthread if necessary and executes a work item. > > During process startup, Libc calls the bsdthread_register() syscall, which > among other things tells the kernel the entry point for new workqueue > threads (_pthread_wqthread()). Valgrind traps bsdthread_register() and > substitutes its own function wqthread_hijack_asm(). When the kernel starts a > workqueue thread in a Valgrind process, it starts in wqthread_hijack_asm() > on the real CPU, which in turn bootstraps the thread into Valgrind's > simulator and calls Libc's entry point. > > Valgrind's pthread-tracing system would need to do its work inside > wqthread_hijack(). I think workqueue threads call the ordinary > pthread_exit() on their way out, so you might not need extra handling there. > > I don't know of any documentation for any of this; like the rest of the > kernel-libc interface, it's private and subject to change at any time. > Everything I know I learned from reading xnu and Libc source. > > > -- > Greg Parker gp...@ap... Runtime Wrangler > > > |
|
From: Greg P. <gp...@ap...> - 2009-12-09 22:36:44
|
On Dec 9, 2009, at 1:50 PM, Konstantin Serebryany wrote: > On Wed, Dec 9, 2009 at 11:42 PM, Greg Parker <gp...@ap...> wrote: >> On Dec 9, 2009, at 9:13 AM, Alexander Potapenko wrote: >>> >>> drd: drd_thread.c:584 (vgDrd_thread_set_vg_running_tid): Assertion >>> vg_tid != VG_INVALID_THREADID' failed. >>> ==68403== at 0xF009DCBD: ??? >>> ==68403== by 0xF009DF71: ??? >> >> First guess: either Valgrind or those tools aren't correctly handling the thread-creation mechanisms used by NSOperationQueue. Work queues don't go through the normal thread entry points. > > You mean that NSOperationQueue can create a thread w/o calling pthread_create()? That's right. (There's also pthread_create_suspended_np(), but I don't know of anyone who uses that.) > Than yes, the tools don't know anything about that. > Could you point to any piece of documentation and/or source code which explains how threads are created by NSOperationQueue? Valgrind works at the kernel interface. At this level, pthreads mostly don't exist; the kernel deals in Mach threads, and pthreads are built on top by Libc. In particular, there is no pthread_create() system call. Workqueue threads are another kernel construct used to support NSOperationQueue and Grand Central Dispatch. Most of the time a workqueue thread does get a pthread built atop it, just like most Mach threads are wrapped in a pthread. But the construction process is different, and does not call Libc's pthread_create(). Workqueue threads are created at the kernel's whim. They simply appear in the process without an explicit user-space request. Each workqueue thread starts its execution de novo in a function provided by Libc, which builds the pthread if necessary and executes a work item. During process startup, Libc calls the bsdthread_register() syscall, which among other things tells the kernel the entry point for new workqueue threads (_pthread_wqthread()). Valgrind traps bsdthread_register() and substitutes its own function wqthread_hijack_asm(). When the kernel starts a workqueue thread in a Valgrind process, it starts in wqthread_hijack_asm() on the real CPU, which in turn bootstraps the thread into Valgrind's simulator and calls Libc's entry point. Valgrind's pthread-tracing system would need to do its work inside wqthread_hijack(). I think workqueue threads call the ordinary pthread_exit() on their way out, so you might not need extra handling there. I don't know of any documentation for any of this; like the rest of the kernel-libc interface, it's private and subject to change at any time. Everything I know I learned from reading xnu and Libc source. -- Greg Parker gp...@ap... Runtime Wrangler |
|
From: Konstantin S. <kon...@gm...> - 2009-12-09 21:50:44
|
On Wed, Dec 9, 2009 at 11:42 PM, Greg Parker <gp...@ap...> wrote: > > On Dec 9, 2009, at 9:13 AM, Alexander Potapenko wrote: > > > Hi everyone, > > > > Debugging ThreadSanitizer for Mac OS > > (http://code.google.com/p/data-race-test) I've came up with a small > > piece of code that makes Valgrind-based threading tools act in a weird > > manner. > > > > The attached code exploits NSOperationQueue from the Foundation > > library. > > > > But neither DRD nor Helgrind cannot cope with this binary: > > > > drd: drd_thread.c:584 (vgDrd_thread_set_vg_running_tid): Assertion > > 'vg_tid != VG_INVALID_THREADID' failed. > > ==68403== at 0xF009DCBD: ??? > > ==68403== by 0xF009DF71: ??? > > ... > > > > sched status: > > running_tid=0 > > > > Thread 1: status = VgTs_WaitSys > > ==68403== at 0x7DDC62: ioctl (in /usr/lib/libSystem.B.dylib) > > ==68403== by 0x7EB00A: __smakebuf (in /usr/lib/libSystem.B.dylib) > > ==68403== by 0x7EAF0C: __swsetup (in /usr/lib/libSystem.B.dylib) > > ==68403== by 0x7BAF8D: __sfvwrite (in /usr/lib/libSystem.B.dylib) > > ==68403== by 0x82618F: puts (in /usr/lib/libSystem.B.dylib) > > ==68403== by 0x1D0E: Printer::Print() (in > > /Users/glider/src/worker_vex_test/nsop) > > ==68403== by 0x1BAD: main (in /Users/glider/src/worker_vex_test/nsop) > > > > Thread 2: status = VgTs_Init > > ==68403== at 0x81E2A4: start_wqthread (in /usr/lib/libSystem.B.dylib) > > > > > > Looks like Valgrind tries to execute code in a previously unknown > > thread without calling the pre_thread_ll_create method for this > > thread. > > > > Does anyone know whether this is a real bug in VEX or just a > > NSOperationQueue misuse? > > First guess: either Valgrind or those tools aren't correctly handling the > thread-creation mechanisms used by NSOperationQueue. Work queues don't go > through the normal thread entry points. > You mean that NSOperationQueue can create a thread w/o calling pthread_create()? Than yes, the tools don't know anything about that. Could you point to any piece of documentation and/or source code which explains how threads are created by NSOperationQueue? Thanks, --kcc > > > -- > Greg Parker gp...@ap... Runtime Wrangler > > > > > ------------------------------------------------------------------------------ > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Greg P. <gp...@ap...> - 2009-12-09 20:49:51
|
On Dec 9, 2009, at 9:13 AM, Alexander Potapenko wrote: > Hi everyone, > > Debugging ThreadSanitizer for Mac OS > (http://code.google.com/p/data-race-test) I've came up with a small > piece of code that makes Valgrind-based threading tools act in a weird > manner. > > The attached code exploits NSOperationQueue from the Foundation > library. > > But neither DRD nor Helgrind cannot cope with this binary: > > drd: drd_thread.c:584 (vgDrd_thread_set_vg_running_tid): Assertion > 'vg_tid != VG_INVALID_THREADID' failed. > ==68403== at 0xF009DCBD: ??? > ==68403== by 0xF009DF71: ??? > ... > > sched status: > running_tid=0 > > Thread 1: status = VgTs_WaitSys > ==68403== at 0x7DDC62: ioctl (in /usr/lib/libSystem.B.dylib) > ==68403== by 0x7EB00A: __smakebuf (in /usr/lib/libSystem.B.dylib) > ==68403== by 0x7EAF0C: __swsetup (in /usr/lib/libSystem.B.dylib) > ==68403== by 0x7BAF8D: __sfvwrite (in /usr/lib/libSystem.B.dylib) > ==68403== by 0x82618F: puts (in /usr/lib/libSystem.B.dylib) > ==68403== by 0x1D0E: Printer::Print() (in > /Users/glider/src/worker_vex_test/nsop) > ==68403== by 0x1BAD: main (in /Users/glider/src/worker_vex_test/nsop) > > Thread 2: status = VgTs_Init > ==68403== at 0x81E2A4: start_wqthread (in /usr/lib/libSystem.B.dylib) > > > Looks like Valgrind tries to execute code in a previously unknown > thread without calling the pre_thread_ll_create method for this > thread. > > Does anyone know whether this is a real bug in VEX or just a > NSOperationQueue misuse? First guess: either Valgrind or those tools aren't correctly handling the thread-creation mechanisms used by NSOperationQueue. Work queues don't go through the normal thread entry points. -- Greg Parker gp...@ap... Runtime Wrangler |
|
From: Alexander P. <gl...@go...> - 2009-12-09 17:13:45
|
Hi everyone, Debugging ThreadSanitizer for Mac OS (http://code.google.com/p/data-race-test) I've came up with a small piece of code that makes Valgrind-based threading tools act in a weird manner. The attached code exploits NSOperationQueue from the Foundation library. To build it, just run: $ g++ nsop.mm -o nsop -framework Foundation If I run ./nsop natively, I get something like: 2009-12-09 19:58:33.021 nsop[64614:10b] *** _NSAutoreleaseNoPool(): Object 0x106580 of class __NSFastEnumerationEnumerator autoreleased with no pool in place - just leaking Stack: (0x92a01f0f 0x9290e442 0x929a41d2 0x929a4597) 2009-12-09 19:58:33.022 nsop[64614:10b] *** _NSAutoreleaseNoPool(): Object 0x10c490 of class NSCFSet autoreleased with no pool in place - just leaking Stack: (0x92a01f0f 0x9290e442 0x92926e63 0x92926b3c 0x929267b8 0x92926493 0x92926242 0x92925e3e 0x929a420f 0x929a4597) 2009-12-09 19:58:33.022 nsop[64614:10b] *** _NSAutoreleaseNoPool(): Object 0x10ce40 of class NSCFSet autoreleased with no pool in place - just leaking Stack: (0x92a01f0f 0x9290e442 0x92926e63 0x92926b3c 0x929267b8 0x92926493 0x92926242 0x92925e3e 0x929a420f 0x929a4597) Printer::Print() BYE Task::Run() But neither DRD nor Helgrind cannot cope with this binary: $ inst/bin/valgrind --tool=drd /Users/glider/src/worker_vex_test/nsop 2>&1 ==68403== drd, a thread error detector ... --68403-- /Users/glider/src/worker_vex_test/nsop: --68403-- dSYM directory is missing; consider using --dsymutil=yes 2009-12-09 20:02:14.368 nsop[68403:50b] *** _NSAutoreleaseNoPool(): Object 0x1cb4d40 of class __NSFastEnumerationEnumerator autoreleased with no pool in place - just leaking Stack: (0x4d1f0f 0x3de442 0x4741d2 0x474597) 2009-12-09 20:02:14.617 nsop[68403:50b] *** _NSAutoreleaseNoPool(): Object 0x1cbcff0 of class NSCFSet autoreleased with no pool in place - just leaking Stack: (0x4d1f0f 0x3de442 0x3f6e63 0x3f6b3c 0x3f67b8 0x3f6493 0x3f6242 0x3f5e3e 0x47420f 0x474597) 2009-12-09 20:02:14.659 nsop[68403:50b] *** _NSAutoreleaseNoPool(): Object 0x1cc12e0 of class NSCFSet autoreleased with no pool in place - just leaking Stack: (0x4d1f0f 0x3de442 0x3f6e63 0x3f6b3c 0x3f67b8 0x3f6493 0x3f6242 0x3f5e3e 0x47420f 0x474597) drd: drd_thread.c:584 (vgDrd_thread_set_vg_running_tid): Assertion 'vg_tid != VG_INVALID_THREADID' failed. ==68403== at 0xF009DCBD: ??? ==68403== by 0xF009DF71: ??? ... sched status: running_tid=0 Thread 1: status = VgTs_WaitSys ==68403== at 0x7DDC62: ioctl (in /usr/lib/libSystem.B.dylib) ==68403== by 0x7EB00A: __smakebuf (in /usr/lib/libSystem.B.dylib) ==68403== by 0x7EAF0C: __swsetup (in /usr/lib/libSystem.B.dylib) ==68403== by 0x7BAF8D: __sfvwrite (in /usr/lib/libSystem.B.dylib) ==68403== by 0x82618F: puts (in /usr/lib/libSystem.B.dylib) ==68403== by 0x1D0E: Printer::Print() (in /Users/glider/src/worker_vex_test/nsop) ==68403== by 0x1BAD: main (in /Users/glider/src/worker_vex_test/nsop) Thread 2: status = VgTs_Init ==68403== at 0x81E2A4: start_wqthread (in /usr/lib/libSystem.B.dylib) Looks like Valgrind tries to execute code in a previously unknown thread without calling the pre_thread_ll_create method for this thread. Does anyone know whether this is a real bug in VEX or just a NSOperationQueue misuse? Thanks, Alexander Potapenko Software Engineer Google Moscow PS. I've filed https://bugs.kde.org/show_bug.cgi?id=216837 some time ago. There is a more practical example of NSOperationQueue use that crashes Helgrind/DRD/TSan as well. |