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
|
2
(13) |
3
(29) |
|
4
(18) |
5
(12) |
6
(12) |
7
(22) |
8
(9) |
9
(14) |
10
(6) |
|
11
|
12
|
13
(1) |
14
(5) |
15
(11) |
16
(7) |
17
(5) |
|
18
(1) |
19
(8) |
20
(7) |
21
(12) |
22
(5) |
23
(17) |
24
(6) |
|
25
(27) |
26
(17) |
27
(2) |
28
(10) |
29
(3) |
30
(8) |
31
(20) |
|
From: Doug R. <df...@nl...> - 2004-01-15 20:16:47
|
On Thu, 2004-01-15 at 19:49, Jeremy Fitzhardinge wrote: > On Thu, 2004-01-15 at 10:37, Doug Rabson wrote: > > I put something together today (attached). I also had to tweak > > vg_mylibc.c somewhat since my pthreads library wanted to override > > sigprocmask, sigaction etc. I've attached the result for your amusement. > > Have you tested it much? Hm. The more I look at it, the more potential > problems I see. We're using a couple of signals for internal use, which > are the same ones as the Linux libpthread uses for itself (deliberately; > I wanted to keep things looking the same to the clients). We need to be > sure to pay attention to that (NPTL's sigaction prevents setting > handlers for those signals anyway, but of course we're going direct to > the kernel). I tested it on my FreeBSD build and it works ok for most of the tests which worked before (some of the tests fail for me anyway because of glibc-dependant stack traces etc.). The signal-dependant tests like signal2, sigaltstack seem to work. Yes, I'm aware of the internal signal thing and I left that alone apart from using pthread_kill to direct them to the proxy thread. It seems to me that VKI_SIGVGKILL might not be needed since pthread_cancel should be roughly equivalent. > > So I guess the prerequisite for this is that we use libc for signal > management, if nothing else. Is that what you did to vg_mylibc? Yes. Of the two pthread implementations I tested, one overrides all the signal calls to help it implement its many user threads to few kernel threads policy. > > > I left the pipes alone in the interests of simplicity. > > Good idea. There's a few things which depend on the pipes, so they'll > need some thinking about. > > > > Hm. There's still one hole in allowing unfettered use of system > > > libraries - we need to make sure that any FDs opened are pushed into > > > Valgrind's range. > > > > I didn't think of that. I don't think that any of the FreeBSD pthreads > > implementations has any internal file descriptors. I'm not sure about > > NPTL/linuxthreads. > > I don't think NPTL does, but LinuxThreads might because it has that > manager thread thing. Maybe it does it all with signals. If it does > use file descriptors, I presume it must do something to get them out of > the way of the app's FDs. The FD allocation algorithm (first available) > is part of the Unix API, and some programs depend on it, and would get > upset to find unexpected FDs lying around. > > But my real concern was other libraries which open files, etc. stdio, > for example. > > One possibility is to fully virtualize the client's FDs with a mapping > table. That means we need to be able to intercept all ways in which the > client and the kernel can refer to FDs to each other. For plain old > read/write/open/close that's pretty simple, but mucking about with > poll/select sets is a bit hairy and I'm a bit concerned about things > like ioctls which can generate new FDs by unconventional means. That would work pretty well in most cases. I don't think there can be many weird ways for ioctls to generate new FDs. We need to handle them all for proper fd leak checking anyway. > > > I think that it probably never happens in practice. Just implementing an > > ia64 jit at all will be enough work without worrying about ia32 > > switching. > > The impression I get is that the hardware ia32 emulation is so slow that > hardly anyone uses it; Intel have a software dynamic-compilation ia32 > emulator which is a lot faster (within spitting distance of a similarly > clocked Xeon). I was just reading about that yesterday on The Register. I've used the hardware ia32 emulation on Itanium 1 early hardware and it sucks big time. Software is likely to be lots faster. |
|
From: Robert S. <rsc...@un...> - 2004-01-15 20:16:41
|
On Thu, Jan 15, 2004 at 11:49:31AM -0800, Jeremy Fitzhardinge wrote: > I don't think NPTL does, but LinuxThreads might because it has that > manager thread thing. Maybe it does it all with signals. If it does > use file descriptors, I presume it must do something to get them out of Yes, LinuxThreads _does_ use file descriptors for this purpose. Robert --=20 Robert Schiele Tel.: +49-621-181-2517 Dipl.-Wirtsch.informatiker mailto:rsc...@un... |
|
From: Jeremy F. <je...@go...> - 2004-01-15 19:49:36
|
On Thu, 2004-01-15 at 10:37, Doug Rabson wrote: > I put something together today (attached). I also had to tweak > vg_mylibc.c somewhat since my pthreads library wanted to override > sigprocmask, sigaction etc. I've attached the result for your amusement. Have you tested it much? Hm. The more I look at it, the more potential problems I see. We're using a couple of signals for internal use, which are the same ones as the Linux libpthread uses for itself (deliberately; I wanted to keep things looking the same to the clients). We need to be sure to pay attention to that (NPTL's sigaction prevents setting handlers for those signals anyway, but of course we're going direct to the kernel). So I guess the prerequisite for this is that we use libc for signal management, if nothing else. Is that what you did to vg_mylibc? > I left the pipes alone in the interests of simplicity. Good idea. There's a few things which depend on the pipes, so they'll need some thinking about. > > Hm. There's still one hole in allowing unfettered use of system > > libraries - we need to make sure that any FDs opened are pushed into > > Valgrind's range. > > I didn't think of that. I don't think that any of the FreeBSD pthreads > implementations has any internal file descriptors. I'm not sure about > NPTL/linuxthreads. I don't think NPTL does, but LinuxThreads might because it has that manager thread thing. Maybe it does it all with signals. If it does use file descriptors, I presume it must do something to get them out of the way of the app's FDs. The FD allocation algorithm (first available) is part of the Unix API, and some programs depend on it, and would get upset to find unexpected FDs lying around. But my real concern was other libraries which open files, etc. stdio, for example. One possibility is to fully virtualize the client's FDs with a mapping table. That means we need to be able to intercept all ways in which the client and the kernel can refer to FDs to each other. For plain old read/write/open/close that's pretty simple, but mucking about with poll/select sets is a bit hairy and I'm a bit concerned about things like ioctls which can generate new FDs by unconventional means. > I think that it probably never happens in practice. Just implementing an > ia64 jit at all will be enough work without worrying about ia32 > switching. The impression I get is that the hardware ia32 emulation is so slow that hardly anyone uses it; Intel have a software dynamic-compilation ia32 emulator which is a lot faster (within spitting distance of a similarly clocked Xeon). J |
|
From: Julian S. <js...@ac...> - 2004-01-15 18:40:33
|
On Thursday 15 January 2004 08:57, Robert Walsh wrote:
> > However, the same sort of malloc() followed by a free() was
> > done a number of times earlier. If vg holds on to freed
> > memory then there may be a problem. The machine is 1GB memory
> > and 2GB swap and abour 450MB of swap was used at the time
> > of failure.
>
> Valgrind does hold on to memory for a certain length of time after it's
> been freed. This is to catch things like this:
>
> x = malloc(10);
> free(x);
> y = malloc(10);
> *x = 0;
>
> If the second malloc happed to return the same value as the first, the
> invalid write to *x would never be caught.
>
> However, it doesn't keep these forever, and I had assumed it would use
> that pool when it ran out of memory. Hmm. Too tired to look at the
> code now, but it's in there somewhere. Search for freed_list.
Command-line parameter:
--freelist-vol=<number> volume of freed blocks queue [1000000]
Eyal, try with ...=0
J
|
|
From: Doug R. <df...@nl...> - 2004-01-15 18:37:36
|
On Thu, 2004-01-15 at 18:08, Jeremy Fitzhardinge wrote: > On Thu, 2004-01-15 at 02:27, Doug Rabson wrote: > > The other thing I've been thinking about recently is that now we can use > > library routines fairly safely, why not re-implement vg_proxylwp using > > pthreads? That would make the only non-portable part the actual syscall > > delivery. I might actually try that. > > Yes, that's on my list of things to do. I'm a bit worried by a few > things; since the proxylwp does direct syscalls (invokes int 0x80 > directly), the threads implementation has to be able to cope with that > (which probably means 1:1 app thread:kernel thread ratio). The direct > syscalls are still required so it can maintain the signal/restart state > machine properly. I put something together today (attached). I also had to tweak vg_mylibc.c somewhat since my pthreads library wanted to override sigprocmask, sigaction etc. I've attached the result for your amusement. > > On the plus size, it would allow me to drop the use of pipes as a thread > communication/synchronisation mechanism, and use pthreads operations > instead, which will be more efficient with any luck. I left the pipes alone in the interests of simplicity. > > Hm. There's still one hole in allowing unfettered use of system > libraries - we need to make sure that any FDs opened are pushed into > Valgrind's range. I didn't think of that. I don't think that any of the FreeBSD pthreads implementations has any internal file descriptors. I'm not sure about NPTL/linuxthreads. > > > I've been thinking about that too. One thing to bear in mind before you > > fix on a structure is the problem of amd64 and ia64. For amd64, the > > instruction set is almost identical with the main difference being a few > > extra prefixes and wider registers. A decompiler for amd64 should share > > almost all the i386 code. > > > > To a much lesser extent, the i386 decompiler would be useful on ia64 too > > since its possible to switch between ia64 and ia32 instruction sets at > > will. In practice, perhaps this doesn't happen though. > > I know ia64 has the ability to switch on a jump, but I was hoping that > in practice the change only really happened at execve time (like amd64's > transitions). If we were to support ia64 dynamic instruction set > switching, it would complicate things quite a bit, since we'd have to > have two complete implementations of the dynamic translator (not to > mention the cost of switching between the client's instruction set and > Valgrind's). I think that it probably never happens in practice. Just implementing an ia64 jit at all will be enough work without worrying about ia32 switching. |
|
From: Jeremy F. <je...@go...> - 2004-01-15 18:08:35
|
On Thu, 2004-01-15 at 02:27, Doug Rabson wrote: > The other thing I've been thinking about recently is that now we can use > library routines fairly safely, why not re-implement vg_proxylwp using > pthreads? That would make the only non-portable part the actual syscall > delivery. I might actually try that. Yes, that's on my list of things to do. I'm a bit worried by a few things; since the proxylwp does direct syscalls (invokes int 0x80 directly), the threads implementation has to be able to cope with that (which probably means 1:1 app thread:kernel thread ratio). The direct syscalls are still required so it can maintain the signal/restart state machine properly. On the plus size, it would allow me to drop the use of pipes as a thread communication/synchronisation mechanism, and use pthreads operations instead, which will be more efficient with any luck. Hm. There's still one hole in allowing unfettered use of system libraries - we need to make sure that any FDs opened are pushed into Valgrind's range. > I've been thinking about that too. One thing to bear in mind before you > fix on a structure is the problem of amd64 and ia64. For amd64, the > instruction set is almost identical with the main difference being a few > extra prefixes and wider registers. A decompiler for amd64 should share > almost all the i386 code. > > To a much lesser extent, the i386 decompiler would be useful on ia64 too > since its possible to switch between ia64 and ia32 instruction sets at > will. In practice, perhaps this doesn't happen though. I know ia64 has the ability to switch on a jump, but I was hoping that in practice the change only really happened at execve time (like amd64's transitions). If we were to support ia64 dynamic instruction set switching, it would complicate things quite a bit, since we'd have to have two complete implementations of the dynamic translator (not to mention the cost of switching between the client's instruction set and Valgrind's). J |
|
From: Doug R. <df...@nl...> - 2004-01-15 10:27:58
|
On Thu, 2004-01-15 at 00:45, Jeremy Fitzhardinge wrote: > Well, I'm still working (slowly) on the source tree rearrangement. I've > put the current patch up at > http://www.goop.org/~jeremy/valgrind/archdep.patch > This may build and work on i386-linux (it did a while ago), but I may > have just broken it. Either way, I'm posting it so people can get a > look at where I'm going with this. > > So far, I've factored out vg_syscalls.c and vg_proxylwp.c, as well as > *.S. vg_signals and vg_scheduler are next, and they should be simpler. > > I've been extracting parts of Doug's FreeBSD patch as required, but I > haven't even compile-tested it, let alone run it. It shouldn't be too > hard to rearrange the freebsd patch against my patch to get it working > (but I wouldn't bother putting lots of effort into it for now, since I'm > still changing things). I've read through the patch and it does look like a reasonably useful structure. Only one minor thing occurred to me while reading - you can use 'uname -m' to get a value for VG_PLAT_ARCH on FreeBSD. The other thing I've been thinking about recently is that now we can use library routines fairly safely, why not re-implement vg_proxylwp using pthreads? That would make the only non-portable part the actual syscall delivery. I might actually try that. In the meantime, I have been keeping my port up to date with valgrind cvs and implementing missing syscalls etc. I've also got the thing to work on FreeBSD 4.x which was a bit tricky since /proc doesn't include map filename information on 4.x. I ended up tweaking ume.c to preserve the filenames for the executable and interpreter and using dladdr() to look up the filename for valgrind's portion of the address space. If you are interested, you can look at the current state of my hackery using subversion: $ svn co svn://mailgate.nlsystems.com/repos/valgrind/branches/dfr valgrind-dfr Don't worry too much about tracking things though - I'm quite happy to do the work of merging when you commit the reorg. Subversion is really quite good at merging. > > I'm also beginning to move the purely x86-specific parts into the proper > place - vg_(to|from)_ucode are the obvious candidates here, as are bits > of vg_main. But since Julian is contemplating new innards to deal with > other CPU architectures, I don't think I'll go to heroic lengths until > we have a better idea of the future of UCode. I've been thinking about that too. One thing to bear in mind before you fix on a structure is the problem of amd64 and ia64. For amd64, the instruction set is almost identical with the main difference being a few extra prefixes and wider registers. A decompiler for amd64 should share almost all the i386 code. To a much lesser extent, the i386 decompiler would be useful on ia64 too since its possible to switch between ia64 and ia32 instruction sets at will. In practice, perhaps this doesn't happen though. |
|
From: Robert W. <rj...@du...> - 2004-01-15 08:57:15
|
> However, the same sort of malloc() followed by a free() was > done a number of times earlier. If vg holds on to freed > memory then there may be a problem. The machine is 1GB memory > and 2GB swap and abour 450MB of swap was used at the time > of failure. Valgrind does hold on to memory for a certain length of time after it's been freed. This is to catch things like this: x =3D malloc(10); free(x); y =3D malloc(10); *x =3D 0; If the second malloc happed to return the same value as the first, the invalid write to *x would never be caught. However, it doesn't keep these forever, and I had assumed it would use that pool when it ran out of memory. Hmm. Too tired to look at the code now, but it's in there somewhere. Search for freed_list. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Eyal L. <ey...@ey...> - 2004-01-15 08:49:45
|
Robert Walsh wrote: > > On Wed, 2004-01-14 at 00:23, Eyal Lebedinsky wrote: > > Testing a busy server, with many threads, I ended up with > > this a long report (attached) that starts with: > > > > valgrind: vg_malloc2.c:1008 (vgPlain_arena_malloc): Assertion `new_sb != > > ((void *)0)' failed. > > > > It seem to only happen when I use UDB database. > > > > This off current cvs. > > Is it possible you're running out of memory or address space? Remember, > Valgrind takes up wads more memory than running the problem without > Valgrind... OK, I had a close look and I do not think a memory shortage is involved. At the point of failure a malloc(exactly 64MB) was done. It never returned. However, the same sort of malloc() followed by a free() was done a number of times earlier. If vg holds on to freed memory then there may be a problem. The machine is 1GB memory and 2GB swap and abour 450MB of swap was used at the time of failure. I am running with: --tool=memcheck --leak-check=yes --show-reachable=no --num-callers=32 --error-limit=no --run-libc-freeres=no --quiet --trace-children=no -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Jeremy F. <je...@go...> - 2004-01-15 00:47:34
|
Well, I'm still working (slowly) on the source tree rearrangement. I've put the current patch up at http://www.goop.org/~jeremy/valgrind/archdep.patch This may build and work on i386-linux (it did a while ago), but I may have just broken it. Either way, I'm posting it so people can get a look at where I'm going with this. So far, I've factored out vg_syscalls.c and vg_proxylwp.c, as well as *.S. vg_signals and vg_scheduler are next, and they should be simpler. I've been extracting parts of Doug's FreeBSD patch as required, but I haven't even compile-tested it, let alone run it. It shouldn't be too hard to rearrange the freebsd patch against my patch to get it working (but I wouldn't bother putting lots of effort into it for now, since I'm still changing things). I'm also beginning to move the purely x86-specific parts into the proper place - vg_(to|from)_ucode are the obvious candidates here, as are bits of vg_main. But since Julian is contemplating new innards to deal with other CPU architectures, I don't think I'll go to heroic lengths until we have a better idea of the future of UCode. J |
|
From: Julian S. <js...@ac...> - 2004-01-15 00:24:07
|
Hi Frederik, list,
It's a nice-looking patch. It would be even nicer if it had the
relavent documentation updates too :-) {hint}
One question I have is, how useful is the ability to track circular
references during leak checking? Is it something that people widely
want?
J
> > Can you please open a report on
> >
> > http://valgrind.kde.org/bugs.html
> >
> > and attach your patch so that it is not forgotten? Thanks in advance.
>
> Ah, sure. I hadn't seen the bugzilla.
|