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
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(11) |
2
|
|
3
(5) |
4
(8) |
5
(33) |
6
(11) |
7
(1) |
8
(3) |
9
(4) |
|
10
(3) |
11
(12) |
12
(17) |
13
(10) |
14
(13) |
15
(7) |
16
|
|
17
(2) |
18
(22) |
19
(9) |
20
(7) |
21
(1) |
22
(4) |
23
(1) |
|
24
|
25
(1) |
26
(3) |
27
(8) |
28
(3) |
29
(16) |
30
(4) |
|
31
|
|
|
|
|
|
|
|
From: Olly B. <ol...@su...> - 2003-08-13 16:51:33
|
> A12. One possible cause is that your program modifies its
> environment variables, possibly including zeroing them
> all. Valgrind relies on the LD_PRELOAD and LD_LIBRARY_PATH
> variables, so zeroing them will break things.
I'm not certain I understand the mechanisms involved completely, but
would it work for valgrind to wrapper getenv, setenv, and putenv and
keep track of what the app thinks LD_PRELOAD and LD_LIBRARY_PATH (and
indeed VG_ARGS) are set to, but when making syscalls, actually use the
values set with the paths valgrind needs prepended?
Or simpler, just wrapper setenv and putenv and force valgrind's paths
in and prevent VG_ARGS from being changed, but I worry slightly that an
app might assume it knows how long a variable is because it just set it
- something like this rather stupid contrived example:
int foo(const char * value) {
char * p = malloc(strlen(value) + 10);
if (!p) return -1;
setenv("LD_PRELOAD", value, 1);
bar();
strcpy(p, getenv("LD_PRELOAD));
strcat(p, ":/usr/lib");
setenv("LD_PRELOAD", p, 1);
baz();
free(p);
return 0;
}
Cheers,
Olly
|
|
From: Nicholas N. <nj...@ca...> - 2003-08-13 16:07:51
|
On Wed, 13 Aug 2003, Vincent Penquerc'h wrote: > > Yes, that is a problem with such patches, unfortunately. > > Would it be accepted (or considered, at least) with configure > checks to only compile in this code (and include the files) if the > include files are actually found on the target system (eg, if the > files aren't there, then the new ioctls aren't supported, but they > are if the files are found) ? Um... maybe. (I'll let Julian have the final say on this one.) N |
|
From: Vincent Penquerc'h <Vin...@ar...> - 2003-08-13 15:48:03
|
> Yes, that is a problem with such patches, unfortunately. Would it be accepted (or considered, at least) with configure checks to only compile in this code (and include the files) if the include files are actually found on the target system (eg, if the files aren't there, then the new ioctls aren't supported, but they are if the files are found) ? -- Vincent Penquerc'h |
|
From: Nicholas N. <nj...@ca...> - 2003-08-13 10:21:14
|
On Wed, 13 Aug 2003, Santeri Paavolainen wrote: > So VG_ARGS needs to be added also. Ah, yes. I've updated the FAQ in CVS. Thanks for the help. N |
|
From: Santeri P. <sa...@ss...> - 2003-08-13 09:46:46
|
Nicholas Nethercote wrote:
>Yes: LD_PRELOAD and LD_LIBRARY_PATH, and only with --trace-children=yes.
>
>
Apparently this is not completely true.. I set up the program to pass
LD_PRELOAD and LD_LIBRARY_PATH from the parent process, and this is
visible in debug output too (from the child):
debug[6918]:
LD_PRELOAD=/l/beta/lib/valgrind/vgskin_memcheck.so:/l/beta/lib/valgrind/valgrind.so:
debug[6918]: LD_LIBRARY_PATH=/l/beta/lib/valgrind:
But:
valgrind.so: Startup or configuration error:
Can't read options from env var VG_ARGS.
valgrind.so: Unable to start up properly. Giving up.
So VG_ARGS needs to be added also. I added that to the list of passed
env variables, and so:
debug[7076]: VG_ARGS=
--suppressions=/l/beta/lib/valgrind/default.supp --trace-children=yes
--num-callers=32 --logfile=/l/xxtest/xxtest.log
And now everything works fine.
--
sa...@ss... I have no opinions, since I cannot express any, after all.
If you think you saw an opinion, contact your optometrist.
|
|
From: Nicholas N. <nj...@ca...> - 2003-08-13 09:36:35
|
On Wed, 13 Aug 2003, Vincent Penquerc'h wrote: > From the traffic on the list, it seems this patch suffers from > the same flaw as another one that stayed unapplied: addition of > include files which may or may not be present on the tgarget > system. Am I right in assuming this is the reason the patch was > not applied ? A quick answer would be nice, time permitting. Yes, that is a problem with such patches, unfortunately. N |
|
From: Vincent Penquerc'h <Vin...@ar...> - 2003-08-13 09:24:03
|
Hi, I posted message:
Message-ID: <B14C9D7F1977D111AD740060970ACBDA0189307D@warhol>
on the 30th of may 2003, and no answer was received. This patch
adds some ioctls and fixes some documentation (I'm unsure of the
actual extent of it, as I am not the patch author).
From the traffic on the list, it seems this patch suffers from
the same flaw as another one that stayed unapplied: addition of
include files which may or may not be present on the tgarget
system. Am I right in assuming this is the reason the patch was
not applied ? A quick answer would be nice, time permitting.
I can post the patches again if requested, if you can't find
the above message. Main text follows.
Thanks.
--
Vincent Penquerc'h
Hi,
This is from my girlfriend, who had been using Valgrind 1.0.4, and
ported some patches to 1.9.6.
--
Vincent Penquerc'h
Hi
I've been playing with valgrind (which is a very useful tool). I needed some
more ioctls, which I added (patch 'ioctls.diff' attached) and I've some
problems with signals.
IOCTLS:
I've added a tty, 2 sound, several frame buffer and VT ioctls.
These ioctls are very lightly tested : I've run programs which I know use
them
under valgrind, they worked and valgrind didn't complain.
I've also updated README_MISSING_SYSCALL_OR_IOCTL to use the new
SYSCAL_TRACK,
etc. instead of must_be_writable, etc.
SIGNALS:
From the manual (2.9 Handling of signals)
As specified by POSIX, a signal is blocked in its own handler.
From a comment at the beginning of coregrind/vg_signal.c
- A signal is not masked in its own handler. Neither are the
signals in the signal's blocking mask.
Which one is true ? (or which one is meant to be true ? ;)
There's a typical output of the program attached ('signals.c')
(run with valgrind -v --trace-signals=yes) :
... Skipping ...
[ 0] --28471-- signal 29 arrived ... queued
[ 1] --28471-- delivering signal 29 to thread 1
[ 2] --28471-- signal 29 arrived ... queued
[ 3] --28471-- signal 29 arrived ... already pending; discarded
[ 4] --28471-- signal 29 arrived ... already pending; discarded
[ 5] --28471-- signal 29 arrived ... already pending; discarded
[ 6] --28471-- signal 29 arrived ... already pending; discarded
[ 7] --28471-- signal 29 arrived ... already pending; discarded
[ 8] --28471-- signal 29 arrived ... already pending; discarded
[ 9] --28471-- signal 29 arrived ... already pending; discarded
[10] --28471-- signal 29 arrived ... already pending; discarded
[11] --28471-- signal 29 arrived ... already pending; discarded
[12] --28471-- signal 29 arrived ... already pending; discarded
[13] --28471-- signal 29 arrived ... already pending; discarded
[14] --28471-- signal 29 arrived ... already pending; discarded
[15] --28471-- signal 29 arrived ... already pending; discarded
[16] --28471-- signal 29 arrived ... already pending; discarded
[17] --28471-- signal 29 arrived ... already pending; discarded
[18] --28471-- signal 29 arrived ... already pending; discarded
[19] Entering: 1
[20] --28471-- delivering signal 29 to thread 1
[21] Entering: 2
[22] --28471-- signal 29 arrived ... queued
[23] --28471-- signal 29 arrived ... already pending; discarded
[24] --28471-- signal 29 arrived ... already pending; discarded
[25] Returning: 2
[26] --28471-- delivering signal 29 to thread 1
[27] Entering: 3
[28] Returning: 3
[29] --28471-- vg_pop_signal_frame (thread 1): valid magic
[30] --28471-- signal 29 arrived ... queued
[31] --28471-- vg_pop_signal_frame (thread 1): valid magic
[32] Returning: 1
[33] --28471-- delivering signal 29 to thread 1
[34] Entering: 2
[35] Returning: 2
[36] --28471-- vg_pop_signal_frame (thread 1): valid magic
[37] --28471-- vg_pop_signal_frame (thread 1): valid magic
... Skipping ...
As far as I understand, signals in lines #2, #22 and #30 should be
discarded.
I use Linux 2.4.13, gcc 2.95.3, libc 2.2.4, valgrind 1.9.6.
Note: signal 29 (SIGIO: I/O now possible) is non-POSIX, it comes from 4.2
BSD.
The example program was compiled with 'gcc -Wall signals.c'. You may want
to
change the MOUSE_DEVICE define at the beginning of the file if your mouse is
not in '/dev/mouse'. To test the program: run it and move the mouse, type
Ctrl-C to quit.
Thank you
--
Annie Testes
|
|
From: Nicholas N. <nj...@ca...> - 2003-08-13 08:48:50
|
On Wed, 13 Aug 2003, Santeri Paavolainen wrote:
> VG_(mash_LD_PRELOAD_and_LD_LIBRARY_PATH): internal error:
>
> This is clearly caused by the fact that this program clears the
> environmental variables on startup (to known values).
>
> What are the environmental variables that should be preserved (not
> cleared) to allow valgrind to work for the program and the child
> processes (with --trace-children=yes)? (My guess: LD_PRELOAD and
> LD_LIBRARY_PATH.)
Yes: LD_PRELOAD and LD_LIBRARY_PATH, and only with --trace-children=yes.
I updated the FAQ, it now reads:
A12. One possible cause is that your program modifies its
environment variables, possibly including zeroing them
all. Valgrind relies on the LD_PRELOAD and LD_LIBRARY_PATH
variables, so zeroing them will break things.
As of 1.9.6, Valgrind only uses these variables with
--trace-children=yes, which should reduce the potential for
problems.
N
|
|
From: Santeri P. <sa...@ss...> - 2003-08-13 07:46:07
|
When running valgrind on a program I get the following errors:
VG_(mash_LD_PRELOAD_and_LD_LIBRARY_PATH): internal error:
what = 0
ld_preload_str = `(null)'
ld_library_path_str = `(null)'
vg_prel = `(null)'
sk_prel = `(null)'
coredir2 = `(null)'
VG_LIBDIR = `/l/beta/lib'
This is clearly caused by the fact that this program clears the
environmental variables on startup (to known values).
What are the environmental variables that should be preserved (not
cleared) to allow valgrind to work for the program and the child
processes (with --trace-children=yes)? (My guess: LD_PRELOAD and
LD_LIBRARY_PATH.)
The FAQ entry 12 has some information:
Q12. My program dies like this (often at exit):
VG_(mash_LD_PRELOAD_and_LD_LIBRARY_PATH): internal error:
(loads of text)
A12. We're not entirely sure about this, and would appreciate
someone sending a simple test case for us to look at.
One possible cause is that your program modifies its
environment variables, possibly including zeroing them
all. Avoid this if you can.
1.9.6 contains a fix which hopefully reduces the chances
of your program bombing out like this.
Perhaps a list of not-to-be-cleared environmental variables should be
added to the FAQ?
--
sa...@ss... I have no opinions, since I cannot express any, after all.
If you think you saw an opinion, contact your optometrist.
|
|
From: Jeremy F. <je...@go...> - 2003-08-13 01:05:51
|
On Tue, 2003-08-12 at 15:42, Paul A. Clarke wrote:
> Does Valgrind support x86-64 executables?
No.
> I assume x86-32 executables on an x86-64 chip would be supported as
> normal.
Yes.
> (I couldn't find anything specific in the documentation, but I did check
> first! ;-)
>
> Also, has anyone even thought about a port (rewrite?) to the
> Power/PowerPC architecture?
Yes.
J
|