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
(17) |
2
(21) |
3
(17) |
4
(28) |
5
(21) |
6
(11) |
|
7
(13) |
8
(21) |
9
(21) |
10
(9) |
11
(11) |
12
(15) |
13
(23) |
|
14
(15) |
15
(22) |
16
(28) |
17
(12) |
18
(15) |
19
(8) |
20
(7) |
|
21
(8) |
22
(12) |
23
(13) |
24
(7) |
25
(7) |
26
(3) |
27
(9) |
|
28
(13) |
29
(7) |
30
(7) |
31
(9) |
|
|
|
|
From: George S. <st...@kd...> - 2004-03-04 23:59:43
|
On Thursday 04 March 2004 18:13, George Staikos wrote:
> > - /* Ignore zero-sized scopes */
> > - if (this == next) {
> > + /* Ignore zero-sized or negative scopes */
> > + if (size <= 0) {
>
> This is exactly the first thing I tried, and then I got more errors after
> that, so I assumed it was more complex. I'm going to try the latest
> snapshot of PPC valgrind and if this fix is not included, I'll add it in
> again. However the log looked worse last time. :-) I'll post the new
> results when I get them.
As a followup, with the latest PPC patch and this patch applied, things work
better, but are still quite broken. The simple 'cout << "Hello world"' app
now works fine (no errors reported), but with the Qt examples/hello demo I
get 30000:
==26698== Conditional jump or move depends on uninitialised value(s)
At startup I also see:
@@ expected ';' at type attrib (ptr="(99,1),(8,12)")
@@ unlikely looking definition in unparsed remains "(0,219)=@(99,1),(8,12)"
I saw this yesterday when I tried the size <= 0 patch too.
--
George Staikos
KDE Developer http://www.kde.org/
Staikos Computing Services Inc. http://www.staikos.net/
|
|
From: Tom H. <th...@cy...> - 2004-03-04 23:43:24
|
CVS commit by thughes:
Add support for 16 bit pushes and pops of segment registers to
fix bug #76762.
A none/tests/pushpopseg.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright]
A none/tests/pushpopseg.stderr.exp 1.1
A none/tests/pushpopseg.stdout.exp 1.1
A none/tests/pushpopseg.vgtest 1.1
M +3 -3 coregrind/vg_to_ucode.c 1.131
M +1 -0 none/tests/.cvsignore 1.10
M +3 -1 none/tests/Makefile.am 1.29
--- valgrind/coregrind/vg_to_ucode.c #1.130:1.131
@@ -3746,9 +3746,9 @@ void dis_push_segreg ( UCodeBlock* cb, U
{
Int t1 = newTemp(cb), t2 = newTemp(cb);
- vg_assert(sz == 4);
+ vg_assert(sz == 2 || sz == 4);
uInstr2(cb, GETSEG, 2, ArchRegS, sreg, TempReg, t1);
uInstr2(cb, GET, 4, ArchReg, R_ESP, TempReg, t2);
uInstr2(cb, SUB, 4, Literal, 0, TempReg, t2);
- uLiteral(cb, 4);
+ uLiteral(cb, sz);
uInstr2(cb, PUT, 4, TempReg, t2, ArchReg, R_ESP);
uInstr2(cb, STORE, 2, TempReg, t1, TempReg, t2);
@@ -3760,5 +3760,5 @@ void dis_pop_segreg ( UCodeBlock* cb, UI
{
Int t1 = newTemp(cb), t2 = newTemp(cb);
- vg_assert(sz == 4);
+ vg_assert(sz == 2 || sz == 4);
uInstr2(cb, GET, 4, ArchReg, R_ESP, TempReg, t2);
uInstr2(cb, LOAD, 2, TempReg, t2, TempReg, t1);
--- valgrind/none/tests/.cvsignore #1.9:1.10
@@ -57,4 +57,5 @@
pth_specific
pth_yield
+pushpopseg
*.stdout.diff
*.stderr.diff
--- valgrind/none/tests/Makefile.am #1.28:1.29
@@ -37,4 +37,5 @@
pth_blockedsig.stderr.exp \
pth_blockedsig.stdout.exp pth_blockedsig.vgtest \
+ pushpopseg.stderr.exp pushpopseg.stdout.exp pushpopseg.vgtest \
rcl_assert.stderr.exp rcl_assert.vgtest \
rcrl.stderr.exp rcrl.stdout.exp rcrl.vgtest \
@@ -60,5 +61,5 @@
munmap_exe map_unmap mremap rcl_assert \
rcrl readline1 resolv seg_override sha1_test shortpush shorts smc1 \
- pth_blockedsig \
+ pth_blockedsig pushpopseg \
syscall-restart1 syscall-restart2 system \
coolo_sigaction gxx304 yield
@@ -98,4 +99,5 @@
mremap_SOURCES = mremap.c
munmap_exe_SOURCES = munmap_exe.c
+pushpopseg_SOURCES = pushpopseg.c
rcl_assert_SOURCES = rcl_assert.S
rcrl_SOURCES = rcrl.c
|
|
From: George S. <st...@kd...> - 2004-03-04 23:21:00
|
On Thursday 04 March 2004 17:42, Jeremy Fitzhardinge wrote:
> No, that's exactly right. The debug contains a scope which ends before
> it begins. I may need to look into it in more detail (there could be a
> meaningful interpretation of this), but the simple fix, which is in CVS
> HEAD, is this:
>
> coregrind/vg_symtab2.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff -puN coregrind/vg_symtab2.c~fix-negscope coregrind/vg_symtab2.c
> --- valgrind/coregrind/vg_symtab2.c~fix-negscope 2004-02-05
> 14:00:54.115608640 -0800 +++
> valgrind-jeremy/coregrind/vg_symtab2.c 2004-02-05 14:01:15.046426672 -0800
> @@ -301,8 +301,8 @@ void VG_(addScopeInfo) ( SegInfo* si,
> Int size = next - this;
> ScopeRange range;
>
> - /* Ignore zero-sized scopes */
> - if (this == next) {
> + /* Ignore zero-sized or negative scopes */
> + if (size <= 0) {
This is exactly the first thing I tried, and then I got more errors after
that, so I assumed it was more complex. I'm going to try the latest snapshot
of PPC valgrind and if this fix is not included, I'll add it in again.
However the log looked worse last time. :-) I'll post the new results when I
get them.
FYI: I'm using a much different system than Paul - different glibc,
compiler, and probably kernel. I guess we can expect some differences.
--
George Staikos
KDE Developer http://www.kde.org/
Staikos Computing Services Inc. http://www.staikos.net/
|
|
From: Paul M. <pa...@sa...> - 2004-03-04 23:06:42
|
Nicholas Nethercote writes: > > You might want to add that it requires kernel 2.6 or above right now. With > > 2.4 it asserts, crashes, or freezes. > > Is that right, Paul? I'll add a note if so. I fixed the main reason why it was crashing on 2.4 - the 2.4 kernel doesn't set the child's stack pointer on clone. So I added code to set the stack pointer in the child first thing. I have updated the tarball at http://ozlabs.org/~paulus/. Other changes include: * removed the XCRF, JMPB0 and JMPB1 uCodes; they weren't being used * removed LOAD_R and STORE_C, use LOCK; LOAD and LOCK; STORE instead * made the icbi instruction (instruction cache block invalidate) invalidate the translation cache for the addressed cache line * fix the thread startup for ppc * added code to set the valid bits exactly for ADD and nearly exactly for CMP0. (This reduces the number of errors detected on ls -l by about 75%. :) Paul. |
|
From: Jeremy F. <je...@go...> - 2004-03-04 22:50:33
|
On Thu, 2004-03-04 at 12:13, George Staikos wrote:
> 47306 type=224 othr=0 desc=0 value=0x16C strx=0
> }
> 47307 type=224 othr=0 desc=0 value=0x8C strx=0
>
> So the failure is at the outer most scope. The assert fails because
> range->size = -0xe0. I'm not sure if it's a coincidence that
> 0x16c=0x8c+0xe0. Any ideas what could be going wrong here? I have tried
> several C++ programs and they all trigger this, while I haven't found a
> single C program that fails so far. GCC version is 2.95.4.
No, that's exactly right. The debug contains a scope which ends before
it begins. I may need to look into it in more detail (there could be a
meaningful interpretation of this), but the simple fix, which is in CVS
HEAD, is this:
coregrind/vg_symtab2.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -puN coregrind/vg_symtab2.c~fix-negscope coregrind/vg_symtab2.c
--- valgrind/coregrind/vg_symtab2.c~fix-negscope 2004-02-05 14:00:54.115608640 -0800
+++ valgrind-jeremy/coregrind/vg_symtab2.c 2004-02-05 14:01:15.046426672 -0800
@@ -301,8 +301,8 @@ void VG_(addScopeInfo) ( SegInfo* si,
Int size = next - this;
ScopeRange range;
- /* Ignore zero-sized scopes */
- if (this == next) {
+ /* Ignore zero-sized or negative scopes */
+ if (size <= 0) {
if (debug)
VG_(printf)("ignoring zero-sized range, scope %p at %p\n", scope, this);
return;
_
|
|
From: Jeremy F. <je...@go...> - 2004-03-04 22:48:28
|
CVS commit by fitzhardinge:
List memalign as an allocator.
M +7 -1 ms_main.c 1.3
--- valgrind/massif/ms_main.c #1.2:1.3
@@ -255,5 +255,5 @@ static UInt n_heap_blocks = 0;
// First six filled in, rest should be zeroed. argc/argv-style vector.
-static UInt n_alloc_fns = 8;
+static UInt n_alloc_fns = 9;
static Char* alloc_fns[MAX_ALLOC_FNS] = {
"malloc",
@@ -265,4 +265,5 @@ static Char* alloc_fns[MAX_ALLOC_FNS] =
"realloc",
"my_malloc", // from vg_libpthread.c
+ "memalign",
};
@@ -781,4 +782,9 @@ void* SK_(calloc) ( Int m, Int size )
}
+void *SK_(memalign)( Int align, Int n )
+{
+ return new_block( n, align, False );
+}
+
void SK_(free) ( void* p )
{
|
|
From: Jeremy F. <je...@go...> - 2004-03-04 22:45:08
|
On Thu, 2004-03-04 at 01:59, Nicholas Nethercote wrote: > Our idea was to have a platform-independent language that skins in which > skins would write their instrumentation. It would presumably look a lot > like UCode. As for skin-specific UInstrs, we thought ditching them would > be ok; Memcheck is the only one that uses them, and they're not really > necessary -- even Tag_PCast40 is just a NEG, SBB, OR which is currently > expressible in UCode. Yes, but not portably. It relies on the x86 behaviour of NEG setting carry depending on whether its argument is zero or not. Unless we define the NEG UOp to contain this, it isn't very portable. Paul's implementation of Tag_PCast40 is very different, and uses the PPC's extensive set of bit-swizzling instructions. It seems to me that the PCast* operations can be composed out of various fairly generic pieces which we could make into UCode operations (things to expand any 0 bit to all zero bits, any 1 bit to all 1 bits, etc). > We could have a special instruction in this instrumentation language with > which a skin can create any (arch-specific) instruction it wants by just > specifying the naked bytes, so skins could generate any instruction if > they really wanted (ie. make the common case easy, and the uncommon case > possible). Well, since we're planning to have one anyway to carry the client's instructions through, it will just be a matter of inserting those. J |
|
From: George S. <st...@kd...> - 2004-03-04 20:21:19
|
I was trying out valgrind on powerpc recently and while it works fine with
C applications, C++ apps seem to be giving it some serious problems. I
compiled helloworld.cpp, basically just 'cout << "Hello world." << endl;',
and when I run it through valgrind I get this assertion failure:
==20360== Reading syms from /lib/libc-2.2.5.so
==20360== Reading syms from /lib/libm-2.2.5.so
==20360== Reading syms from /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
valgrind: vg_symtab2.c:272 (addScopeRange): Assertion `range->size > 0'
failed.
==20360== at 0xFDC6694: ???
==20360== by 0xFDC670C: ???
==20360== by 0xFDD0B24: ???
==20360== by 0xFDD8268: ???
sched status:
Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==20360== at 0xFDF55CC: ???
==20360== by 0x3000B88C: ???
==20360== by 0x3000B974: ???
==20360== by 0x3001022C: ???
Enabling debug, I see this:
---------8<--------------
initSym name="bad_exc" type=r(0,39)=&(0,40)=xstype_info:
making (0,39) 0x30FEDB64 unresolved
defining type 0x30FEDB64 (0,39) = &(0,40)=xstype_info:
making (0,40) 0x30FEDB94 unresolved
defining type 0x30FEDB94 (0,40) = xstype_info:
created struct ref for type_info = 0x30FEDB94
parsed definition: type=0x30FEDB94 symtype=0x30FEDB94
parsed definition: type=0x30FEDB64 symtype=0x30FEDB64
adding = type=0x30FEDB64
47258 type=192 othr=0 desc=0 value=0x90 strx=0
{
adding (0x3103BCB9) bad_exc to scope 0x30FEDBEC depth 6
47259 type=192 othr=0 desc=0 value=0x90 strx=0
{
47260 type=192 othr=0 desc=0 value=0x9C strx=0
{
47261 type=64 othr=0 desc=300 value=0x1F strx=188320 i:r(0,1)
initSym name="i" type=r(0,1)
reference (0,1) -> 0x30FEC2B0
adding = type=0x30FEC2B0
47262 type=192 othr=0 desc=0 value=0x9C strx=0
{
adding (0x3103BCC1) i to scope 0x30FEDCF4 depth 9
47263 type=224 othr=0 desc=0 value=0xDC strx=0
}
47264 type=224 othr=0 desc=0 value=0xDC strx=0
}
47265 type=224 othr=0 desc=0 value=0xDC strx=0
}
47266 type=64 othr=0 desc=308 value=0x1F strx=188320 i:r(0,1)
initSym name="i" type=r(0,1)
reference (0,1) -> 0x30FEC2B0
adding = type=0x30FEC2B0
47267 type=192 othr=0 desc=0 value=0xE0 strx=0
{
adding (0x3103BCC3) i to scope 0x30FEDD1C depth 7
47268 type=192 othr=0 desc=0 value=0xF0 strx=0
{
47269 type=192 othr=0 desc=0 value=0xF0 strx=0
{
47270 type=192 othr=0 desc=0 value=0x10C strx=0
{
47271 type=192 othr=0 desc=0 value=0x10C strx=0
{
47272 type=192 othr=0 desc=0 value=0x10C strx=0
{
47273 type=192 othr=0 desc=0 value=0x10C strx=0
{
47274 type=224 othr=0 desc=0 value=0x10C strx=0
}
47275 type=224 othr=0 desc=0 value=0x10C strx=0
}
47276 type=192 othr=0 desc=0 value=0x10C strx=0
{
47277 type=224 othr=0 desc=0 value=0x10C strx=0
}
47278 type=192 othr=0 desc=0 value=0x10C strx=0
{
47279 type=192 othr=0 desc=0 value=0x10C strx=0
{
47280 type=224 othr=0 desc=0 value=0x10C strx=0
}
47281 type=224 othr=0 desc=0 value=0x10C strx=0
}
47282 type=224 othr=0 desc=0 value=0x10C strx=0
}
47283 type=192 othr=0 desc=0 value=0x11C strx=0
{
47284 type=192 othr=0 desc=0 value=0x11C strx=0
{
47285 type=224 othr=0 desc=0 value=0x11C strx=0
}
47286 type=192 othr=0 desc=0 value=0x128 strx=0
{
47287 type=192 othr=0 desc=0 value=0x128 strx=0
{
47288 type=224 othr=0 desc=0 value=0x128 strx=0
}
47289 type=224 othr=0 desc=0 value=0x128 strx=0
}
47290 type=224 othr=0 desc=0 value=0x128 strx=0
}
47291 type=192 othr=0 desc=0 value=0x12C strx=0
{
47292 type=192 othr=0 desc=0 value=0x12C strx=0
{
47293 type=224 othr=0 desc=0 value=0x12C strx=0
}
47294 type=192 othr=0 desc=0 value=0x12C strx=0
{
47295 type=192 othr=0 desc=0 value=0x12C strx=0
{
47296 type=224 othr=0 desc=0 value=0x12C strx=0
}
47297 type=224 othr=0 desc=0 value=0x12C strx=0
}
47298 type=224 othr=0 desc=0 value=0x12C strx=0
}
47299 type=224 othr=0 desc=0 value=0x158 strx=0
}
47300 type=224 othr=0 desc=0 value=0x158 strx=0
}
47301 type=224 othr=0 desc=0 value=0x158 strx=0
}
47302 type=224 othr=0 desc=0 value=0x164 strx=0
}
47303 type=224 othr=0 desc=0 value=0x168 strx=0
}
47304 type=224 othr=0 desc=0 value=0x168 strx=0
}
47305 type=224 othr=0 desc=0 value=0x16C strx=0
}
47306 type=224 othr=0 desc=0 value=0x16C strx=0
}
47307 type=224 othr=0 desc=0 value=0x8C strx=0
So the failure is at the outer most scope. The assert fails because
range->size = -0xe0. I'm not sure if it's a coincidence that
0x16c=0x8c+0xe0. Any ideas what could be going wrong here? I have tried
several C++ programs and they all trigger this, while I haven't found a
single C program that fails so far. GCC version is 2.95.4.
--
George Staikos
KDE Developer http://www.kde.org/
Staikos Computing Services Inc. http://www.staikos.net/
|
|
From: Josef W. <Jos...@gm...> - 2004-03-04 20:01:54
|
On Thursday 04 March 2004 20:36, Julian Seward wrote: > Fine by me, if it works for you. Can you run big stuff like OOo and > Mozilla on it? > > The list might want to comment further, though. Problem: latest Calltree release doesn't work with VG CVS at the moment, and thus, KCachegrind would be pretty useless in Suse 9.1. I have a working version here, but you have to provide "--pointercheck=no" on the command line because of client space checking in VG CVS. Another problem is that the API version number for Valgrind tools is only valid over stable Valgrind releases. Or can you package both stable and unstable versions, e.g. putting CVS version in a package "valgrind-unstable", using perhaps even different command names (valgrindunstable), so that one can have installed both versions simultaneously? Why is VG 2.0.x not working? Josef |
|
From: Julian S. <js...@ac...> - 2004-03-04 19:35:38
|
Fine by me, if it works for you. Can you run big stuff like OOo and Mozilla on it? The list might want to comment further, though. J On Thursday 04 March 2004 16:44, Stephan Kulow wrote: > Hi! > > We've got the usual problem, the latest stable valgrind > doesn't work on the latest glibc/kernel ;( > > Is it ok if we package a CVS version? > > Greetings, Stephan |
|
From: Nicholas N. <nj...@ca...> - 2004-03-04 18:12:16
|
CVS commit by nethercote:
Remove comma from last element of enum; C++ apparently doesn't allow it.
M +1 -1 memcheck.h 1.19
--- valgrind/memcheck/memcheck.h #1.18:1.19
@@ -93,5 +93,5 @@ typedef
/* This is just for memcheck's internal use - don't use it */
- _VG_USERREQ__MEMCHECK_GET_RECORD_OVERLAP = VG_USERREQ_SKIN_BASE('M','C')+256,
+ _VG_USERREQ__MEMCHECK_GET_RECORD_OVERLAP = VG_USERREQ_SKIN_BASE('M','C')+256
} Vg_MemCheckClientRequest;
|
|
From: Nicholas N. <nj...@ca...> - 2004-03-04 17:52:56
|
CVS commit by nethercote:
Remove mention of no-longer-existing Falgrind.
M +0 -5 related.html 1.14
--- devel-home/valgrind/related.html #1.13:1.14
@@ -79,9 +79,4 @@
Valgrind 1.0.3.
<p>
-<li>FreeBSD: sos22 tried porting Valgrind, but decided a rewrite would be
- simpler. The result was called Falgrind. Unfortunately, the page it was
- hosted on seems to have disappeared.
-<!--<a href="http://www.srcf.ucam.org/~sos22/falgrind.html">Falgrind</a>.-->
- <p>
</ul>
|
|
From: Nicholas N. <nj...@ca...> - 2004-03-04 13:53:40
|
On Thu, 4 Mar 2004, George Staikos wrote: > > Added news of Paul Mackerras's PowerPC port, and a link to it. > > You might want to add that it requires kernel 2.6 or above right now. With > 2.4 it asserts, crashes, or freezes. Is that right, Paul? I'll add a note if so. N |
|
From: Doug R. <df...@nl...> - 2004-03-04 10:19:25
|
On Wed, 2004-03-03 at 19:47, Julian Seward wrote: > On Wednesday 03 March 2004 19:29, Madhu M Kurup wrote: > > Doug Rabson <df...@nl...> said on March 3,2004: > > > On Wed, 2004-03-03 at 11:51, Nicholas Nethercote wrote: > > > > [Hmm... Doug -- would you be interested in doing the same with your > > > > x86/BSD patch?] > > > > > > My subversion tree is publically accessible. You can check out my > > > 'reasonably stable' tree (based on valgrind cvs from about 10th > > > January) with: > > > > I can second that. The FreeBSD port works well - there are a few edge > > cases ( zombie processes and getting stuck in poll loops), but mostly, > > it works perfectly. > > In that case, can one or the other of you use the autotest scripts in > nightly/ to run overnight tests, so we can monitor the status? > > For that matter, doing the same for the ppc port wouldn't be a bad > idea. I'll probably set this up fairly soon. |
|
From: Nicholas N. <nj...@ca...> - 2004-03-04 10:07:16
|
CVS commit by nethercote:
Whoops, fix HTML
M +9 -4 related.html 1.13
--- devel-home/valgrind/related.html #1.12:1.13
@@ -92,10 +92,15 @@
<p>
Some caveats:
-<ul>It only supports 32-bit instructions at present (no 64-bit instructions).
-<ul>It doesn't handle Altivec (SIMD) instructions.
-<ul>There are no PowerPC-specific suppression files yet, so libc.so and ld.so
+<ul>
+<li>It only supports 32-bit instructions at present (no 64-bit instructions).
+ <p>
+<li>It doesn't handle Altivec (SIMD) instructions.
+ <p>
+<li>There are no PowerPC-specific suppression files yet, so libc.so and ld.so
cause a lot of errors.
-<ul>The code to set cache parameters in cachegrind is pretty minimal at
+ <p>
+<li>The code to set cache parameters in cachegrind is pretty minimal at
present.
+ <p>
</ul>
<p>
|
|
From: Nicholas N. <nj...@ca...> - 2004-03-04 10:05:43
|
On Thu, 4 Mar 2004, Paul Mackerras wrote: > > But the "IrKnowledge" and "IrOpinions" pages show some of our > > current thinking; they are a distillation of several failed > > half-attempts to come up with a concrete design. > > Interesting. If we allow skins to extend the ucode then we will > inevitably have architecture-specific code in the skins. We could > import the ucode extensions from memcheck into the core and then not > allow skins to extend the ucode. That shouldn't be too bad since > skins can always use CCALL to do any funky stuff they need to do. > Memcheck is a bit of a special case since it is the "primary" skin and > because it is important that the valid bit computations are reasonably > fast. For that reason I wouldn't like to see all the tag computations > done as CCALLs. Some of them could be done with ordinary ucode > instructions (e.g. AND, OR) but some of them couldn't be done easily > and efficiently that way (e.g. Tag_PCast40). Our idea was to have a platform-independent language that skins in which skins would write their instrumentation. It would presumably look a lot like UCode. As for skin-specific UInstrs, we thought ditching them would be ok; Memcheck is the only one that uses them, and they're not really necessary -- even Tag_PCast40 is just a NEG, SBB, OR which is currently expressible in UCode. We could have a special instruction in this instrumentation language with which a skin can create any (arch-specific) instruction it wants by just specifying the naked bytes, so skins could generate any instruction if they really wanted (ie. make the common case easy, and the uncommon case possible). SIMD instructions and registers are a big complication. It seems that programs will increasingly use them in ways that normal integer registers are currently used, which will require having a sensible way to instrument them. > > So I'm personally not convinced the approach you've taken is the right > > way to go -- it might be acceptable for two architectures, but what > > happens when someone wants a SPARC port, or an ARM port, etc? > > Obviously there must be some architecture-specific bits (eg. asm > > disassembly and code-regeneration), but keeping those bits separate from > > the skins seems, to me, crucial. > > I agree that that is the direction to head. Valgrind is such a useful > tool though that I want to have something that is usable on PPC now, > without having to wait until we have worked out the exact right way to > do things. :) No problem -- I'm sure other PowerPC users will be happy you've done so :) And you've done a massively helpful thing by concretely identifying the x86-specific parts of Valgrind. > Good idea. I have put it at > > http://ozlabs.org/~paulus/valgrind-2.1.0-ppc.tar.bz2 > > This includes a fixes for a couple of bugs I found last night. Thanks. I've linked to this from valgrind.kde.org. Keep updating it if you make improvements (and the patch, too). Paul, are you subscribed to valgrind-developers? N |
|
From: Nicholas N. <nj...@ca...> - 2004-03-04 09:56:07
|
CVS commit by nethercote: Added news of Paul Mackerras's PowerPC port, and a link to it. M +3 -0 index.html 1.19 M +3 -0 news.html 1.2 M +14 -0 related.html 1.12 M +1 -1 users.html 1.53 --- devel-home/valgrind/index.html #1.18:1.19 @@ -5,4 +5,7 @@ ?> +<p class="news">March 04, 2004: An experimental PowerPC port is available. +See <a href="related.html">Related Projects</a>. + <p class="news">February 15, 2004: Valgrind CVS now includes Massif, a heap profiling tool. --- devel-home/valgrind/news.html #1.1:1.2 @@ -5,4 +5,7 @@ ?> +<p class="news">March 04, 2004: An experimental PowerPC port is available. +See <a href="related.html">Related Projects</a>. + <p class="news">February 15, 2004: Valgrind CVS now includes Massif, a heap profiling tool. --- devel-home/valgrind/related.html #1.11:1.12 @@ -87,4 +87,18 @@ +<h3>Ports to Other Architectures</h3> +Paul Mackerras has an experimental port of Valgrind 2.1.0 to PowerPC/Linux +(<a href="http://ozlabs.org/~paulus/valgrind-2.1.0-ppc.tar.bz2">download</a>). +<p> +Some caveats: +<ul>It only supports 32-bit instructions at present (no 64-bit instructions). +<ul>It doesn't handle Altivec (SIMD) instructions. +<ul>There are no PowerPC-specific suppression files yet, so libc.so and ld.so + cause a lot of errors. +<ul>The code to set cache parameters in cachegrind is pretty minimal at + present. +</ul> +<p> + <h3>Other</h3> The University of New Mexico's --- devel-home/valgrind/users.html #1.52:1.53 @@ -152,5 +152,5 @@ <dt><a href="http://www.coin3d.org/">Coin</a> -<dd>Multi-platform scene graph library for realtime 3D graphics. +<dd>A multi-platform scene graph library for realtime 3D graphics. <dt><a href="http://www.paraview.org/">ParaView</a> |
|
From: Tom H. <th...@cy...> - 2004-03-04 07:31:28
|
In message <164...@ca...>
Paul Mackerras <pa...@sa...> wrote:
> Nicholas Nethercote writes:
>
> > - Some big changes have been made ("full virtualization") since 2.1.0. I
> > don't know how much these changes would affect your patch.
>
> I'll check out the cvs repository on sourceforge.net and look at what
> has changed. I assume that sourceforge.net is the right place to go?
No - it was was moved to the KDE repository some time ago. Full
details of how to check it out are on the web site.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: <js...@ac...> - 2004-03-04 04:12:54
|
Nightly build on phoenix ( SuSE 8.2 ) started at 2004-03-04 04:00:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow resolv: valgrind ./resolv seg_override: valgrind ./seg_override sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 125 tests, 5 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) helgrind/tests/inherit (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: <js...@ac...> - 2004-03-04 03:55:56
|
Nightly build on nemesis ( SuSE 9.0 ) started at 2004-03-04 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 125 tests, 13 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/inherit (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-03-04 03:28:31
|
Nightly build on dunsmere ( Fedora Core 1 ) started at 2004-03-04 03:20:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow == 126 tests, 15 stderr failures, 1 stdout failure ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/inherit (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/fwrite (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-03-04 03:23:35
|
Nightly build on audi ( Red Hat 9 ) started at 2004-03-04 03:15:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow pth_blockedsig: valgrind ./pth_blockedsig rcl_assert: valgrind ./rcl_assert rcrl: valgrind ./rcrl readline1: valgrind ./readline1 resolv: valgrind ./resolv seg_override: valgrind ./seg_override sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 126 tests, 1 stderr failure, 0 stdout failures ================= helgrind/tests/inherit (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-03-04 03:18:41
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-03-04 03:10:01 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind ./seg_override sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 126 tests, 6 stderr failures, 0 stdout failures ================= helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/nanoleak (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-03-04 03:16:07
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-03-04 03:00:05 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow == 126 tests, 12 stderr failures, 5 stdout failures ================= corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/pth_atfork1 (stdout) corecheck/tests/pth_atfork1 (stderr) corecheck/tests/pth_cancel2 (stderr) corecheck/tests/pth_cvsimple (stdout) corecheck/tests/pth_cvsimple (stderr) corecheck/tests/pth_exit (stderr) corecheck/tests/res_search (stdout) helgrind/tests/inherit (stderr) memcheck/tests/badfree-2trace (stderr) memcheck/tests/execve (stderr) memcheck/tests/writev (stderr) none/tests/pth_blockedsig (stdout) none/tests/pth_blockedsig (stderr) none/tests/yield (stdout) none/tests/yield (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-03-04 03:13:36
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-03-04 03:05:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests ---------------------------------------- == 126 tests, 12 stderr failures, 3 stdout failures ================= corecheck/tests/fdleak_creat (stderr) corecheck/tests/pth_atfork1 (stdout) corecheck/tests/pth_atfork1 (stderr) corecheck/tests/res_search (stdout) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/badfree-2trace (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/mismatches (stderr) memcheck/tests/new_nothrow (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |