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
(11) |
2
(13) |
3
(7) |
|
4
(9) |
5
(23) |
6
(19) |
7
(18) |
8
(2) |
9
(7) |
10
(21) |
|
11
(13) |
12
|
13
(8) |
14
(17) |
15
(19) |
16
(25) |
17
(43) |
|
18
(22) |
19
(12) |
20
(19) |
21
(12) |
22
(9) |
23
(12) |
24
(5) |
|
25
(16) |
26
(25) |
27
(24) |
28
(19) |
29
(26) |
30
(25) |
31
(6) |
|
From: Nicholas N. <nj...@ca...> - 2004-07-05 20:27:31
|
On Mon, 5 Jul 2004, Josef Weidendorfer wrote: >> I've made these changes. The improvement are pretty big. I've include >> the change log below, check out the general improvements. They arose >> because I split one messy data structure, which was (I now realise) >> serving two distinct purposes, into two much cleaner data structures. > > I always thought that this mix up was because of getting better cache > behaviour (more spatial locality) of cachegrind ... which obviously is not > true? No! I just hadn't thought about it in the right way. :) > One problem is that Calltree has an option to dump out events by their > instruction address (actually object file offset), and KCachegrind > uses this for annotated dissassembler. I don't want to loose this feature, > especially as I think it is important for the user to be able to look at this > detail level if needed. > > But your separation is a very good thing. I'm sure this will give similar > simplifications. Instead of a CC per distinct source line, can't we use a CC > per (obj_file/instruction offset) which is mapped to a distinct source line? > I know that this makes things a little bit more complex, but still the CCs > don't have to be discarded on unmapping code segments. Yes, an object file location, rather than a source file location, could be suitable for Calltree for this purpose. But I want to stick with the source file location for Cachegrind. > Is a CC per distinct source line enough? E.g. all initialisation functions of > shared libraries, where you don't have source code, will be mapped into one, > as the functions are called the same (_init). Yes, but if you don't have source code then you can't do annotation and so the information collected for that library won't be used anyway. So it's good that it's been compacted so much and takes up very little space in the cachegrind.out file. >> - Removed "fi" and "fe" handling from cg_annotate, no longer needed due >> to neatening of the CC-table. > > What actually was the purpose here? Why wasn't "fn=" in all cases enough? I can't remember exactly... it was something to do with cross-module inlining, which meant that the instructions within a basic block could have different filenames, and so it had to switch back and forth between files. Or something like that. N |
|
From: Josef W. <Jos...@gm...> - 2004-07-05 19:08:32
|
Hi Nick, On Monday 05 July 2004 11:00, Nicholas Nethercote wrote: > I've made these changes. The improvement are pretty big. I've include > the change log below, check out the general improvements. They arose > because I split one messy data structure, which was (I now realise) > serving two distinct purposes, into two much cleaner data structures. I always thought that this mix up was because of getting better cache behaviour (more spatial locality) of cachegrind ... which obviously is not true? > I'm pretty keen to commit these changes soon, in time for 2.1.2. It would > be good to see them in Calltree too, but I'm not sure how easy that will > be. I will see what I can do. One problem is that Calltree has an option to dump out events by their instruction address (actually object file offset), and KCachegrind uses this for annotated dissassembler. I don't want to loose this feature, especially as I think it is important for the user to be able to look at this detail level if needed. But your separation is a very good thing. I'm sure this will give similar simplifications. Instead of a CC per distinct source line, can't we use a CC per (obj_file/instruction offset) which is mapped to a distinct source line? I know that this makes things a little bit more complex, but still the CCs don't have to be discarded on unmapping code segments. Is a CC per distinct source line enough? E.g. all initialisation functions of shared libraries, where you don't have source code, will be mapped into one, as the functions are called the same (_init). > - Previously, when code was unloaded all its hit/miss counts were stuck > in a single "discard" CC, and so that code would not be annotated. Now > this code is profiled and annotatable just like all other code. I actually do almost nothing at all when a code segment is discarded, and I know this is buggy and leaking, just to be able to dump data for discarded code segments. Your solution (the structure separation) is very good here. > - Source code size is 27% smaller. cg_main.c is now 1494 lines, down > from 2174. Some (1/3?) of this is from removing the special handling > of JIFZ and general compaction, but most is from the data structure > changes. Happily, a lot of the removed code was nasty. Then I will get rid of the JIFZ code, too. > - cachegrind.out.pid size is about 90+% smaller(!) Annotation time is > accordingly much faster. Doing cost-centres at the level of source > code lines rather than instructions makes a big difference, since > there's typically 2--3 instructions per source line. Even better, > when debug info is not present, entire functions (and even files) get > collapsed into a single "???" CC. (This behaviour is no different > to what happened before, it's just the collapsing used to occur in the > annotation script, rather than within Cachegrind.) This is a big win > for stripped libraries. I actually do some compression at dump time, but it is much uglier... > - Speed is not much changed -- the changes were not in the intensive > parts, so the only likely change is a cache improvement due to using > less memory. SPEC experiments go -3 -- 10% faster, with the "average" > being unchanged or perhaps a tiny bit faster. That's good to see. > - Removed "fi" and "fe" handling from cg_annotate, no longer needed due > to neatening of the CC-table. What actually was the purpose here? Why wasn't "fn=" in all cases enough? Josef |
|
From: Nicholas N. <nj...@ca...> - 2004-07-05 17:29:06
|
On Mon, 5 Jul 2004, Jeremy Fitzhardinge wrote: > I think for now, the best way squeeze everything into the address space > is: > * take advantage of the 4G/4G patches which some distros are > shipping with; that gives us an extra Gbyte of address space to Do you know how to detect this at configure-time? N |
|
From: Jeremy F. <je...@go...> - 2004-07-05 17:21:45
|
On Mon, 2004-07-05 at 09:44 +0100, Nicholas Nethercote wrote: > Can we pass the info from stage1 to stage2 without using the auxv? Could > it be done just with two global variables? stage1 is still in memory when > stage2 starts, so this shouldn't be too hard, right? Well, yes, but there's a problem of finding the rendezvous memory. I guess we could just pick a fixed constant address and put some info there. I used the AUXV because its the standard way of passing this kind of info between kernel and userspace at exec time, and I'm just piggybacking a bit. > If it's possible to do it this way, that would be better than doing it via > auxv and not being certain if it's going to work or going to clobber some > random memory location miles away. Well, glibc already uses AT_ entries bigger than 32 so it would be a generic bug if they're still doing that now. J |
|
From: Jeremy F. <je...@go...> - 2004-07-05 17:18:59
|
On Mon, 2004-07-05 at 10:11 +0100, Julian Seward wrote:
> This is something we discussed a few months ago. On the plus side
> it completely decouples the client and V's address space and so
> sidesteps what I see (perhaps incorrectly) as the somewhat fragile
> scheme we have at the moment. On the minus side there is some
> overhead, plus there is complication at syscall boundaries of
> doing the relevant address translation and scatter/gather
> operations (copy_to_user, copy_from_user in effect).
Unfortunately I think a VMMU would be even more fragile. It would mean
being able to reliably intercept every single memory address passing
over the user/kernel boundary. At present we make a best attempt, but
if we miss something its no big deal. With a VMMU we would have to be
100% accurate (this is the same reason I'm not keen on completely
virtualizing the file-descriptor space).
Aside from that, there are some much more common syscalls which would be
impossible to deal with in a VMMU scheme, like the SHM ones. They don't
allow a shared memory segment to be broken into separate pieces in the
user virtual address space, so you wouldn't be able to map them into the
Valgrind client's address space linearly. It may not even help with
this aio problem, if the shared aio memory has pointers in it.
The static address space partition is a pain, I agree. But I think its
pain we can deal with, given the advantages of protecting Valgrind from
the client, being able to enforce the client's address space
limitations, and being able to scale to a 64-bit address space easily.
After all, all this is just a limitation of the 32-bit address space; in
a 64-bit space we have plenty of space to fit everything in, and a
simple address space partition is the simplest way to go.
I think for now, the best way squeeze everything into the address space
is:
* take advantage of the 4G/4G patches which some distros are
shipping with; that gives us an extra Gbyte of address space to
play with
* use less memory internally; the big hog is the debug stuff.
stabs makes it hard to do anything but load everything at once,
but stabs is obsolete and dwarf allows pretty fine-grained
incremental loading
* fix things as they come up
J
|
|
From: Jeremy F. <je...@go...> - 2004-07-05 17:00:07
|
On Mon, 2004-07-05 at 08:47 +0100, Tom Hughes wrote: > > Would mremap work on these things, so we can move them down into the > > client address space? > > I don't think it would, because the kernel has other pointers to the > memory in question that wouldn't be adjusted by the mremap call. Hm, well that depends on which address space the kernel pokes at this memory. If its via a kernel mapping it doesn't matter where it is mapped in the user address space. Or I wonder if there's some way of getting an aliased mapping. I think mmap on /proc/self/mem doesn't work any more though... J |
|
From: Nicholas N. <nj...@ca...> - 2004-07-05 11:00:08
|
CVS commit by nethercote: Remove out-of-date info. M +0 -5 awards.html 1.3 --- devel-home/valgrind/awards.html #1.2:1.3 @@ -14,9 +14,4 @@ <p> -See Valgrind's <a href="http://freshmeat.net/stats/#rating">ranking</a> among -the best projects at <a href="http://freshmeat.net">freshmeat.net</a>. (At the -time of writing, Valgrind was number 6.) - -<p> <a href="http://opensource.org/OSA/"> <img src="http://opensource.org/osa/osamerit.png" |
|
From: Nicholas N. <nj...@ca...> - 2004-07-05 09:21:08
|
On Mon, 5 Jul 2004, Julian Seward wrote: >> Actually, that's another question - are we still interested in trying >> to support 2.2 kernels? There are a few minor tweaks needed to make it >> compile but it isn't clear that it runs properly afterwards - there is >> some suggestion of problems with signal/syscall handling by the looks >> of the reports on the users list. > > I vote No. I don't think it's a good tradeoff to introduce extra > complexity to support an increasingly marginal group of users. > There's enough complexity in there already. I vote maybe. If it's a matter of not much code (eg. < 100 lines) to keep 2.2 working, I don't think we should remove support. Assuming that's the case, since we don't have 2.2 test machines[1] the support will slowly bit-rot. I think some kind of official statement like "we will support 2.2 so long as it's not too much trouble, but beware that it might not work as well as 2.4/2.6, tell us if you have problems and we will fix them if they're not too hard" would be good. Where that statement would go and who would make it, I don't know. [1] not that the tests are all that effective at the moment, since a number of them fail each night and are generally ignored. N |
|
From: Julian S. <js...@ac...> - 2004-07-05 09:16:50
|
On Monday 05 July 2004 09:47, Nicholas Nethercote wrote: > On Sun, 4 Jul 2004, Tom Hughes wrote: > > As a result it typically seems to get allocated in the valgrind part > > of the address space which can't be accessed by the client while > > pointer checking is turned on. As libaio tries to peek at it in order > > to avoid entering the kernel when io_getevents is called and there > > are no events pending this is a problem... > > > > Anybody got any suggestions for a way of handling this? > > Something Julian suggested: instead of partitioning the address space, as > we currently do -- part for the client, part for Valgrind+tool -- instead > virtualize it, by introducing a software MMU. Every address would have to > be converted before use, though... it would be a lot of infrastructure and > probably quite tricky, and possibly very slow. However, it would get rid > of the problems with the client and Valgrind banging heads in the address > space. This is something we discussed a few months ago. On the plus side it completely decouples the client and V's address space and so sidesteps what I see (perhaps incorrectly) as the somewhat fragile scheme we have at the moment. On the minus side there is some overhead, plus there is complication at syscall boundaries of doing the relevant address translation and scatter/gather operations (copy_to_user, copy_from_user in effect). =46rom the performance point of view, it might be possible to somehow piggyback on what is effectively a simulated MMU=20 maintained anyway by memcheck/helgrind/addrcheck. =20 In any case I would be interested to know what the performance and complexity impact of a soft MMU is. Without that data, at the moment we don't really know what tradeoff we're making. J |
|
From: Nicholas N. <nj...@ca...> - 2004-07-05 09:00:23
|
On Fri, 2 Jul 2004, Nicholas Nethercote wrote: > I'm currently looking at rejigging Cachegrind's data structures. I think I > can solve the missing-info-for-unloaded-code and also significantly simplify > its code. I've made these changes. The improvement are pretty big. I've include the change log below, check out the general improvements. They arose because I split one messy data structure, which was (I now realise) serving two distinct purposes, into two much cleaner data structures. The diff is at: www.cl.cam.ac.uk/~njn25/cg.diff Enough code has changed that the diff is hard to read, the new cg_main.c is here: www.cl.cam.ac.uk/~njn25/cg_main.c [I tried attaching them but the mailing list software didn't like them, they were too big.] I'm pretty keen to commit these changes soon, in time for 2.1.2. It would be good to see them in Calltree too, but I'm not sure how easy that will be. N Completely overhauled Cachegrind's data structures. With the new scheme, there are two main structures: 1. The CC table holds a cost centre (CC) for every distinct source code line, as found using debug/symbol info. It's arranged by files, then functions, then lines. 2. The instr-info-table holds certain important pieces of info about each instruction -- instr_addr, instr_size, data_size, its line-CC. A pointer to the instr's info is passed to the simulation functions, which is shorter and quicker than passing the pieces individually. This is nice and simple. Previously, there was a single data structure (the BBCC table) which mingled the two purposes (maintaining CCs and caching instruction info). The CC stuff was done at the level of instructions, and there were different CC types for different kinds of instructions, and it was pretty yucky. It's now much cleaner. As a result, we have the following general improvements: - Previously, when code was unloaded all its hit/miss counts were stuck in a single "discard" CC, and so that code would not be annotated. Now this code is profiled and annotatable just like all other code. - Source code size is 27% smaller. cg_main.c is now 1494 lines, down from 2174. Some (1/3?) of this is from removing the special handling of JIFZ and general compaction, but most is from the data structure changes. Happily, a lot of the removed code was nasty. - Object code size (vgskin_cachegrind.so) is 15% smaller. - cachegrind.out.pid size is about 90+% smaller(!) Annotation time is accordingly much faster. Doing cost-centres at the level of source code lines rather than instructions makes a big difference, since there's typically 2--3 instructions per source line. Even better, when debug info is not present, entire functions (and even files) get collapsed into a single "???" CC. (This behaviour is no different to what happened before, it's just the collapsing used to occur in the annotation script, rather than within Cachegrind.) This is a big win for stripped libraries. - Memory consumption is about 10--20% less, due to fewer CCs. - Speed is not much changed -- the changes were not in the intensive parts, so the only likely change is a cache improvement due to using less memory. SPEC experiments go -3 -- 10% faster, with the "average" being unchanged or perhaps a tiny bit faster. I've tested it moderately thoroughly, it seems to give the same results as the old version where it should. Some particularly nice changes that happened: - No longer need an instrumentation prepass; this is because CCs are not stored grouped by BB, and they're all the same size now (which makes various code much simpler than before). - The actions to take when a BB translation is discarded (due to the translation table getting full) are much easier -- just chuck all the instr-info nodes for the BB, without touching the CCs. - Dumping the cachegrind.out.pid file at the end is much simpler, just because the CC data structure is much neater. Some other, specific changes: - Removed the JIFZ special handling, which never did what it was intended to do and just complicated things. This changes the results for REP-prefixed instructions very slightly, but it's not important. - Abbreviated the FP/MMX/SSE crap by being slightly laxer with size checking -- will be caught later if there's any problems anyway - Removed "fi" and "fe" handling from cg_annotate, no longer needed due to neatening of the CC-table. - Factorised out some code a bit, so fewer monolithic slabs. - Just improved formatting and compacted code in general in a few places. - Removed the long-commented-out sanity checking code at the bottom Phew. |
|
From: Nicholas N. <nj...@ca...> - 2004-07-05 08:57:58
|
On Sun, 4 Jul 2004, Tom Hughes wrote: > As a result it typically seems to get allocated in the valgrind part > of the address space which can't be accessed by the client while > pointer checking is turned on. As libaio tries to peek at it in order > to avoid entering the kernel when io_getevents is called and there > are no events pending this is a problem... > > Anybody got any suggestions for a way of handling this? Something Julian suggested: instead of partitioning the address space, as we currently do -- part for the client, part for Valgrind+tool -- instead virtualize it, by introducing a software MMU. Every address would have to be converted before use, though... it would be a lot of infrastructure and probably quite tricky, and possibly very slow. However, it would get rid of the problems with the client and Valgrind banging heads in the address space. N |
|
From: Julian S. <js...@ac...> - 2004-07-05 08:52:51
|
> Actually, that's another question - are we still interested in trying > to support 2.2 kernels? There are a few minor tweaks needed to make it > compile but it isn't clear that it runs properly afterwards - there is > some suggestion of problems with signal/syscall handling by the looks > of the reports on the users list. I vote No. I don't think it's a good tradeoff to introduce extra complexity to support an increasingly marginal group of users. There's enough complexity in there already. J |
|
From: Nicholas N. <nj...@ca...> - 2004-07-05 08:45:10
|
On Sun, 4 Jul 2004, Tom Hughes wrote: > We currently add a couple of auxv entries to convery information from > stage 1 to the main program. Currently those entries have high key > values to keeep them separate from existing entries that the kernel > generates. Can we pass the info from stage1 to stage2 without using the auxv? Could it be done just with two global variables? stage1 is still in memory when stage2 starts, so this shouldn't be too hard, right? If it's possible to do it this way, that would be better than doing it via auxv and not being certain if it's going to work or going to clobber some random memory location miles away. N |
|
From: Tom H. <th...@cy...> - 2004-07-05 08:43:45
|
Nightly build on audi ( Red Hat 9 ) started at 2004-07-05 03:15:03 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 169 tests, 7 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-05 07:53:04
|
In message <1088990029.6827.10.camel@localhost>
Jeremy Fitzhardinge <je...@go...> wrote:
> Hm. Current glibc (on FC2) defines AT_ entries up to 37, so I presume
> the limit has been removed, or at least increased (even SYSINFO_EHDR is
> 33). On the other hand, these entries won't appear on older systems, so
> there's no issue there. I guess we could just hijack some lower numbers
> and hope for the best (we could use different constants on different
> systems, but I'm not terribly keen on that).
I looked at the FC2 glibc before posting, and _dl_sysdep_start in
sysdeps/generic/dl-sysdep.c still seems to be using an unsigned long
to keep track of which entries it has seen.
Admittedly certain HAVE_xxx defines will stop it doing so, so it isn't
clear whether the actual configuration used on FC2 has a problem but
certainly the last time I disassembled that routine on a RH box it was
doing so.
> Is this causing real problems?
The only time I've seen it cause a problem was on an old RH system
with a 2.2 kernel last time I was trying to get valgrind running
on a 2.2 system. It came up again last week when somebody on the users
list was trying to get valgrind running on a 2.2 system.
Actually, that's another question - are we still interested in trying
to support 2.2 kernels? There are a few minor tweaks needed to make it
compile but it isn't clear that it runs properly afterwards - there is
some suggestion of problems with signal/syscall handling by the looks
of the reports on the users list.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-07-05 07:47:47
|
In message <1088989847.6827.6.camel@localhost>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Sun, 2004-07-04 at 19:38 +0100, Tom Hughes wrote:
>> As a result it typically seems to get allocated in the valgrind part
>> of the address space which can't be accessed by the client while
>> pointer checking is turned on. As libaio tries to peek at it in order
>> to avoid entering the kernel when io_getevents is called and there
>> are no events pending this is a problem...
>>
>> Anybody got any suggestions for a way of handling this?
>
> The most immediate is to try and get the AIO people to change such a
> braindead API. There aren't any other instances of a syscall plonking
> things down in memory without some way to control it.
I agree that it's pretty braindead. In fact older versions of libaio
don't seem to peek at the memory in this way, but the fact that it is
mapped in user space suggests that it was always intended.
> Would mremap work on these things, so we can move them down into the
> client address space?
I don't think it would, because the kernel has other pointers to the
memory in question that wouldn't be adjusted by the mremap call.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-07-05 07:32:06
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-07-05 03:05:04 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 169 tests, 5 stderr failures, 1 stdout failure ================= memcheck/tests/badfree-2trace (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/new_nothrow (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: <js...@ac...> - 2004-07-05 03:01:05
|
Nightly build on nemesis ( SuSE 9.1 ) started at 2004-07-05 03:50:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow memcheck/tests/null_socket (stderr) memcheck/tests/overlap (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/pushfpopf (stderr) memcheck/tests/realloc1 (stderr) memcheck/tests/realloc2 (stderr) memcheck/tests/realloc3 (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/signal2 (stderr) memcheck/tests/supp1 (stderr) memcheck/tests/supp2 (stderr) memcheck/tests/suppfree (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/trivialleak (stderr) memcheck/tests/tronical (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-07-05 02:27:12
|
Nightly build on dunsmere ( Fedora Core 2 ) started at 2004-07-05 03:20:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 169 tests, 7 stderr failures, 1 stdout failure ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-05 02:15:27
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-07-05 03:10:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 169 tests, 4 stderr failures, 0 stdout failures ================= helgrind/tests/deadlock (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-05 02:14:05
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-07-05 03:00:01 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow resolv: valgrind ./resolv rlimit_nofile: valgrind ./rlimit_nofile seg_override: valgrind ./seg_override sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 169 tests, 1 stderr failure, 0 stdout failures ================= memcheck/tests/badfree-2trace (stderr) make: *** [regtest] Error 1 |
|
From: Jeremy F. <je...@go...> - 2004-07-05 01:43:55
|
On Sun, 2004-07-04 at 19:38 +0100, Tom Hughes wrote: > As a result it typically seems to get allocated in the valgrind part > of the address space which can't be accessed by the client while > pointer checking is turned on. As libaio tries to peek at it in order > to avoid entering the kernel when io_getevents is called and there > are no events pending this is a problem... > > Anybody got any suggestions for a way of handling this? The most immediate is to try and get the AIO people to change such a braindead API. There aren't any other instances of a syscall plonking things down in memory without some way to control it. Would mremap work on these things, so we can move them down into the client address space? J |
|
From: Jeremy F. <je...@go...> - 2004-07-05 01:43:39
|
On Sun, 2004-07-04 at 19:56 +0100, Tom Hughes wrote: > I think I did mention this somewhere (probably the users list) some > time ago, but a recent posting on the users list reminded me of it. > > We currently add a couple of auxv entries to convery information from > stage 1 to the main program. Currently those entries have high key > values to keeep them separate from existing entries that the kernel > generates. Specifically they have these values: > > AT_UME_PADFD 0xff01 > AT_UME_EXECFD 0xff02 > > The problem is that _dl_sysdep_start in glibc tries to keep track > of which auxv entries have been seen using an unsigned long and > orring in bits based on the auxv key values. > > Obviously 0xff01 and 0xff02 are way out of range for an unsigned > long that can only handle 32 bits. Most of the time we get away with > this because gcc generates code which doesn't set any bits if the > value is out of range. > > Some compilers (mostly older ones on 2.2 kernel systems it seems) do > generate problem code that uses the x86 set bit instruction. This code > just ignores the fact that it is out of range and writes to some other > word of memory miles away from the unsigned long. > > The point is that there seems to be some sort of assumption in glibc > that AT_xxx values should be in the 0..31 range and we are currently > violating that. Hm. Current glibc (on FC2) defines AT_ entries up to 37, so I presume the limit has been removed, or at least increased (even SYSINFO_EHDR is 33). On the other hand, these entries won't appear on older systems, so there's no issue there. I guess we could just hijack some lower numbers and hope for the best (we could use different constants on different systems, but I'm not terribly keen on that). Is this causing real problems? J |