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
(1) |
2
(8) |
3
(7) |
4
(16) |
5
|
|
6
(3) |
7
(4) |
8
(1) |
9
(1) |
10
(4) |
11
(5) |
12
(1) |
|
13
|
14
(4) |
15
(2) |
16
|
17
(2) |
18
(9) |
19
(5) |
|
20
(9) |
21
(7) |
22
(9) |
23
(5) |
24
|
25
(1) |
26
|
|
27
|
28
(1) |
29
(11) |
30
(6) |
31
|
|
|
|
From: Jeremy F. <je...@go...> - 2002-10-20 22:50:05
|
On Sun, 2002-10-20 at 15:21, Julian Seward wrote: > Jeremy, I see 17-hg-generic-mutex. I presume this is infrastructure for > the thread-segments stuff, or something like that. I've got a number of plans for this: - keep a graph of mutex dependencies so that incorrect locking order can be detected - keep track of mutex lifetimes to handle mutexes in allocated memory which gets freed - support non-pthreads threading using client requests to indicate lock/unlock/context switch - record execution context when a mutex state changes, so it can be reported - and some other stuff (lots use uses for maintaining per-mutex information) I think the thread segments stuff only needs a redefinition of tid (which fits in well with the non-pthreads changes as well). J |
|
From: Julian S. <js...@ac...> - 2002-10-20 22:15:38
|
On Sunday 20 October 2002 10:40 pm, Jeremy Fitzhardinge wrote: > On Sun, 2002-10-20 at 13:54, Jeremy Fitzhardinge wrote: > On Sun, 2002-10-20 at 13:15, Julian Seward wrote: > I think Nick has already merged 08-skin-clientreq. > > Excellent. I'll merge and regenerate my patchset. > > OK, I've updated http://www.goop.org/~jeremy/valgrind - it doesn't look > like 08-skin-clientreq has been merged yet. Hmm. You're right; my memory is wrong. Nick, do you see any potential problems if I merge in 08-skin-clientreq? [just a sanity check before I do so ...] Jeremy, I see 17-hg-generic-mutex. I presume this is infrastructure for the thread-segments stuff, or something like that. J |
|
From: Jeremy F. <je...@go...> - 2002-10-20 21:40:09
|
On Sun, 2002-10-20 at 13:54, Jeremy Fitzhardinge wrote:
On Sun, 2002-10-20 at 13:15, Julian Seward wrote:
I think Nick has already merged 08-skin-clientreq.
Excellent. I'll merge and regenerate my patchset.
OK, I've updated http://www.goop.org/~jeremy/valgrind - it doesn't look
like 08-skin-clientreq has been merged yet.
J
|
|
From: Jeremy F. <je...@go...> - 2002-10-20 20:54:06
|
On Sun, 2002-10-20 at 13:15, Julian Seward wrote:
Hi. Thx for the helgrind fixes. I merged the following patches into
the head this afternoon:
03-poll-select (is also in 1.0.4)
04-lax-ioctls (is also in 1.0.4)
07-seginfo
13-data-syms
14-hg-tid
06-memops
15-hg-datasym
16-ld-nodelete
I think Nick has already merged 08-skin-clientreq.
Excellent. I'll merge and regenerate my patchset.
I just tried a run of mozilla-1.0.1 on the fully patched helgrind.
There are bazillions of errors reported for the _dl_num_relocations
problem which we already know about (even with LD_BIND_NOW=y). If
those were to be got rid of somehow, the remaining ones are sufficiently
few that they might actually tell us something useful.
Yes, LD_BIND_NOW will only work for simple dynamically linked programs
which do all their linking at startup (ie, while single threaded).
Presumably Mozilla is still dynamically linking things well into its
life, with multiple threads.
Which is a step in the right direction.
Any ideas how to get rid of this blasted _dl_num_relocations thing?
Perhaps helgrind can check to see if the variable in question is
indeed _dl_num_relocations, and suppress the error if so?
Well, obviously Helgrind needs to be taught how to understand
suppressions, and we need to start building a standard suppression
file. I also think the handling of duplicate errors needs to be a bit
different from Memcheck and so on. Memcheck considers the error context
to be the same if there's matching portions of the stack backtrace. I
think for helgrind, the memory location itself is all that's
interesting: it doesn't matter what the call frames are (for the
purposes of suppression; obviously you need them for reporting).
Also, the increment of _dl_num_locations is probably an atomic inc
anyway (probably a simple addl $1, _dl_num_locations), so it doesn't
really count as an error at all. I'm not planning on teaching helgrind
about atomic operations just yet, but it is an obvious path for future
work.
Another interesting test is tests/unused/pth_threadpool; this gives
a large number of errors, many of which pertain to _IO_2_1_stdout_.
Yes, I noticed there were a number of reports coming out of stdio, but I
haven't looked into it yet. Quite possibly they're atomic ops as well.
Or just bugs.
J
|
|
From: Jeremy F. <je...@go...> - 2002-10-20 20:53:44
|
On Sun, 2002-10-20 at 13:33, Julian Seward wrote:
How about just link in our libpthread.so under all circumstances? Surely
the magic hacks it does for some functions (select, poll, etc) are harmless
for single-threaded programs, just a little inefficient? Is there any
advantage to the added complication of switching behaviours depending on
whether or not a second thread has been created? All else being equal
I prefer to avoid complexity like that.
It leaks the pthread names into programs which didn't ask for
libpthread. But that's pretty likely anyway, given the number of
libraries which pull in libpthread for you.
Also, some of libpthread's substitutions may not be functionally
identical to the real functions, so it would be nice to avoid
introducing that complexity unless it is necessary (I don't think that's
the case at the moment, but it is true for the non-blocking open, which
is impossible to emulate exactly).
So I don't have a strong objection to always bringing in libpthread, but
I do think we should just use the standard libc implementations unless
we actually need the threaded versions.
J
|
|
From: Julian S. <js...@ac...> - 2002-10-20 20:27:26
|
> Not entirely sure what the outcome of this is -- can you summarise? I > get the impression that it _should_ be OK -- libpthread.so should override > libc -- but perhaps I'm wrong? > > Yes, but... The case where a program binds to some symbols, then > (implicitly) loads libpthread and becomes multithreaded is difficult, > because any previously bound references will remain bound. glibc w/ > pthreads has this problem as well (libpthread wants to intercept fork(), > but may not get to it in time). > > I think the safe and sure way of making this always work is to make > valgrind.so define all the symbols we want to intercept, and then have > it dispatch them out to our libpthread or into the real libc, depending > on whether a second thread has been created. I think this is certain to > catch all the references we want to catch under all circumstances. How about just link in our libpthread.so under all circumstances? Surely the magic hacks it does for some functions (select, poll, etc) are harmless for single-threaded programs, just a little inefficient? Is there any advantage to the added complication of switching behaviours depending on whether or not a second thread has been created? All else being equal I prefer to avoid complexity like that. > A couple of other points. > > 1. Your __select and __poll renamings suffer from the same problem. > > As do all the libc intercepts in libpthread.so (select and __select are > strong aliases and are therefore indistinguishable Blargh. J |
|
From: Julian S. <js...@ac...> - 2002-10-20 20:09:20
|
Hi. Thx for the helgrind fixes. I merged the following patches into the head this afternoon: 03-poll-select (is also in 1.0.4) 04-lax-ioctls (is also in 1.0.4) 07-seginfo 13-data-syms 14-hg-tid 06-memops 15-hg-datasym 16-ld-nodelete I think Nick has already merged 08-skin-clientreq. I just tried a run of mozilla-1.0.1 on the fully patched helgrind. There are bazillions of errors reported for the _dl_num_relocations problem which we already know about (even with LD_BIND_NOW=y). If those were to be got rid of somehow, the remaining ones are sufficiently few that they might actually tell us something useful. Which is a step in the right direction. Any ideas how to get rid of this blasted _dl_num_relocations thing? Perhaps helgrind can check to see if the variable in question is indeed _dl_num_relocations, and suppress the error if so? Another interesting test is tests/unused/pth_threadpool; this gives a large number of errors, many of which pertain to _IO_2_1_stdout_. J |
|
From: Jeremy F. <je...@go...> - 2002-10-20 18:35:52
|
On Sun, 2002-10-20 at 04:00, Julian Seward wrote:
Jeremy
Not entirely sure what the outcome of this is -- can you summarise? I get
the impression that it _should_ be OK -- libpthread.so should override libc
-- but perhaps I'm wrong?
Yes, but... The case where a program binds to some symbols, then
(implicitly) loads libpthread and becomes multithreaded is difficult,
because any previously bound references will remain bound. glibc w/
pthreads has this problem as well (libpthread wants to intercept fork(),
but may not get to it in time).
I think the safe and sure way of making this always work is to make
valgrind.so define all the symbols we want to intercept, and then have
it dispatch them out to our libpthread or into the real libc, depending
on whether a second thread has been created. I think this is certain to
catch all the references we want to catch under all circumstances.
A couple of other points.
1. Your __select and __poll renamings suffer from the same problem.
As do all the libc intercepts in libpthread.so (select and __select are
strong aliases and are therefore indistinguishable
2. I didn't mention this before, but ... you might want to play with the
coregrind/dosyms script. This compares the exported symbols from
V's libpthread.so vs those from the standard one; and it is how I
navigate this swamp -- to a first approximation I try and make
V's libpthread.so export the same syms as the standard one.
OK. It looks to me like the version script mechanism can also be used
to make sure there's no symbol namespace leakage (ie, it can enforce the
rule that only vgPlain_* symbols are visible outside the .so).
J
|
|
From: Julian S. <js...@ac...> - 2002-10-20 10:54:12
|
Jeremy
Not entirely sure what the outcome of this is -- can you summarise? I get
the impression that it _should_ be OK -- libpthread.so should override libc
-- but perhaps I'm wrong?
A couple of other points.
1. Your __select and __poll renamings suffer from the same problem.
2. I didn't mention this before, but ... you might want to play with the
coregrind/dosyms script. This compares the exported symbols from
V's libpthread.so vs those from the standard one; and it is how I
navigate this swamp -- to a first approximation I try and make
V's libpthread.so export the same syms as the standard one.
J
On Saturday 19 October 2002 2:50 am, Jeremy Fitzhardinge wrote:
> On Fri, 2002-10-18 at 17:52, H. J. Lu wrote:
> > > OK, but valgrind.so is already being linked with "-z initfirst"; what
> > > happens if there are two .so files with initfirst? (It does seem to
> > > work).
> >
> > Which ever comes first wins
>
> So if the order of events is:
>
> 1. run executable A, with LD_PRELOAD=valgrind.so (which has initfirst
> set)
> 2. A uses function foo() which is defined in libc.so
> 3. A doesn't use libpthread, but after a while it dlopens libB.so, which
> does
> 4. libB.so pulls in Valgrind's libpthread.so.
> 5. Valgrind's libpthread.so wants to override foo(), now that this has
> become a multithreaded program. If A uses foo() again, which definition
> will it get? libc's original one (which it was using before), or the
> new definition in libpthread.so?
>
> I wonder if the solution is to always pull in Valgrind's libpthread.so,
> but only make it do special stuff once there's more than one thread...
>
> Thanks,
> J
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> Access Your PC Securely with GoToMyPC. Try Free Now
> https://www.gotomypc.com/s/OSND/DD
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|