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
(9) |
2
(16) |
|
3
(9) |
4
(8) |
5
(9) |
6
(10) |
7
(14) |
8
(10) |
9
(7) |
|
10
(14) |
11
(19) |
12
(22) |
13
(18) |
14
(20) |
15
(10) |
16
(12) |
|
17
(13) |
18
(7) |
19
(12) |
20
(13) |
21
(9) |
22
(12) |
23
(6) |
|
24
(5) |
25
(5) |
26
(6) |
27
(7) |
28
(9) |
29
(13) |
30
(21) |
|
From: Nicholas N. <nj...@cs...> - 2006-09-14 23:28:40
|
On Thu, 14 Sep 2006, Julian Seward wrote: >> I don't think there were any problems with Cachegrind, were there? > > Well, the message is a bit misleading, but at least concise. > In fact there were no problems with either cachegrind, callgrind, or any > other tool. The problem was that the core's handling of sys_mremap (a > horrible syscall) was wrong (my mistake). Ah, ok. Nick |
|
From: Julian S. <js...@ac...> - 2006-09-14 22:54:39
|
On Thursday 14 September 2006 23:36, Nicholas Nethercote wrote: > On Thu, 14 Sep 2006 sv...@va... wrote: > > +3.2.1 adds x86/amd64 support for all SSE3 instructions except monitor > > +and mwait, further reduces memcheck's false error rate on all > > +platforms, adds support for recent binutils (in OpenSUSE 10.2 and > > +Fedora Rawhide) and fixes a bunch of bugs in 3.2.0. Some of the fixed > > +bugs were causing large programs to segfault with --tool=callgrind and > > +--tool=cachegrind, so an upgrade is recommended. > > I don't think there were any problems with Cachegrind, were there? Well, the message is a bit misleading, but at least concise. In fact there were no problems with either cachegrind, callgrind, or any other tool. The problem was that the core's handling of sys_mremap (a horrible syscall) was wrong (my mistake). Turns out that glibc's realloc is the only real user of sys_mremap; hence memcheck and massif were unaffected, because they provide their own realloc implementation and hence don't use sys_remap; but all the other tools were susceptible to the problem. Please do feel free to rephrase it if you want. http://bugs.kde.org/show_bug.cgi?id=129866 if you want the gory details. It took a long time to track this down, and the reporter did a great job of reducing his huge Ada app to a tractable test case. Later I found out that some other folks running a multi-million LOC app on callgrind were also experiencing segfaults which were fixed by this bugfix. So it struck more than once. J |
|
From: Nicholas N. <nj...@cs...> - 2006-09-14 22:37:05
|
On Thu, 14 Sep 2006 sv...@va... wrote: > +3.2.1 adds x86/amd64 support for all SSE3 instructions except monitor > +and mwait, further reduces memcheck's false error rate on all > +platforms, adds support for recent binutils (in OpenSUSE 10.2 and > +Fedora Rawhide) and fixes a bunch of bugs in 3.2.0. Some of the fixed > +bugs were causing large programs to segfault with --tool=callgrind and > +--tool=cachegrind, so an upgrade is recommended. I don't think there were any problems with Cachegrind, were there? NIck |
|
From: <sv...@va...> - 2006-09-14 20:17:10
|
Author: sewardj
Date: 2006-09-14 21:17:09 +0100 (Thu, 14 Sep 2006)
New Revision: 6069
Log:
Update
Modified:
branches/VALGRIND_3_2_BRANCH/NEWS
Modified: branches/VALGRIND_3_2_BRANCH/NEWS
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/VALGRIND_3_2_BRANCH/NEWS 2006-09-14 20:14:10 UTC (rev 6068)
+++ branches/VALGRIND_3_2_BRANCH/NEWS 2006-09-14 20:17:09 UTC (rev 6069)
@@ -1,12 +1,12 @@
=20
Release 3.2.1 (XX Sept 2006)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-3.2.1 adds SSE3 support for x86 and amd64, further reduces memcheck's
-false error rate on all platforms, adds support for recent binutils
-(in OpenSUSE 10.2 and Fedora Rawhide) and fixes a bunch of bugs in
-3.2.0. Some of the fixed bugs were causing large programs to segfault
-with --tool=3Dcallgrind and --tool=3Dcachegrind, so an upgrade is
-recommended.
+3.2.1 adds x86/amd64 support for all SSE3 instructions except monitor
+and mwait, further reduces memcheck's false error rate on all
+platforms, adds support for recent binutils (in OpenSUSE 10.2 and
+Fedora Rawhide) and fixes a bunch of bugs in 3.2.0. Some of the fixed
+bugs were causing large programs to segfault with --tool=3Dcallgrind and
+--tool=3Dcachegrind, so an upgrade is recommended.
=20
In view of the fact that any 3.3.0 release is unlikely to happen until
well into 1Q07, we intend to keep the 3.2.X line alive for a while
@@ -57,6 +57,8 @@
--dump-instr=3Dyes
n-i-bz callgrind: fix failed assertion when toggling=20
instrumentation mode
+n-i-bz callgrind: fix annotate script fix warnings with
+ --collect-jumps=3Dyes
n-i-bz docs path hardwired (Dennis Lubert)
=20
The following bugs were not fixed, due primarily to lack of developer
|
|
From: <sv...@va...> - 2006-09-14 20:14:13
|
Author: sewardj
Date: 2006-09-14 21:14:10 +0100 (Thu, 14 Sep 2006)
New Revision: 6068
Log:
Merge (from stable) r6066 (Yet another X padding suppression)
Modified:
trunk/xfree-4.supp
Modified: trunk/xfree-4.supp
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/xfree-4.supp 2006-09-14 20:10:19 UTC (rev 6067)
+++ trunk/xfree-4.supp 2006-09-14 20:14:10 UTC (rev 6068)
@@ -214,5 +214,14 @@
obj:/usr/X11*/lib*/libXft.so*
}
=20
+{
+ More X padding stuff
+ Memcheck:Param
+ writev(vector[...])
+ fun:*writev*
+ obj:/usr/X11*/lib*/libX11.so*
+ obj:/usr/X11*/lib*/libX11.so*
+}
+
##----------------------------------------------------------------------=
##
=20
|
|
From: <sv...@va...> - 2006-09-14 20:10:22
|
Author: sewardj
Date: 2006-09-14 21:10:19 +0100 (Thu, 14 Sep 2006)
New Revision: 6067
Log:
Merge r6064 (callgrind_annotate: fix warnings with "--collect-jumps=3Dyes=
")
Modified:
branches/VALGRIND_3_2_BRANCH/callgrind/callgrind_annotate.in
Modified: branches/VALGRIND_3_2_BRANCH/callgrind/callgrind_annotate.in
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/VALGRIND_3_2_BRANCH/callgrind/callgrind_annotate.in 2006-09-=
14 20:07:46 UTC (rev 6066)
+++ branches/VALGRIND_3_2_BRANCH/callgrind/callgrind_annotate.in 2006-09-=
14 20:10:19 UTC (rev 6067)
@@ -634,6 +634,16 @@
} elsif (s/^(jump|jcnd)=3D//) {
#ignore jump information
=20
+ } elsif (s/^jfi=3D(.*)$//) {
+ # side effect needed: possibly add compression mapping=20
+ uncompressed_name("fl",$1);
+ # ignore jump information=09
+
+ } elsif (s/^jfn=3D(.*)$//) {
+ # side effect needed: possibly add compression mapping
+ uncompressed_name("fn",$1);
+ # ignore jump information
+
} elsif (s/^totals:\s+//) {
#ignore
=20
|
|
From: <sv...@va...> - 2006-09-14 20:07:54
|
Author: sewardj
Date: 2006-09-14 21:07:46 +0100 (Thu, 14 Sep 2006)
New Revision: 6066
Log:
Yet another X padding suppression.
Modified:
branches/VALGRIND_3_2_BRANCH/xfree-4.supp
Modified: branches/VALGRIND_3_2_BRANCH/xfree-4.supp
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/VALGRIND_3_2_BRANCH/xfree-4.supp 2006-09-14 15:35:14 UTC (re=
v 6065)
+++ branches/VALGRIND_3_2_BRANCH/xfree-4.supp 2006-09-14 20:07:46 UTC (re=
v 6066)
@@ -214,5 +214,14 @@
obj:/usr/X11*/lib*/libXft.so*
}
=20
+{
+ More X padding stuff
+ Memcheck:Param
+ writev(vector[...])
+ fun:*writev*
+ obj:/usr/X11*/lib*/libX11.so*
+ obj:/usr/X11*/lib*/libX11.so*
+}
+
##----------------------------------------------------------------------=
##
=20
|
|
From: Julian S. <js...@ac...> - 2006-09-14 16:04:08
|
> I currently are not really sure when I step on your shoes > with a commit. Trunk commits should be definitly OK currently, as there > is no release? Yes. > You talk about docs/internals/3_2_BUGSTATUS.txt in trunk, right? Yes. > So is it enough for you when I add an entry with "pending" to note > that this is a candidate for backporting from my side? Yes, that's fine. I see your r6065 just now - that's fine. Really, the main problem I am trying to avoid is forgetting about bugs that need to be fixed and/or be merged to the stable branch. Any kind of info in BUGSTATUS.txt is helpful; you can see I often leave notes for myself in there :-) > Then: r6064 is a candidate for backporting. It works for me and Christoph, > and it is that small that it is quite unprobably to introduce another bug. Cool, will do. Thanks for the recent bug fixes. One other thing - I notice you are not on the list of people who 'watch' bugs assigned to me in the kde bugzilla. This means you miss out on all the valgrind bugs-related email dialogue. This may be an advantage for you :-) - I just didn't know if you are aware of this or not. Maybe you should be a 'watcher' - most other V developers are. J |
|
From: Josef W. <Jos...@gm...> - 2006-09-14 15:36:49
|
On Thursday 14 September 2006 10:54, Julian Seward wrote: > > Hi Josef > > In the future, it would be useful for release management if you > could let me know when you make a commit which you want merged into > the stable branch. Also adding entries for callgrind-related bugs > you fix, into docs/internals/3_2_BUGSTATUS.txt would be helpful, > since that's how I keep track of the current global bug status. I currently are not really sure when I step on your shoes with a commit. Trunk commits should be definitly OK currently, as there is no release? You talk about docs/internals/3_2_BUGSTATUS.txt in trunk, right? So is it enough for you when I add an entry with "pending" to note that this is a candidate for backporting from my side? Then: r6064 is a candidate for backporting. It works for me and Christoph, and it is that small that it is quite unprobably to introduce another bug. Thanks, Josef |
|
From: <sv...@va...> - 2006-09-14 15:35:19
|
Author: weidendo
Date: 2006-09-14 16:35:14 +0100 (Thu, 14 Sep 2006)
New Revision: 6065
Log:
Update on bugstatus
Modified:
trunk/docs/internals/3_2_BUGSTATUS.txt
Modified: trunk/docs/internals/3_2_BUGSTATUS.txt
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/docs/internals/3_2_BUGSTATUS.txt 2006-09-13 22:57:38 UTC (rev 6=
064)
+++ trunk/docs/internals/3_2_BUGSTATUS.txt 2006-09-14 15:35:14 UTC (rev 6=
065)
@@ -84,6 +84,7 @@
produced with --dump-instr=3Dyes
v6045, v6057 n-i-bz callgrind: fix failed assertion when
v6053 toggling instrumentation mode
+v6064 pending n-i-bz callgrind_annotate: fix warnings with
+ "--collect-jumps=3Dyes"
=20
v6059 v6060 n-i-bz docs path hardwired (Dennis Lubert)
-
|
|
From: Tom H. <to...@co...> - 2006-09-14 11:59:56
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> Tom, I just sent this to the dbus list, and wondered if you had any
> comments. Essence of the question is: if sys_poll returns 0, are the
> .revent fields defined or not?
I agree that POSIX is not entirely clear, even the current version.
Looking at the kernel source, I believe they will always be filled
in even if a timeout occurs.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <js...@ac...> - 2006-09-14 11:57:44
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-09-14 09:00:01 BST 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 == 207 tests, 10 stderr failures, 6 stdout failures, 0 posttest failures == memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: Julian S. <js...@ac...> - 2006-09-14 11:39:50
|
Tom, I just sent this to the dbus list, and wondered if you had any
comments. Essence of the question is: if sys_poll returns 0, are the
.revent fields defined or not?
J
---------- Forwarded Message ----------
Subject: Possible poll-related problem in dbus-0.92
Date: Thursday 14 September 2006 12:08
From: Julian Seward <js...@ac...>
To: db...@li...
I've been running a bunch of KDE4 code through Valgrind, hence exercising
dbus-0.92 too. The following is with KDE4 from svn, dbus-0.92 unmodified,
running on x86-linux, and using the just-about-to-be released
valgrind-3.2.1. I am running the entire process tree for a KDE session
on valgrind.
Under obscure circumstances, V reports uninitialised value uses in
unix_do_iteration() in dbus-transport-unix.c, line 1053:
if (need_write && (flags & DBUS_ITERATION_DO_WRITING))
do_writing (transport);
Upon investigation, it seems to me that dbus is depending on a boundary
case of poll() which is poorly specified by POSIX. I am not saying that
dbus necessarily has a bug, nor that valgrind is being too strict; but
it does appear that dbus and valgrind disagree, and from reading the POSIX
specification for poll() it's not clear what should happen. See
http://www.opengroup.org/onlinepubs/007908799/xsh/poll.html for the POSIX
spec.
The problem case is when poll() (hence _dbus_poll) returns zero. At
dbus-transport-unix.c:1032 we have
if (poll_res >= 0)
{
/* poke around in the .revents field of the pollfd structure */
}
As currently set up, valgrind's handler for poll() does not mark the .revent
fields as defined in the case where poll returned zero (meaning no file
descriptors were ready). Is that a bug? I don't know. It could be argued
that dbus should not look at the .revents field in this case.
I suspect Valgrind is being too conservative here; but given that this is
a boundary case you could easily ignore - do nothing if poll_res == 0 - and
given that presumably portability is a goal, maybe you'd want to handle this
rather than rely on implementations setting .revents to zero in the case
where poll returns zero.
J
_______________________________________________
dbus mailing list
db...@li...
http://lists.freedesktop.org/mailman/listinfo/dbus
-------------------------------------------------------
|
|
From: Julian S. <js...@ac...> - 2006-09-14 09:06:23
|
Sounds plausible, and I like the idea of not messing with the state
machine. So you are saying, if you had a client request
VG_USERREQ__GET_MY_THREADID, that is all you would need?
How would you do the locking for this data structure? Would you
use pthread_mutex_{lock,unlock}? Does anything break if you call
those from inside the wrappers for pthread_{create,join} ?
J
On Wednesday 13 September 2006 20:53, Bart Van Assche wrote:
> A proposal for storing the (pthread_t, ThreadId) relationship in such a way
> that the scheduler's state machine doesn't have to be modified:
> - Add a client request such that a thread can query it's ThreadId from
> client space.
> - Implement a thread-safe data structure in the client that allows each
> thread to store its own ThreadId (thread-local storage can't be used for
> this purpose since each thread can only access it's own thread-local
> storage, and not that of another thread).
> - After each call to pthread_create(), store the (pthread_t, ThreadId) of
> the newly created thread in the just described data structure (e.g. at the
> beginning of vg_thread_wrapper()). Only allow pthread_create() to return
> after the (pthread_t, ThreadId) info has been stored, in order to avoid
> race conditions.
> - In the wrapper of pthread_join(), before the actual call of
> pthread_join(), obtain the ThreadId of the joined thread from that data
> structure. Next, call the actual pthread_join() function and do the
> post-thread-join client request. Next, remove the (pthread_t, ThreadId)
> info from the same data structure.
> - For detached threads, remove the (pthread_t, ThreadId) info at the time
> the thread is detached (this is either at thread creation time or at the
> time pthread_detach() is called).
>
> On 8/26/06, Bart Van Assche <bar...@gm...> wrote:
> > Hello Julian,
> >
> > Regarding thread state: I commented out tst->status = VgTs_Empty in
> > the assembly code cited below because I moved it to another point
> > (m_scheduler.c, case VG_USERREQ__POST_PTHREAD_JOIN). The background of
> > this change is as follows:
> > - After the client finished calling pthread_join(), drd needs to know
> > both the thread IDs of the thread that called pthread_join() and the the
> > ID of the joined thread. Once pthread_join() finishes, the client knows
> > the identity of both threads, but both IDs are of type pthread_t.
> > - drd uses ThreadId's internally. Hence, I needed a way to map pthread_t
> > into ThreadId. I had two options for storing the translation data between
> > these two types of thread IDs: either in the Valgrind core or in the
> > client.
> >
> > - When storing the translation information between pthread_t and ThreadId
> > in Valgrind, this translation information must still be accessible at the
> > time VG_USERREQ__POST_PTHREAD_JOIN is handled. This is why I postponed
> > cleanup of the per-thread data in Valgrind.
> > - Another option is to store the relationship between pthread_t and
> > ThreadId in the client. I can't solve this with thread-local storage
> > since this information is no longer accessible once pthread_join()
> > completes
> > (pthread_key_create()/pthread_key_delete()/pthread_setspecific()/pthread_
> >getspecific()).
> >
> >
> > Note: this change breaks clone() calls that do not originate from
> > pthread_create(). This can be solved by initializing the pthread_t value
> > kept for threads created by raw clone() calls to zero, and by executing
> > the statement "movl %1, %0\n" conditionally (only for threads created by
> > raw clone() calls). I did not yet implement this byself because I'm not
> > that fluent in assembly language.
|
|
From: Julian S. <js...@ac...> - 2006-09-14 08:54:30
|
Hi Josef
In the future, it would be useful for release management if you
could let me know when you make a commit which you want merged into
the stable branch. Also adding entries for callgrind-related bugs
you fix, into docs/internals/3_2_BUGSTATUS.txt would be helpful,
since that's how I keep track of the current global bug status.
Thanks,
J
On Wednesday 13 September 2006 23:57, sv...@va... wrote:
> Author: weidendo
> Date: 2006-09-13 23:57:38 +0100 (Wed, 13 Sep 2006)
> New Revision: 6064
>
> Log:
> callgrind_annotate: fix warnings with "--collect-jumps=yes"
>
> This callgrind option produces lines starting e.g. with
> "jfi" in the profile data files, which specifies a
> source file change between a jump source and jump target.
> This itself is meaningless for callgrind_annotate, as
> it can not show jump information in its annotation.
> However, such "jfi" lines can contain important mapping
> info for a (file ID, file name) tuple - which leads to
> further warnings and problems if ignored.
>
> Modified:
> trunk/callgrind/callgrind_annotate.in
>
>
> Modified: trunk/callgrind/callgrind_annotate.in
> ===================================================================
> --- trunk/callgrind/callgrind_annotate.in 2006-09-12 23:08:49 UTC (rev
> 6063) +++ trunk/callgrind/callgrind_annotate.in 2006-09-13 22:57:38 UTC
> (rev 6064) @@ -634,6 +634,16 @@
> } elsif (s/^(jump|jcnd)=//) {
> #ignore jump information
>
> + } elsif (s/^jfi=(.*)$//) {
> + # side effect needed: possibly add compression mapping
> + uncompressed_name("fl",$1);
> + # ignore jump information
> +
> + } elsif (s/^jfn=(.*)$//) {
> + # side effect needed: possibly add compression mapping
> + uncompressed_name("fn",$1);
> + # ignore jump information
> +
> } elsif (s/^totals:\s+//) {
> #ignore
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Tom H. <to...@co...> - 2006-09-14 02:46:26
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-09-14 03:30:05 BST 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 == 240 tests, 5 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-09-14 02:26:53
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-09-14 03:10:13 BST 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 == 268 tests, 4 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-09-14 02:24:59
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-09-14 03:15:02 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccRj4qar.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccRj4qar.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccRj4qar.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccRj4qar.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccRj4qar.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccRj4qar.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccRj4qar.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccRj4qar.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.8624/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.8624/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.8624/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.8624/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.8624/valgrind' make: *** [check] Error 2 ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccjnExiK.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccjnExiK.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccjnExiK.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccjnExiK.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccjnExiK.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccjnExiK.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccjnExiK.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccjnExiK.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.8624/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.8624/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.8624/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.8624/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.8624/valgrind' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Thu Sep 14 03:19:39 2006 --- new.short Thu Sep 14 03:24:53 2006 *************** *** 7,16 **** Last 20 lines of verbose log follow echo ! /tmp/ccjnExiK.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccjnExiK.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccjnExiK.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccjnExiK.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccjnExiK.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccjnExiK.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccjnExiK.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccjnExiK.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 --- 7,16 ---- Last 20 lines of verbose log follow echo ! /tmp/ccRj4qar.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccRj4qar.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccRj4qar.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccRj4qar.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccRj4qar.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccRj4qar.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccRj4qar.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccRj4qar.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 |
|
From: Tom H. <th...@cy...> - 2006-09-14 02:20:20
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2006-09-14 03:05:07 BST 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 == 268 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/leakotron (stdout) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-09-14 02:17:15
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-09-14 03:00:03 BST 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 == 270 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |