You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(5) |
2
(12) |
3
(2) |
|
4
(1) |
5
(3) |
6
(4) |
7
(9) |
8
(7) |
9
(3) |
10
(4) |
|
11
(3) |
12
(16) |
13
(9) |
14
(16) |
15
(7) |
16
|
17
|
|
18
(1) |
19
(1) |
20
(9) |
21
(4) |
22
(1) |
23
(6) |
24
|
|
25
|
26
(2) |
27
(8) |
28
(12) |
29
(14) |
30
(8) |
31
(2) |
|
From: Olly B. <ol...@su...> - 2003-05-14 15:38:22
|
On Wed, May 14, 2003 at 08:27:58AM -0700, Michael Labhard wrote: > I have been refused connection to the CVS repository with the command: > > cvs -d:pserver:ano...@cv...:/cvsroot/valgrind login > > entering <Enter>, or anonymous or <my-email> at the password prompt. > > How do I get the CVS files? The valgrind CVS is hosted at sourceforge.net, which tends to be overloaded at peak times - which usually seems to be during the US working day. I'm getting the same problem, and Richard Boulton mentioned it earlier. All I can suggest is to try later, and if it doesn't resolve itself, to report the problem to the sourceforge people. Cheers, Olly |
|
From: Michael L. <in...@pa...> - 2003-05-14 15:28:34
|
I have been refused connection to the CVS repository with the command: cvs -d:pserver:ano...@cv...:/cvsroot/valgrind login entering <Enter>, or anonymous or <my-email> at the password prompt. How do I get the CVS files? Thank you. -- Michael |
|
From: Crispin F. <cr...@th...> - 2003-05-14 13:08:22
|
On Wed, 2003-05-14 at 13:49, Richard Boulton wrote: > Wouldn't that result in confusing, or at least excessively repetitive, > output when the same leak is happening multiple times when called from > different places? Hmm I hadn't thought of that :) > How about changing the leak checker to compare the names up to the first > name in the stack trace that isn't in part of valgrind? This would > exclude the allocation functions quite neatly, which seems desirable. > Perhaps there are problems with this that I can't see, though. That seems like a pretty good solution, the slight problem however is that things such as strdup() aren't provided by valgrind, but will cause a malloc() to be performed, but the actual location of the leak is in the function above. (there may only be a small number of functions like that and these could possibly be special cased to go up another level). Crispin |
|
From: Nicholas N. <nj...@ca...> - 2003-05-14 13:01:40
|
On 14 May 2003, Richard Boulton wrote: > Incidentally, I was going to try putting a patch for this together, but > can't seem to update my checkout of valgrind CVS. In fact, I can't even > do the cvs login: > > $ cvs -d:pserver:ano...@cv...:/cvsroot/valgrind login > Logging in to :pserver:ano...@cv...:2401/cvsroot/valgrind > CVS password: > cvs [login aborted]: connect to cvs.sourceforge.net(66.35.250.207):2401 failed: Connection refused > > (just pressing return for the password) > > Is this just me and the lightning storms around here, or is it sourceforge? SourceForge does that sometimes, try again or wait a while. N |
|
From: Richard B. <ri...@ta...> - 2003-05-14 12:50:57
|
On Wed, 2003-05-14 at 11:33, Crispin Flowerday wrote: > Ahh, that explains it. Perhaps the leak-resolution should default to med > or high as the output was extremely confusing (much worse when you have > a large application and valgrind has merged 10 blocks into a single > stacktrace). Wouldn't that result in confusing, or at least excessively repetitive, output when the same leak is happening multiple times when called from different places? How about changing the leak checker to compare the names up to the first name in the stack trace that isn't in part of valgrind? This would exclude the allocation functions quite neatly, which seems desirable. Perhaps there are problems with this that I can't see, though. Incidentally, I was going to try putting a patch for this together, but can't seem to update my checkout of valgrind CVS. In fact, I can't even do the cvs login: $ cvs -d:pserver:ano...@cv...:/cvsroot/valgrind login Logging in to :pserver:ano...@cv...:2401/cvsroot/valgrind CVS password: cvs [login aborted]: connect to cvs.sourceforge.net(66.35.250.207):2401 failed: Connection refused (just pressing return for the password) Is this just me and the lightning storms around here, or is it sourceforge? -- Richard |
|
From: Olly B. <ol...@su...> - 2003-05-14 11:34:57
|
On Wed, May 14, 2003 at 08:41:06AM +0100, Nicholas Nethercote wrote:
> But first, just try "valgrind --leak-check=yes <program>", see how that
> works.
On a slightly tangential note, if your program is built using libtool
(as Michael's was, judging by the program name "src/.libs/lt-myapp") then
running the actual binary in .lib may not work. The most reliable way
to run it under valgrind would be:
libtool --mode=execute valgrind --leak-check=yes src/myapp
This lets libtool take care of any messing around with environmental
variables and the like that is required to get the program to run
before it has been installed.
The only wrinkle is that --mode=execute seems to have problems with
passing arguments to valgrind or the program in libtool 1.4.2 (you can
set VALGRIND_OPTS to pass options to valgrind). I've had no such
problems with libtool 1.5.
Cheers,
Olly
|
|
From: Crispin F. <cr...@th...> - 2003-05-14 10:35:03
|
> Ah; by default, the leak checker only compares the first two names in the > stack trace for the purposes of merging leak record. Try > --leak-resolution=med. > > (2.96 gave two leak records because it didn't have the "operator new[]" > line in the stack trace, so dostuff/dostuff1 made it into the first two > names.) Ahh, that explains it. Perhaps the leak-resolution should default to med or high as the output was extremely confusing (much worse when you have a large application and valgrind has merged 10 blocks into a single stacktrace). Cheers Crispin |
|
From: Nicholas N. <nj...@ca...> - 2003-05-14 10:19:22
|
On Wed, 14 May 2003, Nicholas Nethercote wrote: > > While attempting to locate all the memory in a program that wasn't > > freed, I came across an odd behaviour. [snip] > > (compiled with gcc 3.2.3 (debian unstable), using 'g++ main.cpp-o main' > > > > I get only 2 unreachable blocks, but both with the same stacktrace: > > > > 2048 bytes in 2 blocks are still reachable in loss record 1 of 1 > > at 0x4015D573: __builtin_vec_new (vg_clientfuncs.c:161) > > by 0x4015D5AE: operator new[](unsigned) (vg_clientfuncs.c:174) > > by 0x8048450: do_stuff() (in /home/crispin/src/tmp/main) > > by 0x8048470: main (in /home/crispin/src/tmp/main) > > > > Surely I should get 2 different stacktraces? > > I get the same with gcc 3.2.3. But with gcc 2.96 I get two stack traces. > Hmm, not sure... Ah; by default, the leak checker only compares the first two names in the stack trace for the purposes of merging leak record. Try --leak-resolution=med. (2.96 gave two leak records because it didn't have the "operator new[]" line in the stack trace, so dostuff/dostuff1 made it into the first two names.) N |
|
From: Bastien C. <ba...@ch...> - 2003-05-14 10:15:25
|
On Wednesday 14 May 2003 11:58, Crispin Flowerday wrote:
> No, I just get a longer stacktrace :)
Confirmed :-/ (with valgrind 1.9.5 and gcc3.3) Compiling with -g didn't help
either, it really shows the same line for both leaks. As no optimization
option is used for the compiler, I'd say that it's a bug. Now whether it's
the compiler or valgrind ...
Salut,
Bastien
--
-- The universe has its own cure for stupidity. --
-- Unfortunately, it doesn't always apply it. --
|
|
From: Nicholas N. <nj...@ca...> - 2003-05-14 10:09:32
|
On 14 May 2003, Crispin Flowerday wrote:
> While attempting to locate all the memory in a program that wasn't
> freed, I came across an odd behaviour.
>
> Using the following program:
>
> == START ==
>
> static char * bar = 0;
> static char * bar1 = 0;
>
> void do_stuff1()
> {
> bar = new char[1024];
> }
>
> void do_stuff()
> {
> bar1 = new char[1024];
> }
>
> int main( int argc, char ** argv )
> {
> do_stuff();
> do_stuff1();
> }
>
> == END ==
>
> (compiled with gcc 3.2.3 (debian unstable), using 'g++ main.cpp-o main'
>
> I get only 2 unreachable blocks, but both with the same stacktrace:
>
> 2048 bytes in 2 blocks are still reachable in loss record 1 of 1
> at 0x4015D573: __builtin_vec_new (vg_clientfuncs.c:161)
> by 0x4015D5AE: operator new[](unsigned) (vg_clientfuncs.c:174)
> by 0x8048450: do_stuff() (in /home/crispin/src/tmp/main)
> by 0x8048470: main (in /home/crispin/src/tmp/main)
>
> Surely I should get 2 different stacktraces?
I get the same with gcc 3.2.3. But with gcc 2.96 I get two stack traces.
Hmm, not sure...
N
|
|
From: Crispin F. <cr...@th...> - 2003-05-14 09:59:52
|
On Wed, 2003-05-14 at 10:45, Bastien Chevreux wrote: > On Wednesday 14 May 2003 11:37, Crispin Flowerday wrote: > > While attempting to locate all the memory in a program that wasn't > > freed, I came across an odd behaviour. > > [...] > > I get only 2 unreachable blocks, but both with the same stacktrace: > > Does using the --num-callers option help? No, I just get a longer stacktrace :) Crispin |
|
From: Bastien C. <ba...@ch...> - 2003-05-14 09:45:25
|
On Wednesday 14 May 2003 11:37, Crispin Flowerday wrote:
> While attempting to locate all the memory in a program that wasn't
> freed, I came across an odd behaviour.
> [...]
> I get only 2 unreachable blocks, but both with the same stacktrace:
Does using the --num-callers option help?
Salut,
Bastien
--
-- The universe has its own cure for stupidity. --
-- Unfortunately, it doesn't always apply it. --
|
|
From: Crispin F. <cr...@th...> - 2003-05-14 09:39:00
|
Hi,
While attempting to locate all the memory in a program that wasn't
freed, I came across an odd behaviour.
Using the following program:
== START ==
static char * bar = 0;
static char * bar1 = 0;
void do_stuff1()
{
bar = new char[1024];
}
void do_stuff()
{
bar1 = new char[1024];
}
int main( int argc, char ** argv )
{
do_stuff();
do_stuff1();
}
== END ==
(compiled with gcc 3.2.3 (debian unstable), using 'g++ main.cpp-o main'
I get only 2 unreachable blocks, but both with the same stacktrace:
2048 bytes in 2 blocks are still reachable in loss record 1 of 1
at 0x4015D573: __builtin_vec_new (vg_clientfuncs.c:161)
by 0x4015D5AE: operator new[](unsigned) (vg_clientfuncs.c:174)
by 0x8048450: do_stuff() (in /home/crispin/src/tmp/main)
by 0x8048470: main (in /home/crispin/src/tmp/main)
Surely I should get 2 different stacktraces?
Cheers
|
|
From: Nicholas N. <nj...@ca...> - 2003-05-14 07:41:10
|
On Tue, 13 May 2003, Michael Labhard wrote: > I am at a loss as to how to use valgrind. I have read the manual and a > howto. Using this command > > export GLIBCPP_FORCE_NEW=1; > valgrind > --skin=memcheck Memcheck is the default skin, so this flag is unnecessary > --leak-check=yes > --show-reachable=yes Don't use --show-reachable=yes and you won't the the "still reachable in loss record" messages below; they're not so important, they show memory that your program could have freed (it's still reachable via some pointer) but didn't bother to. > --logfile=debug.out > --suppressions=xfree-3.supp > --suppressions=xfree-4.supp --suppressions=default.supp --suppressions=glibc-2.2.supp default.supp is used as the default suppression file so you don't need to specify it. It's constructed at ./configure time from the relevant xfree/glibc/linux .supp files, so you don't need to mentiont them either. > src/.libs/lt-myapp > > My application produces hundreds of lines looking like > > ==26316== 216 bytes in 21 blocks are still reachable in loss record 77 of 124 > ==26316== at 0x40160989: malloc (in /usr/lib/valgrind/valgrind.so) > ==26316== by 0x40B33B2F: __GI___strdup (in /lib/libc-2.3.1.so) > ==26316== by 0x40F5C37A: resolve_object (in /usr/X11R6/lib/libX11.so.6.2) > ==26316== by 0x40F5BF7C: _XlcDynamicLoad (in /usr/X11R6/lib/libX11.so.6.2) > ==26316== > > What do I do with this stuff? It looks like it comes from an X11 library but > the command line includes suppressions for X11. Why isn't X11 output > suppressed? Where do I get a suppressions file for Qt? If you look in any of the .supp files, you'll see many suppressions for individual errors. These have been added as they were encountered. They should cover most X11 errors people get, but we may have missed some, or your machine might have an unusual configuration that means some errors are getting through. You can write your own suppressions; the manual currently doesn't explain how to very well, it would be easier to check out the CVS HEAD (from sourceforge.net) and use the --gen-suppressions feature to automatically generate suppressions (the feature isn't in 1.9.6). But first, just try "valgrind --leak-check=yes <program>", see how that works. N |
|
From: Michael L. <in...@pa...> - 2003-05-14 02:37:31
|
I am at a loss as to how to use valgrind. I have read the manual and a h= owto. =20 Using this command=20 export GLIBCPP_FORCE_NEW=3D1; valgrind --skin=3Dmemcheck --leak-check=3Dy= es=20 --show-reachable=3Dyes --logfile=3Ddebug.out --suppressions=3Dxfree-3.sup= p=20 --suppressions=3Dxfree-4.supp --suppressions=3Ddefault.supp=20 --suppressions=3Dglibc-2.2.supp src/.libs/lt-myapp My application produces hundreds of lines looking like =3D=3D26316=3D=3D 216 bytes in 21 blocks are still reachable in loss reco= rd 77 of 124 =3D=3D26316=3D=3D at 0x40160989: malloc (in /usr/lib/valgrind/valgrind= =2Eso) =3D=3D26316=3D=3D by 0x40B33B2F: __GI___strdup (in /lib/libc-2.3.1.so) =3D=3D26316=3D=3D by 0x40F5C37A: resolve_object (in /usr/X11R6/lib/lib= X11.so.6.2) =3D=3D26316=3D=3D by 0x40F5BF7C: _XlcDynamicLoad (in /usr/X11R6/lib/li= bX11.so.6.2) =3D=3D26316=3D=3D=20 What do I do with this stuff? It looks like it comes from an X11 library= but=20 the command line includes suppressions for X11. Why isn't X11 output=20 suppressed? Where do I get a suppressions file for Qt? Thanks. -- Michael |
|
From: Jeremy F. <je...@go...> - 2003-05-13 17:02:38
|
On Tue, 2003-05-13 at 07:26, Nicholas Nethercote wrote: > On Tue, 13 May 2003 gt...@ma... wrote: > > > I get the below error when trying to use Helgrind on VTK based applications > > (www.vtk.org). > > > blockSane: fail -- redzone-hi > > mallocSanityCheckArena: sb 0x4238A000, block 3007 (bszW 10): BAD > > Looks like Helgrind has a heap-block overrun (how embarassing). Thanks > for the report. Very. David, I don't suppose you have a smaller test case to reproduce this? J |
|
From: Nicholas N. <nj...@ca...> - 2003-05-13 14:37:41
|
Hi, This is slightly off-topic but since I discovered it when hacking Valgrind it's worth a shot: I find that when the poll() system call is made, sometimes the value of %ebx (which holds the 1st argument) changes, being increased by 8. A sample call: poll ( 0x804A6C0, 0, 0 ) (which returns 0) doesn't change %ebx. But another call: poll ( 0xBFFFF310, 1, 0 ) does. No other syscall I've seen changes any of its argument (and I've checked it on some pretty big programs). I have a patched 2.4.19-3 kernel. Any ideas? N |
|
From: Nicholas N. <nj...@ca...> - 2003-05-13 14:26:44
|
On Tue, 13 May 2003 gt...@ma... wrote: > I get the below error when trying to use Helgrind on VTK based applications > (www.vtk.org). > blockSane: fail -- redzone-hi > mallocSanityCheckArena: sb 0x4238A000, block 3007 (bszW 10): BAD Looks like Helgrind has a heap-block overrun (how embarassing). Thanks for the report. N |
|
From: <gt...@ma...> - 2003-05-13 14:01:38
|
I get the below error when trying to use Helgrind on VTK based applicatio= ns (www.vtk.org). When the sanity-level is at the default, Valgrind seg-fau= lts without any warning or other output. This happens very early in the exec= ution of the program. $ valgrind --skin=3Dhelgrind --sanity-level=3D5 ./ParaView =3D=3D22474=3D=3D Helgrind, a data race detector for x86-linux. =3D=3D22474=3D=3D Copyright (C) 2002, and GNU GPL'd, by Nicholas Netherco= te. =3D=3D22474=3D=3D Using valgrind-1.9.6, a program instrumentation system = for x86-linux. =3D=3D22474=3D=3D Copyright (C) 2000-2002, and GNU GPL'd, by Julian Sewar= d. =3D=3D22474=3D=3D Estimated CPU clock rate is 1994 MHz =3D=3D22474=3D=3D For more details, rerun with: -v =3D=3D22474=3D=3D --22474-- mSC [core ]: 1 sbs, 197 tot bs, 1/1 free bs, 16 lis= ts, 1048576 mmap, 7324 loan --22474-- mSC [skin ]: 1 sbs, 52 tot bs, 1/1 free bs, 16 lis= ts, 1048576 mmap, 1212 loan --22474-- mSC [symtab ]: 0 sbs, 0 tot bs, 0/0 free bs, 16 lis= ts, =20 0 mmap, 0 loan --22474-- mSC [JITter ]: 0 sbs, 0 tot bs, 0/0 free bs, 16 lis= ts, =20 0 mmap, 0 loan --22474-- mSC [client ]: 0 sbs, 0 tot bs, 0/0 free bs, 16 lis= ts, =20 0 mmap, 0 loan --22474-- mSC [demangle]: 0 sbs, 0 tot bs, 0/0 free bs, 16 lis= ts, =20 0 mmap, 0 loan --22474-- mSC [exectxt ]: 0 sbs, 0 tot bs, 0/0 free bs, 16 lis= ts, =20 0 mmap, 0 loan --22474-- mSC [errors ]: 0 sbs, 0 tot bs, 0/0 free bs, 16 lis= ts, =20 0 mmap, 0 loan --22474-- mSC [transien]: 0 sbs, 0 tot bs, 0/0 free bs, 16 lis= ts, =20 0 mmap, 0 loan blockSane: fail -- redzone-hi mallocSanityCheckArena: sb 0x4238A000, block 3007 (bszW 10): BAD valgrind: the `impossible' happened: mallocSanityCheckArena Basic block ctr is approximately 50000 sched status: Thread 1: status =3D Runnable, associated_mx =3D 0x0, associated_cv =3D 0= x0 =3D=3D22474=3D=3D at 0x4000F85E: strcmp (in /lib/ld-2.2.5.so) =3D=3D22474=3D=3D by 0x4000B0A5: fixup (in /lib/ld-2.2.5.so) =3D=3D22474=3D=3D by 0x4000B22F: _dl_runtime_resolve (in /lib/ld-2.2.5= .so) =3D=3D22474=3D=3D by 0x41E0BEC8: (within /extra/paraview/ParaViewComplete06/lib/libvtkexpat.so) When run using the Memcheck skin, the program runs fine. The first error reported (which appears to later in the programs execuation) is: =3D=3D22494=3D=3D pthread_attr_setscope: invalid or unsupported scope =3D=3D22494=3D=3D at 0x40215CFF: pthread_error (vg_libpthread.c:290) =3D=3D22494=3D=3D by 0x40215E86: pthread_attr_setscope (vg_libpthread.= c:410) =3D=3D22494=3D=3D by 0x420CF2A5: vtkMultiThreader::SingleMethodExecute= (void) (in /extra/paraview/ParaViewCompe06/lib/libvtkCommon.so) =3D=3D22494=3D=3D by 0x41F399E5: vtkImageToImageFilter::MultiThread(vt= kImageData *, vtkImageData *) (in /extraraview/ParaViewComplete06/lib/libvtkFiltering.s= o) Valgrind version 1.9.6 stable release on Red Hat Linux 7.2 (?), kernel 2.= 4.18-3. David Bauer |
|
From: Olly B. <ol...@su...> - 2003-05-13 11:28:30
|
On Tue, May 13, 2003 at 11:16:47AM -0000, dev...@op... wrote: > Hi! This is the ezmlm program. I'm managing the > de...@op... mailing list. > > Acknowledgment: The address > > val...@li... > > was not on the dev mailing list when I received > your request and is not a subscriber of this list. Hmm, I've been getting double posts for the openoffice.org messages, which from the headers appear to be coming from the de...@op... mailing list via the valgrind-users list, but the valgrind-users list isn't subscribed to de...@op.... Did someone else beat me to unsubscribing it? Or is something more peculiar happening? Whatever is going on, it's annoying to get double posts so it'd be good if it got fixed... Cheers, Olly |
|
From: <dev...@op...> - 2003-05-13 11:16:52
|
Hi! This is the ezmlm program. I'm managing the
de...@op... mailing list.
Acknowledgment: The address
val...@li...
was not on the dev mailing list when I received
your request and is not a subscriber of this list.
If you unsubscribe, but continue to receive mail, you're subscribed
under a different address than you currently use. Please look at the
header for:
'Return-Path: <dev-return-1234-user=hos...@op...>'
The unsubscribe address for this user would be:
'dev-unsubscribe-user=hos...@op...'.
Just mail to that address, substituting user=host.dom for the real
values, reply to the confirmation request, and you should receive a message
that you're off the list.
For some mail programs, you need to make the headers visible to
see the return path:
For Eudora 4.0, click on the "Blah blah ..." button.
For PMMail, click on "Window->Show entire message/header".
If this still doesn't work, I'm sorry to say that I can't help you.
Please FORWARD a list message together with a note about what you're
trying to achieve and a list of addresses that you might be subscribed
under to my owner:
dev...@op...
who will take care of it. My owner is a little bit slower than I am,
so please be patient.
--- Administrative commands for the dev list ---
I can handle administrative requests automatically. Please
do not send them to the list address! Instead, send
your message to the correct command address:
To subscribe to the list, send a message to:
<dev...@op...>
To remove your address from the list, send a message to:
<dev...@op...>
Send mail to the following for info and FAQ for this list:
<dev...@op...>
<de...@op...>
Similar addresses exist for the digest list:
<dev...@op...>
<dev...@op...>
To get messages 123 through 145 (a maximum of 100 per request), mail:
<dev...@op...>
To get an index with subject and author for messages 123-456 , mail:
<dev...@op...>
They are always returned as sets of 100, max 2000 per request,
so you'll actually get 100-499.
To receive all messages with the same subject as message 12345,
send an empty message to:
<dev...@op...>
The messages do not really need to be empty, but I will ignore
their content. Only the ADDRESS you send to is important.
You can start a subscription for an alternate address,
for example "jo...@ho...main", just add a hyphen and your
address (with '=' instead of '@') after the command word:
<dev-subscribe-john=hos...@op...>
To stop subscription for this address, mail:
<dev-unsubscribe-john=hos...@op...>
In both cases, I'll send a confirmation message to that address. When
you receive it, simply reply to it to complete your subscription.
If despite following these instructions, you do not get the
desired results, please contact my owner at
dev...@op.... Please be patient, my owner is a
lot slower than I am ;-)
--- Enclosed is a copy of the request I received.
Return-Path: <ol...@su...>
Received: (qmail 25829 invoked from network); 13 May 2003 11:16:46 -0000
Received: from ixion.tartarus.org (195.149.39.210)
by s002.sfo.collab.net with SMTP; 13 May 2003 11:16:46 -0000
Received: from olly by ixion.tartarus.org with local (Exim 3.35 #1 (Debian))
id 19FXm1-0005da-00; Tue, 13 May 2003 12:16:45 +0100
Date: Tue, 13 May 2003 12:16:45 +0100
From: Olly Betts <ol...@su...>
To: dev-uc.1052824302.elkplmkaambcampcbpbm-valgrind-users=lis...@op...
Subject: Re: [Valgrind-users] confirm unsubscribe from de...@op...
Message-ID: <200...@su...>
References: <105...@op...>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <105...@op...>
User-Agent: Mutt/1.3.28i
Thanks.
|
|
From: <dev...@op...> - 2003-05-13 11:11:48
|
Hi! This is the ezmlm program. I'm managing the de...@op... mailing list. To confirm that you would like val...@li... removed from the dev mailing list, please send an empty reply to this address: dev-uc.1052824302.elkplmkaambcampcbpbm-valgrind-users=lis...@op... Usually, this happens when you just hit the "reply" button. If this does not work, simply copy the address and paste it into the "To:" field of a new message. I haven't checked whether your address is currently on the mailing list. To see what address you used to subscribe, look at the messages you are receiving from the mailing list. Each message has your address hidden inside its return path; for example, ma...@xd... receives messages with return path: <dev-return-<number>-mary=xdd...@op.... Some mail programs are broken and cannot handle long addresses. If you cannot reply to this request, instead send a message to <dev...@op...> and put the entire address listed above into the "Subject:" line. --- Administrative commands for the dev list --- I can handle administrative requests automatically. Please do not send them to the list address! Instead, send your message to the correct command address: To subscribe to the list, send a message to: <dev...@op...> To remove your address from the list, send a message to: <dev...@op...> Send mail to the following for info and FAQ for this list: <dev...@op...> <de...@op...> Similar addresses exist for the digest list: <dev...@op...> <dev...@op...> To get messages 123 through 145 (a maximum of 100 per request), mail: <dev...@op...> To get an index with subject and author for messages 123-456 , mail: <dev...@op...> They are always returned as sets of 100, max 2000 per request, so you'll actually get 100-499. To receive all messages with the same subject as message 12345, send an empty message to: <dev...@op...> The messages do not really need to be empty, but I will ignore their content. Only the ADDRESS you send to is important. You can start a subscription for an alternate address, for example "jo...@ho...main", just add a hyphen and your address (with '=' instead of '@') after the command word: <dev-subscribe-john=hos...@op...> To stop subscription for this address, mail: <dev-unsubscribe-john=hos...@op...> In both cases, I'll send a confirmation message to that address. When you receive it, simply reply to it to complete your subscription. If despite following these instructions, you do not get the desired results, please contact my owner at dev...@op.... Please be patient, my owner is a lot slower than I am ;-) --- Enclosed is a copy of the request I received. Return-Path: <ol...@su...> Received: (qmail 23755 invoked from network); 13 May 2003 11:11:42 -0000 Received: from ixion.tartarus.org (195.149.39.210) by s002.sfo.collab.net with SMTP; 13 May 2003 11:11:42 -0000 Received: from olly by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 19FXh7-0004QA-00; Tue, 13 May 2003 12:11:41 +0100 Date: Tue, 13 May 2003 12:11:41 +0100 From: Olly Betts <ol...@su...> To: dev-unsubscribe-valgrind-users=lis...@op... Subject: Please unsubscribe the valgrind-users mailing list Message-ID: <200...@su...> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i |
|
From: Nicholas N. <nj...@ca...> - 2003-05-13 07:44:52
|
On Mon, 12 May 2003, Seto wrote:
> Has anyone been using Valgrind successfully with his/her
> own memory management or maybe has some ideas on what
> should people do when using Valgrind with their own memory
> management, so Valgrind will report useful memory information?
It will still work, but give less information. The validity checks will
be fine. The addressability checks will be less accurate, because your
allocator might allocate superblocks and then dole out small blocks from
within that; so small-block-overruns probably wouldn't be found. Some
other errors you obviously won't get (eg. mismatched malloc/new/new[] vs.
free/delete/delete[], accessing blocks after free()ing them). Memory leak
checking (--leak-check) also won't be any use as it's based around
recording malloc/new/new[] blocks. Also, error locations will be less
accurate, as errors within your non-malloc'd blocks won't be identified as
such.
----
Hmm... some client requests could be useful here. For example:
VALGRIND_MALLOCLIKE_BLOCK(mallocname, addr, rz1, size, rz2)
VALGRIND_FREELIKE_BLOCK(freename, addr, rz1, rz2)
The first would tell Valgrind that the block at 'addr' of size 'size' is a
malloc-like block and should be recorded as such, the second should be
obvious. You could use it like this:
void* my_alloc(int size)
{
void* p = <get memory block somehow>;
VALGRIND_MALLOCLIKE_BLOCK("my_alloc", p, 0, size, 0);
return p;
}
void* my_free(void* p)
{
<free p's memory somehow>
VALGRIND_FREELIKE_BLOCK("my_free", p, 0, 0)
}
By introducing a new alloc type 'AllocOther' to complement the existing
'AllocMalloc', 'AllocNew', 'AllocVecNew', error messages could be made to
say things like:
error blah blah
at 0x...
by 0x...
Address 0x12345678 is within a block of size 100 my_alloc'd
at 0x...
by 0x...
This would allow error checking to be almost as good as it is for malloc
et al (superblocks could be marked inaccessible at first with the
VALGRIND_MARK_NOACCESS request). The only shortcomings would be:
1. redzones -- Valgrind's malloc pads heap blocks with redzones to help
detect overruns and underruns; the 'rz1' and 'rz2' args above would
allow a custom allocator to use them if it could. The rz1 and rz2 args
would have to match in VALGRIND_MALLOCLIKE_BLOCK and
VALGRIND_FREELIKE_BLOCK.
2. accesses to freed memory -- Valgrind's allocator deliberately postpones
the reuse of freed blocks to help catch any accesses after their free.
A custom allocator could also do this, although it wouldn't be
necessary.
This seems quite neat and doable to me -- it would fit in fairly easily
with the heap-block-tracking Valgrind already has. I'll put it on my "to
consider" list... if anyone else would find this useful, speak up, and
that will increase the likelihood of it being implemented.
N
|
|
From: Dan K. <da...@ke...> - 2003-05-13 04:28:39
|
Julian Seward wrote: > Attached is a patch which allows you to change stdin to whatever > you like, if you thing V is closing it. I tried the new --gdb-command= option, setting it to a shell script containing DISPLAY=x.y.z.w:0.0 xterm -e gdb "$@" and it worked nicely. I'll try the other option next. I've already posted an interesting stack dump to de...@op... using this. +1 for getting this into the upcoming release of valgrind! Thanks, Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |
|
From: Seto <Wun...@sy...> - 2003-05-12 23:13:53
|
Hi, Has anyone been using Valgrind successfully with his/her own memory management or maybe has some ideas on what should people do when using Valgrind with their own memory management, so Valgrind will report useful memory information? -Seto |