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
(28) |
3
(21) |
4
(27) |
5
(22) |
6
(24) |
7
(25) |
8
(21) |
|
9
(18) |
10
(20) |
11
(10) |
12
(36) |
13
(18) |
14
(18) |
15
(29) |
|
16
(17) |
17
(7) |
18
(11) |
19
(17) |
20
(18) |
21
(12) |
22
(13) |
|
23
(9) |
24
(8) |
25
(7) |
26
(22) |
27
(18) |
28
(9) |
29
(15) |
|
30
(13) |
31
(7) |
|
|
|
|
|
|
From: John R.
|
Julian Seward wrote: > It looks like all segments listed in /proc/self/maps have x > permission regardless. SuSE isn't the only one. Fedora Core 4 also has this on x86, and maintainers think that this is good: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160889#c3 I haven't tracked it down all the way, but my guess is that as long as the page is within the limit of the %cs segment, then I'll see 'x' in /proc/pid/maps. In other words, if there is an executable page at any higher address, then all lower pages will see 'x', regardless of requested permissions. Supposedly this is "closer to reality" on any machine that does not have the NX permission feature, than omitting the 'x' from the report if you asked for "rw-p". Observe this program carefully. The page at 0x100000 (1MB) gets reported as "--xp" because there are executable pages at higher addresses (including 0x08048000, the default start of .text.) Jumping to the page gives a SIGSEGV on the 1st instruction because 0x100000: add %al,(%eax) %eax [0x100000] does not have Read or Write permission. ----- #include <sys/types.h> #include <sys/mman.h> main() { char *vaddr= mmap(0x100000, 4096, PROT_NONE, MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE, 0,0); ((void (*)(void))vaddr)(); return 0; } ----- Asking for ~MAP_FIXED at 0x0 gives a page above the limit of %cs, [0xb7f08000 on Fedora Core 4] so that page is reported as "---p", and the SIGSEGV happens one instruction earlier, on the CALL itself: 0x80483b8 <main+60>: call *%eax because the address is beyond the limit of %cs. -- |
|
From: Julian S. <js...@ac...> - 2005-10-09 19:00:29
|
> >>> further (anybody willing to incorporate gcc's optimizer into V? :). > >> > >> Hercules, Augean stables, etc. > > > > ENEEDMOREINPUT See http://ancienthistory.about.com/library/bl/bl_herc_lab5.htm J |
|
From: Nicholas N. <nj...@cs...> - 2005-10-09 16:03:21
|
On Sun, 9 Oct 2005, Oswald Buddenhagen wrote: >>> an orthogonal issue: V could detect tight loops and optimize them >>> further (anybody willing to incorporate gcc's optimizer into V? :). >> >> Hercules, Augean stables, etc. >> > ENEEDMOREINPUT Julian's making a point about the level of effort required. That point holds for this whole discussion; there are plenty of things we could do with Valgrind, but we have only a small number of developers so we have to choose our projects carefully. I don't think making translations persistent passes a basic cost/benefit analysis. Nick |
|
From: Oswald B. <os...@kd...> - 2005-10-09 13:57:43
|
On Sun, Oct 09, 2005 at 12:12:50PM +0100, Julian Seward wrote: > > a critical aspect: valgrind is a debugging tool. that means that a > > particular binary is usually executed exactly once. consequently a > > wholesale consistency check would drastically lower the effect of > > Most large apps are composed mainly of .so's > most ... > and I bet 99.9% of the code does not change from run to run. > yes, and at dso granularity that means, that the program must have 1000 dsos to match up to that ratio if one source file is modified. but somehow i suspect that at this size the granularity would not really matter anyway ... > > an orthogonal issue: V could detect tight loops and optimize them > > further (anybody willing to incorporate gcc's optimizer into V? :). > > Hercules, Augean stables, etc. > ENEEDMOREINPUT > It might not help much - for complex tools like cachegrind and > memcheck most of the time is spent in the helper functions called from > generated code. > hmm, that's an argument. depends on the tool, of course. > The new jit is better than the old at optimising and will even unroll > single-basic-block loops itself. > i heard rumors like that already. will have to look myself finally. :) -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Julian S. <js...@ac...> - 2005-10-09 13:28:47
|
> a critical aspect: valgrind is a debugging tool. that means that a > particular binary is usually executed exactly once. consequently a > wholesale consistency check would drastically lower the effect of Most large apps are composed mainly of .so's and I bet 99.9% of the code does not change from run to run. > an orthogonal issue: V could detect tight loops and optimize them > further (anybody willing to incorporate gcc's optimizer into V? :). Hercules, Augean stables, etc. It might not help much - for complex tools like cachegrind and memcheck most of the time is spent in the helper functions called from generated code. The new jit is better than the old at optimising and will even unroll single-basic-block loops itself. J |
|
From: Oswald B. <os...@kd...> - 2005-10-09 11:26:09
|
On Sun, Oct 09, 2005 at 01:11:53PM +0200, Josef Weidendorfer wrote: > On Sunday 09 October 2005 11:52, Oswald Buddenhagen wrote: > > On Sat, Oct 08, 2005 at 06:49:52PM -0500, Nicholas Nethercote wrote: > > > On Sat, 8 Oct 2005, Josef Weidendorfer wrote: > > > >Hmmm... this leads to a further question: Could a persistant > > > >translation cache speed up Valgrind ... ? > > > a critical aspect: valgrind is a debugging tool. that means that a > > particular binary is usually executed exactly once. > > Performance was not the original motivation for my suggestion to persistance, > but only about improving profiling ability of valgrind itself (either with > OProfile or self hosting). > i know. but as you stole another thread, i stole your's. ;-P > Why do you need function level consistency checks? Checking the modify > date of a shared object should be enough when separating TCs by > objects. You usually do not have self-modifying code in read-only > pages backed up by files. > you completely missed the point ... > And I am not sure whether the issue about absolute addresses generated > by the binary translation engine does happen with VEX. > i'm pretty sure it does. for the real data the mapping is 1:1. the shadow memory currently has a pretty straight-forward mapping as well. code references are "somehow" different ... :} -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Josef W. <Jos...@gm...> - 2005-10-09 11:20:19
|
On Sunday 09 October 2005 04:40, Julian Seward wrote: > 4001e000-4001f000 r-xp /usr/lib/locale/en_GB.utf8/LC_MEASUREMENT > 4001f000-40020000 r-xp /usr/lib/locale/en_GB.utf8/LC_TELEPHONE > 40020000-40021000 r-xp /usr/lib/locale/en_GB.utf8/LC_ADDRESS > > ... > > Can anyone with SuSE 10.0 on real hardware check this? Happens on real hardware here, too :-( Above segments (LC_*) are only mapped with PROT_READ, but show up with x in /proc/*/maps. I did not investigate further. Time for a bug report? Josef |
|
From: Josef W. <Jos...@gm...> - 2005-10-09 11:12:29
|
On Sunday 09 October 2005 11:52, Oswald Buddenhagen wrote: > On Sat, Oct 08, 2005 at 06:49:52PM -0500, Nicholas Nethercote wrote: > > On Sat, 8 Oct 2005, Josef Weidendorfer wrote: > > >Hmmm... this leads to a further question: Could a persistant > > >translation cache speed up Valgrind ... ? > a critical aspect: valgrind is a debugging tool. that means that a > particular binary is usually executed exactly once. Performance was not the original motivation for my suggestion to persistance, but only about improving profiling ability of valgrind itself (either with OProfile or self hosting). Why do you need function level consistency checks? Checking the modify date of a shared object should be enough when separating TCs by objects. You usually do not have self-modifying code in read-only pages backed up by files. And I am not sure whether the issue about absolute addresses generated by the binary translation engine does happen with VEX. Josef |
|
From: Oswald B. <os...@kd...> - 2005-10-09 09:52:31
|
On Sat, Oct 08, 2005 at 06:49:52PM -0500, Nicholas Nethercote wrote: > On Sat, 8 Oct 2005, Josef Weidendorfer wrote: > > >Hmmm... this leads to a further question: Could a persistant > >translation cache speed up Valgrind, by simply executing the > >"pre-translated" code chunks from an earlier run? In multiple runs, > >shared objects can be mapped to different addresses. So the > >translation cache should be separated by shared objects. But this > >would need a (object/offset) tuple as lookup key instead of a simple > >code address. > > See this paper from the recent WBIA workshop: > > http://rogue.colorado.edu/draco/papers/wbia05-persistence.pdf > i have the impression that these guys were told to produce six pages, so they did ... with the content for max four pages. oh, well. :) a critical aspect: valgrind is a debugging tool. that means that a particular binary is usually executed exactly once. consequently a wholesale consistency check would drastically lower the effect of persistence (there still would be a gain for separately cached dynamic objects). so we need function-level granularity, based on function signatures. however, static linking will most often yield different binary images for unmodified functions due to offset changes stemming from unrelated code changes. i *think* such locations are easy to spot - they are either dynamic relocations of some type or they are involved into PLT or GOT references, and debug info certainly provides the info directly. they would be made wildcards in the signatures, and their values would have to be propagated into the translated code. fetching from the cache could be done at the function translation stage, but i guess the global view (function order) one has at object load time would help improving the overall overhead. an orthogonal issue: V could detect tight loops and optimize them further (anybody willing to incorporate gcc's optimizer into V? :). with persistent translations, expensive optimizations could be applied more liberally. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: <js...@ac...> - 2005-10-09 04:09:56
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-10-09 03:30:01 BST Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 190 tests, 2 stderr failures, 0 stdout failures ================= none/tests/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Julian S. <js...@ac...> - 2005-10-09 02:40:48
|
Am just playing with V (svn trunk) on SuSE 10.0, and I get failures from the sync checker with --sanity-level=3. It looks like all segments listed in /proc/self/maps have x permission regardless. A section from "cat /proc/self/maps" says (skipping inode/dev and offset): 4001e000-4001f000 r-xp /usr/lib/locale/en_GB.utf8/LC_MEASUREMENT 4001f000-40020000 r-xp /usr/lib/locale/en_GB.utf8/LC_TELEPHONE 40020000-40021000 r-xp /usr/lib/locale/en_GB.utf8/LC_ADDRESS whereas on SuSE 9.2 they are r--p as you'd expect. On SuSE 10.0 the only sections listed as not having x are [stack] and [vdso]. The only thing that might be strange is that they are both running on VMware Workstation 5, although that seems unlikely. Can anyone with SuSE 10.0 on real hardware check this? This is screwing up the new address space manager's sync checker because it maps in the client's data sections as rw- (also the interpreter's) as they request, but when it compares against /proc/self/maps it sees rwx. J |
|
From: Tom H. <to...@co...> - 2005-10-09 02:40:08
|
Nightly build on dunsmere ( athlon, Fedora Core 4 ) started at 2005-10-09 03:30:05 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 192 tests, 12 stderr failures, 4 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/trivialleak (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/map_unmap (stdout) none/tests/map_unmap (stderr) none/tests/mremap2 (stdout) none/tests/sigstackgrowth (stdout) none/tests/sigstackgrowth (stderr) none/tests/stackgrowth (stdout) none/tests/stackgrowth (stderr) none/tests/x86/int (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 192 tests, 13 stderr failures, 5 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) lackey/tests/true (stderr) none/tests/faultstatus (stderr) none/tests/map_unmap (stdout) none/tests/map_unmap (stderr) none/tests/mremap2 (stdout) none/tests/sigstackgrowth (stdout) none/tests/sigstackgrowth (stderr) none/tests/stackgrowth (stdout) none/tests/stackgrowth (stderr) none/tests/threaded-fork (stdout) none/tests/threaded-fork (stderr) none/tests/x86/int (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Oct 9 03:35:06 2005 --- new.short Sun Oct 9 03:40:00 2005 *************** *** 8,10 **** ! == 192 tests, 13 stderr failures, 5 stdout failures ================= memcheck/tests/leak-tree (stderr) --- 8,10 ---- ! == 192 tests, 12 stderr failures, 4 stdout failures ================= memcheck/tests/leak-tree (stderr) *************** *** 12,13 **** --- 12,14 ---- memcheck/tests/pointer-trace (stderr) + memcheck/tests/trivialleak (stderr) memcheck/tests/weirdioctl (stderr) *************** *** 15,17 **** memcheck/tests/xml1 (stderr) - lackey/tests/true (stderr) none/tests/faultstatus (stderr) --- 16,17 ---- *************** *** 24,27 **** none/tests/stackgrowth (stderr) - none/tests/threaded-fork (stdout) - none/tests/threaded-fork (stderr) none/tests/x86/int (stderr) --- 24,25 ---- |
|
From: Tom H. <th...@cy...> - 2005-10-09 02:27:45
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2005-10-09 03:15:05 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 191 tests, 16 stderr failures, 0 stdout failures ================= memcheck/tests/addressable (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/mempool (stderr) memcheck/tests/nanoleak (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) none/tests/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 191 tests, 16 stderr failures, 1 stdout failure ================= memcheck/tests/addressable (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/mempool (stderr) memcheck/tests/nanoleak (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) none/tests/faultstatus (stderr) none/tests/x86/int (stderr) none/tests/x86/yield (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Oct 9 03:21:33 2005 --- new.short Sun Oct 9 03:27:40 2005 *************** *** 8,10 **** ! == 191 tests, 16 stderr failures, 1 stdout failure ================= memcheck/tests/addressable (stderr) --- 8,10 ---- ! == 191 tests, 16 stderr failures, 0 stdout failures ================= memcheck/tests/addressable (stderr) *************** *** 25,27 **** none/tests/x86/int (stderr) - none/tests/x86/yield (stdout) --- 25,26 ---- |
|
From: Tom H. <th...@cy...> - 2005-10-09 02:25:00
|
Nightly build on ginetta ( i686, Red Hat 8.0 ) started at 2005-10-09 03:10:08 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 191 tests, 4 stderr failures, 1 stdout failure ================= memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/x86/int (stderr) none/tests/x86/yield (stdout) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 191 tests, 4 stderr failures, 0 stdout failures ================= memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Oct 9 03:18:35 2005 --- new.short Sun Oct 9 03:24:55 2005 *************** *** 8,10 **** ! == 191 tests, 4 stderr failures, 0 stdout failures ================= memcheck/tests/mempool (stderr) --- 8,10 ---- ! == 191 tests, 4 stderr failures, 1 stdout failure ================= memcheck/tests/mempool (stderr) *************** *** 13,14 **** --- 13,15 ---- none/tests/x86/int (stderr) + none/tests/x86/yield (stdout) |
|
From: Tom H. <th...@cy...> - 2005-10-09 02:21:46
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2005-10-09 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 == 166 tests, 8 stderr failures, 2 stdout failures ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/as_mmap (stderr) none/tests/as_shm (stdout) none/tests/as_shm (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) none/tests/tls (stdout) |
|
From: Tom H. <th...@cy...> - 2005-10-09 02:20:35
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2005-10-09 03:10:08 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 == 166 tests, 7 stderr failures, 2 stdout failures ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/as_mmap (stderr) none/tests/as_shm (stdout) none/tests/as_shm (stderr) none/tests/faultstatus (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2005-10-09 02:18:17
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2005-10-09 03:05: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 == 166 tests, 7 stderr failures, 2 stdout failures ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/as_mmap (stderr) none/tests/as_shm (stdout) none/tests/as_shm (stderr) none/tests/faultstatus (stderr) none/tests/mremap2 (stdout) |
|
From: Julian S. <js...@ac...> - 2005-10-09 00:52:17
|
> With the latest libc version, no symbol information shows up at all: > > Conditional jump or move depends on uninitialised value(s) > at 0x1B8ECB13: (within /lib/ld-2.3.5.so) > by 0x1B8E631C: (within /lib/ld-2.3.5.so) > by 0x1B8F2BDD: (within /lib/ld-2.3.5.so) > by 0x1B8E7675: (within /lib/ld-2.3.5.so) > by 0x1B8E47C6: (within /lib/ld-2.3.5.so) The same thing (or similar) happened in the release version of SuSE 9.3. Shortly thereafter SuSE put a non-stripped version on their online update and that made the problem go away, and they seem to have stayed with that in SuSE 10.0 as Josef observes. Which is excellent. I see what the patch is for and it looks plausible. However to me it is fixing the symptom -- the fundamental problem is that the glibc packagers insist on removing ever more debugging info. > By the way, are any of the Debian valgrind maintainers regular readers > of this list? If not, I'll forward this information to the BTS. Please hassle the Debian glibc maintainers. Point out that they can't expect to strip off all vestiges of debug info and still have a debuggable system. At least leave the symbols on. /lib/ld-2.3.5.so is only on the order of 110k even with symbols on, so there's really very little to be gained from stripping it anyway. J |