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
(4) |
2
(17) |
3
(9) |
4
(14) |
5
(10) |
6
(11) |
7
(8) |
|
8
(9) |
9
(11) |
10
(29) |
11
(27) |
12
(29) |
13
(36) |
14
(8) |
|
15
(18) |
16
(30) |
17
(25) |
18
(6) |
19
(16) |
20
(13) |
21
(10) |
|
22
(16) |
23
(7) |
24
(8) |
25
(13) |
26
(14) |
27
(14) |
28
(5) |
|
29
(6) |
30
(21) |
31
(14) |
|
|
|
|
|
From: Greg P. <gp...@ap...> - 2009-03-05 21:56:52
|
On Mar 5, 2009, at 1:48 PM, Nicholas Nethercote wrote:
> On Fri, Mar 6, 2009 at 6:23 AM, Maurice van der Pot
> <gri...@kf...> wrote:
>> Instead of using a
>> symbol name, the code should use a forward label, as in
>> call 1f;
>> 1: popl %0
>> Or it should use some other technique to ensure a unique name.
>
> Which I'd be happy to use if I understood how it worked and knew it
> was
> portable (ie. would work with all GCCs back to 3.0). Can anyone
> enlighten
> me?
You can have labels that are numbers (single-digit only, I think).
1: push %eax
push %ecx
call 1f
1: popl %0
1: ret
These labels are allowed multiple times. Each use is disambiguated:
"1f" means "the next label 1 forward" and "1b" means "the previous
label 1 back". This is safe as long as there's no way for additional
code (with more number labels) to be introduced between the label and
its uses. A single "asm" is safe, because GCC simply writes your asm
directly to the .s, without mingling it with any other instructions.
This is an assembler convention of which GCC is blissfully unaware, so
it should work with all versions of GCC.
--
Greg Parker gp...@ap... Runtime Wrangler
|
|
From: Nicholas N. <n.n...@gm...> - 2009-03-05 21:48:40
|
On Fri, Mar 6, 2009 at 6:23 AM, Maurice van der Pot <gri...@kf...> wrote: > > I'm not sure if this problem interests anyone, because firstly gcc 4.4 > has not been released yet and secondly it only occurs with -O3 (for > which valgrind's configure has to be patched). > > The problem is in the use of global labels in pieces of asm that may be > duplicated because of inlining and things like that. > > I reported a similar issue in the tests earlier: > https://bugs.kde.org/show_bug.cgi?id=179731 > > The current issue is described in more detail here: > http://bugs.gentoo.org/show_bug.cgi?id=260802 > > Should I submit a bug in valgrind's bugzilla or would you rather not > have bug reports for custom CFLAGS? If Valgrind's inline asm is dodgy, then we should fix it. To summarise the links, we have this code: #if defined(VGP_x86_linux) # define GET_REAL_PC_SP_AND_FP(pc, sp, fp) \ asm("call m_libcassert_get_ip;" \ "m_libcassert_get_ip: popl %0;" \ "movl %%esp, %1;" \ "movl %%ebp, %2;" \ : "=r" (pc),\ "=r" (sp),\ "=r" (fp)); One of the commenters at the Gentoo link says this: > I would say that this is a valgrind bug, a misuse of inline asm. gcc > never promises that it will only emit one instance of the asm, > especially if, as here, the asm is not volatile. (The GCC option seems to be one that causes some code to be cloned, hence the repeated label.) > Instead of using a > symbol name, the code should use a forward label, as in > call 1f; > 1: popl %0 > Or it should use some other technique to ensure a unique name. Which I'd be happy to use if I understood how it worked and knew it was portable (ie. would work with all GCCs back to 3.0). Can anyone enlighten me? N |
|
From: Maurice v. d. P. <gri...@kf...> - 2009-03-05 19:44:50
|
Dear devs, I'm not sure if this problem interests anyone, because firstly gcc 4.4 has not been released yet and secondly it only occurs with -O3 (for which valgrind's configure has to be patched). The problem is in the use of global labels in pieces of asm that may be duplicated because of inlining and things like that. I reported a similar issue in the tests earlier: https://bugs.kde.org/show_bug.cgi?id=179731 The current issue is described in more detail here: http://bugs.gentoo.org/show_bug.cgi?id=260802 Should I submit a bug in valgrind's bugzilla or would you rather not have bug reports for custom CFLAGS? Best regards, Maurice. -- Maurice van der Pot Gentoo Linux Developer gri...@ge... http://www.gentoo.org Gnome Planner Developer gri...@kf... http://live.gnome.org/Planner |
|
From: Bart V. A. <bar...@gm...> - 2009-03-05 14:22:23
|
2009/3/5 Tayfun Elmas <tay...@gm...>: > This is an experimental study and Pinar's senior project. We previously > implemented Goldilocks inside a Java VM and showed that it can run faster > than Eraser and standard happens-before algorithm. We would like to see how > it is costly to implement Goldilocks via code instrumentation. We benefited > from the source code of Helgrind to understand how a race detected can be > implemented in Valgrind. That sounds interesting. In my previous e-mail I should have added that installing the glibc-debuginfo package will probably help: most Linux distributors strip debug information from glibc and ld.so before shipping. Installing the glibc-debuginfo package will allow Valgrind to print more detailed stack traces for the functions inside glibc and ld.so. Bart. |
|
From: Konstantin S. <kon...@gm...> - 2009-03-05 13:12:27
|
2009/3/5 Tayfun Elmas <tay...@gm...>: > Let me briefly restate the question. The algorithm we are implementing has > special rules to handle pthread_xxx functions. We would like to be notified > when a pthread_xxx function is called but would like NOT to be notified > whatever happens within these functions. You can disable notifications while in ptread_xxx Like this: http://code.google.com/p/data-race-test/source/browse/trunk/tsan/ts_valgrind_intercepts.c#427 > As a result, we want the sample > code Pinar sent to trigger our algorithm when pthread_create and > pthread_join are called but not any other time. I think there is some > mechanism in Valgrind to do this, but we could not understand it clearly. > Thanks. > > Tayfun > - Show quoted text - > > Konstantin Serebryany wrote: >> >> On Tue, Mar 3, 2009 at 3:29 PM, Pınar Tözün <pin...@gm...> wrote: >> >>> >>> Hi, >>> >>> I am trying to implement the dynamic race detection algorithm >>> "Goldilocks" into Helgrind but I am having some difficulties with the >>> source code. The below c code is from the Valgrind Manual, >>> >>> #include <pthread.h> >>> >>> int var = 0; >>> >>> void* child_fn ( void* arg ) { >>> var++; /* Unprotected relative to parent */ /* this is line 6 */ >>> return NULL; >>> } >>> >>> int main ( void ) { >>> pthread_t child; >>> pthread_create(&child, NULL, child_fn, NULL); >>> var++; /* Unprotected relative to child */ /* this is line 13 */ >>> pthread_join(child, NULL); >>> return 0; >>> } >>> >>> My question is; how can I understand when hg_handle_client_request is >>> called and entered one of the LOCK cases, that it is not for the >>> Helgrind's own locking procedures but it is for one of the locks in >>> the checked c code. Because for the above example c code, although >>> there is no locking for the variable 'var' it calls a lot of >>> hg_handle_client_request with one of the LOCK cases in the switch >>> statement. >>> >> >> Not sure I understood your problem. >> Do you see LOCK/UNLOCK events when executing the program above? >> There is probably some locking inside pthread_create... >> >> --kcc >> >> >>> >>> Thank you! >>> pinar >>> >>> >>> ------------------------------------------------------------------------------ >>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, >>> CA >>> -OSBC tackles the biggest issue in open source: Open Sourcing the >>> Enterprise >>> -Strategies to boost innovation and cut costs with open source >>> participation >>> -Receive a $600 discount off the registration fee with the source code: >>> SFAD >>> http://p.sf.net/sfu/XcvMzF8H >>> _______________________________________________ >>> Valgrind-developers mailing list >>> Val...@li... >>> https://lists.sourceforge.net/lists/listinfo/valgrind-developers >>> >>> >> >> > > |
|
From: Bart V. A. <bar...@gm...> - 2009-03-05 13:02:34
|
On Tue, Mar 3, 2009 at 1:29 PM, Pınar Tözün <pin...@gm...> wrote: > My question is; how can I understand when hg_handle_client_request is > called and entered one of the LOCK cases, that it is not for the > Helgrind's own locking procedures but it is for one of the locks in > the checked c code. Because for the above example c code, although > there is no locking for the variable 'var' it calls a lot of > hg_handle_client_request with one of the LOCK cases in the switch > statement. What can help a lot in order to understand which code triggers the call to hg_handle_client_request() is to insert the following code in that function: VG_(message)(Vg_DebugMsg, "client stack from inside hg_handle_client_request:"); VG_(pp_StackTrace) (VG_(get_running_tid)(), VG_(clo_backtrace_size)); You can find more information about the VG_(message)() and the VG_(pp_StackTrace)() functions in the header files include/pub_tool_libcprint.h and include/pub_tool_stacktrace.h. Bart. |
|
From: Bart V. A. <bar...@gm...> - 2009-03-05 09:42:06
|
Nightly build on georgia-tech-cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) started at 2009-03-05 02:59:44 EST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 405 tests, 37 stderr failures, 9 stdout failures, 0 post failures == exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/wrap8 (stderr) none/tests/linux/mremap (stderr) none/tests/linux/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/round (stdout) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) |
|
From: Tom H. <th...@cy...> - 2009-03-05 03:48:29
|
Nightly build on vauxhall ( x86_64, Fedora 10 ) started at 2009-03-05 03:20:09 GMT
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 485 tests, 0 stderr failures, 1 stdout failure, 0 post failures ==
none/tests/pth_cvsimple (stdout)
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... done
Regression test results follow
== 485 tests, 0 stderr failures, 0 stdout failures, 0 post failures ==
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Thu Mar 5 03:34:19 2009
--- new.short Thu Mar 5 03:48:23 2009
***************
*** 4,6 ****
Building valgrind ... done
! Running regression tests ... done
--- 4,6 ----
Building valgrind ... done
! Running regression tests ... failed
***************
*** 8,10 ****
! == 485 tests, 0 stderr failures, 0 stdout failures, 0 post failures ==
--- 8,11 ----
! == 485 tests, 0 stderr failures, 1 stdout failure, 0 post failures ==
! none/tests/pth_cvsimple (stdout)
|
|
From: Tom H. <th...@cy...> - 2009-03-05 03:45:00
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2009-03-05 03:05:05 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 476 tests, 5 stderr failures, 0 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) helgrind/tests/tc20_verifywrap (stderr) |
|
From: Tom H. <th...@cy...> - 2009-03-05 03:32:16
|
Nightly build on mg ( x86_64, Fedora 9 ) started at 2009-03-05 03:10:06 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 482 tests, 4 stderr failures, 2 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) memcheck/tests/linux/timerfd-syscall (stdout) none/tests/linux/mremap2 (stdout) |