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
(20) |
2
(19) |
3
(7) |
|
4
(13) |
5
(24) |
6
(9) |
7
(12) |
8
(8) |
9
(34) |
10
(28) |
|
11
(20) |
12
(23) |
13
(12) |
14
(10) |
15
(15) |
16
(24) |
17
(26) |
|
18
(17) |
19
(14) |
20
(14) |
21
(8) |
22
(12) |
23
(22) |
24
(10) |
|
25
(21) |
26
(21) |
27
(18) |
28
(8) |
29
(13) |
30
(15) |
|
|
From: Nicholas N. <nj...@cs...> - 2007-11-17 23:58:50
|
On Sat, 17 Nov 2007, Julian Seward wrote:
>> weidendo@linux:~> echo %q{foo}
>> %q{foo}
>> weidendo@linux:~> echo %q(foo)
>> bash: syntax error near unexpected token `('
>> weidendo@linux:~>
>
> That's in bash. In csh:
>
> > echo %q{foo}
> %qfoo
> > echo %q(foo)
> Badly placed ()'s.
>
> So in csh both are borked, but ( ) is more borked than { }.
>
> Can I change my vote back to { } please?
Another possibility: %qVAR
N
|
|
From: <sv...@va...> - 2007-11-17 23:00:44
|
Author: sewardj
Date: 2007-11-17 23:00:47 +0000 (Sat, 17 Nov 2007)
New Revision: 7178
Log:
Add regtest for the --child-silent-after-fork added in r7177.
Added:
trunk/memcheck/tests/noisy_child.c
trunk/memcheck/tests/noisy_child.stderr.exp
trunk/memcheck/tests/noisy_child.stdout.exp
trunk/memcheck/tests/noisy_child.vgtest
Modified:
trunk/memcheck/tests/Makefile.am
Modified: trunk/memcheck/tests/Makefile.am
===================================================================
--- trunk/memcheck/tests/Makefile.am 2007-11-17 22:29:25 UTC (rev 7177)
+++ trunk/memcheck/tests/Makefile.am 2007-11-17 23:00:47 UTC (rev 7178)
@@ -86,6 +86,7 @@
nanoleak2.stderr.exp nanoleak2.vgtest \
new_nothrow.stderr.exp new_nothrow.vgtest \
new_override.stderr.exp new_override.stdout.exp new_override.vgtest \
+ noisy_child.vgtest noisy_child.stderr.exp noisy_child.stdout.exp \
null_socket.stderr.exp null_socket.vgtest \
overlap.stderr.exp overlap.stdout.exp overlap.vgtest \
oset_test.stderr.exp oset_test.stdout.exp oset_test.vgtest \
@@ -160,6 +161,7 @@
match-overrun \
memalign_test memalign2 memcmptest mempool mmaptest \
nanoleak nanoleak2 new_nothrow \
+ noisy_child \
null_socket oset_test overlap \
partiallydefinedeq \
partial_load pdb-realloc pdb-realloc2 \
Added: trunk/memcheck/tests/noisy_child.c
===================================================================
--- trunk/memcheck/tests/noisy_child.c (rev 0)
+++ trunk/memcheck/tests/noisy_child.c 2007-11-17 23:00:47 UTC (rev 7178)
@@ -0,0 +1,42 @@
+
+#include <stdlib.h>
+#include <sys/types.h>
+#include <unistd.h>
+#include <assert.h>
+
+void do_child_badness ( char* p )
+{
+ /* Free it a second time */
+ free(p);
+}
+
+void do_parent_badness ( char* p )
+{
+ /* Do a write off the end */
+ p[10] = 42;
+}
+
+
+int main ( void )
+{
+ pid_t child;
+ char* p = malloc(10); assert(p);
+ free(p);
+
+ /* parent does something bad */
+ p[5] = 22;
+
+ child = fork();
+ assert(child != -1); /* assert fork did not fail */
+
+ if (child == 0) {
+ /* I am the child */
+ do_child_badness(p);
+ } else {
+ /* I am the parent */
+ do_parent_badness(p);
+ }
+
+ return 0;
+
+}
Added: trunk/memcheck/tests/noisy_child.stderr.exp
===================================================================
--- trunk/memcheck/tests/noisy_child.stderr.exp (rev 0)
+++ trunk/memcheck/tests/noisy_child.stderr.exp 2007-11-17 23:00:47 UTC (rev 7178)
@@ -0,0 +1,19 @@
+
+Invalid write of size 1
+ at 0x........: main (noisy_child.c:27)
+ Address 0x........ is 5 bytes inside a block of size 10 free'd
+ at 0x........: free (vg_replace_malloc.c:...)
+ by 0x........: main (noisy_child.c:24)
+
+Invalid write of size 1
+ at 0x........: do_parent_badness (noisy_child.c:16)
+ by 0x........: main (noisy_child.c:37)
+ Address 0x........ is 0 bytes after a block of size 10 free'd
+ at 0x........: free (vg_replace_malloc.c:...)
+ by 0x........: main (noisy_child.c:24)
+
+ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
+malloc/free: in use at exit: 0 bytes in 0 blocks.
+malloc/free: 1 allocs, 1 frees, 10 bytes allocated.
+For a detailed leak analysis, rerun with: --leak-check=yes
+For counts of detected errors, rerun with: -v
Added: trunk/memcheck/tests/noisy_child.stdout.exp
===================================================================
Added: trunk/memcheck/tests/noisy_child.vgtest
===================================================================
--- trunk/memcheck/tests/noisy_child.vgtest (rev 0)
+++ trunk/memcheck/tests/noisy_child.vgtest 2007-11-17 23:00:47 UTC (rev 7178)
@@ -0,0 +1,2 @@
+prog: noisy_child
+vgopts: --child-silent-after-fork=yes
|
|
From: <sv...@va...> - 2007-11-17 22:29:23
|
Author: sewardj
Date: 2007-11-17 22:29:25 +0000 (Sat, 17 Nov 2007)
New Revision: 7177
Log:
Add a new flag, --child-silent-after-fork=no|yes [no]. When enabled,
causes child processes after fork to fall completely silent, which can
make the output a lot less confusing. In addition it is pretty much
essential in XML output mode, so as to avoid mixing up any child XML
output with the parent's.
Modified:
trunk/coregrind/m_libcprint.c
trunk/coregrind/m_main.c
trunk/coregrind/m_options.c
trunk/coregrind/m_syswrap/syswrap-aix5.c
trunk/coregrind/m_syswrap/syswrap-generic.c
trunk/coregrind/m_syswrap/syswrap-linux.c
trunk/coregrind/pub_core_options.h
Modified: trunk/coregrind/m_libcprint.c
===================================================================
--- trunk/coregrind/m_libcprint.c 2007-11-17 21:31:48 UTC (rev 7176)
+++ trunk/coregrind/m_libcprint.c 2007-11-17 22:29:25 UTC (rev 7177)
@@ -53,7 +53,12 @@
static void send_bytes_to_logging_sink ( Char* msg, Int nbytes )
{
if (!VG_(logging_to_socket)) {
- VG_(write)( VG_(clo_log_fd), msg, nbytes );
+ /* VG_(clo_log_fd) could have been set to -1 in the various
+ sys-wrappers for sys_fork, if --child-silent-after-fork=yes
+ is in effect. That is a signal that we should not produce
+ any more output. */
+ if (VG_(clo_log_fd) >= 0)
+ VG_(write)( VG_(clo_log_fd), msg, nbytes );
} else {
Int rc = VG_(write_socket)( VG_(clo_log_fd), msg, nbytes );
if (rc == -1) {
Modified: trunk/coregrind/m_main.c
===================================================================
--- trunk/coregrind/m_main.c 2007-11-17 21:31:48 UTC (rev 7176)
+++ trunk/coregrind/m_main.c 2007-11-17 22:29:25 UTC (rev 7177)
@@ -114,7 +114,8 @@
" --version show version\n"
" -q --quiet run silently; only print error msgs\n"
" -v --verbose be more verbose, incl counts of errors\n"
-" --trace-children=no|yes Valgrind-ise child processes? [no]\n"
+" --trace-children=no|yes Valgrind-ise child processes (follow execve)? [no]\n"
+" --child-silent-after-fork=no|yes omit child output between fork & exec? [no]\n"
" --track-fds=no|yes track open file descriptors? [no]\n"
" --time-stamp=no|yes add timestamps to log messages? [no]\n"
" --log-fd=<number> log messages to file descriptor [2=stderr]\n"
@@ -370,6 +371,8 @@
else VG_BOOL_CLO(arg, "--time-stamp", VG_(clo_time_stamp))
else VG_BOOL_CLO(arg, "--track-fds", VG_(clo_track_fds))
else VG_BOOL_CLO(arg, "--trace-children", VG_(clo_trace_children))
+ else VG_BOOL_CLO(arg, "--child-silent-after-fork",
+ VG_(clo_child_silent_after_fork))
else VG_BOOL_CLO(arg, "--trace-sched", VG_(clo_trace_sched))
else VG_BOOL_CLO(arg, "--trace-signals", VG_(clo_trace_signals))
else VG_BOOL_CLO(arg, "--trace-symtab", VG_(clo_trace_symtab))
Modified: trunk/coregrind/m_options.c
===================================================================
--- trunk/coregrind/m_options.c 2007-11-17 21:31:48 UTC (rev 7176)
+++ trunk/coregrind/m_options.c 2007-11-17 22:29:25 UTC (rev 7177)
@@ -50,7 +50,8 @@
HChar* VG_(clo_xml_user_comment) = NULL;
Bool VG_(clo_demangle) = True;
Bool VG_(clo_trace_children) = False;
-Int VG_(clo_log_fd) = 2;
+Bool VG_(clo_child_silent_after_fork) = False;
+Int VG_(clo_log_fd) = 2; /* must be signed, as -1 is possible. */
Char* VG_(clo_log_name) = NULL;
Char* VG_(clo_log_file_qualifier) = NULL;
Bool VG_(clo_time_stamp) = False;
Modified: trunk/coregrind/m_syswrap/syswrap-aix5.c
===================================================================
--- trunk/coregrind/m_syswrap/syswrap-aix5.c 2007-11-17 21:31:48 UTC (rev 7176)
+++ trunk/coregrind/m_syswrap/syswrap-aix5.c 2007-11-17 22:29:25 UTC (rev 7177)
@@ -1321,13 +1321,22 @@
SET_STATUS_from_SysRes( VG_(do_syscall0)(__NR_fork) );
if (SUCCESS && RES == 0) {
+ /* child */
VG_(do_atfork_child)(tid);
/* restore signal mask */
VG_(sigprocmask)(VKI_SIG_SETMASK, &fork_saved_mask, NULL);
+
+ /* If --child-silent-after-fork=yes was specified, set the
+ logging file descriptor to an 'impossible' value. This is
+ noticed by send_bytes_to_logging_sink in m_libcprint.c, which
+ duly stops writing any further logging output. */
+ if (!VG_(logging_to_socket) && VG_(clo_child_silent_after_fork))
+ VG_(clo_log_fd) = -1;
}
else
if (SUCCESS && RES > 0) {
+ /* parent */
PRINT(" fork: process %d created child %d\n", VG_(getpid)(), RES);
/* restore signal mask */
Modified: trunk/coregrind/m_syswrap/syswrap-generic.c
===================================================================
--- trunk/coregrind/m_syswrap/syswrap-generic.c 2007-11-17 21:31:48 UTC (rev 7176)
+++ trunk/coregrind/m_syswrap/syswrap-generic.c 2007-11-17 22:29:25 UTC (rev 7177)
@@ -2895,13 +2895,22 @@
SET_STATUS_from_SysRes( VG_(do_syscall0)(__NR_fork) );
if (SUCCESS && RES == 0) {
+ /* child */
VG_(do_atfork_child)(tid);
/* restore signal mask */
VG_(sigprocmask)(VKI_SIG_SETMASK, &fork_saved_mask, NULL);
+
+ /* If --child-silent-after-fork=yes was specified, set the
+ logging file descriptor to an 'impossible' value. This is
+ noticed by send_bytes_to_logging_sink in m_libcprint.c, which
+ duly stops writing any further logging output. */
+ if (!VG_(logging_to_socket) && VG_(clo_child_silent_after_fork))
+ VG_(clo_log_fd) = -1;
}
else
if (SUCCESS && RES > 0) {
+ /* parent */
PRINT(" fork: process %d created child %d\n", VG_(getpid)(), RES);
/* restore signal mask */
Modified: trunk/coregrind/m_syswrap/syswrap-linux.c
===================================================================
--- trunk/coregrind/m_syswrap/syswrap-linux.c 2007-11-17 21:31:48 UTC (rev 7176)
+++ trunk/coregrind/m_syswrap/syswrap-linux.c 2007-11-17 22:29:25 UTC (rev 7177)
@@ -333,6 +333,13 @@
/* restore signal mask */
VG_(sigprocmask)(VKI_SIG_SETMASK, &fork_saved_mask, NULL);
+
+ /* If --child-silent-after-fork=yes was specified, set the
+ logging file descriptor to an 'impossible' value. This is
+ noticed by send_bytes_to_logging_sink in m_libcprint.c, which
+ duly stops writing any further logging output. */
+ if (!VG_(logging_to_socket) && VG_(clo_child_silent_after_fork))
+ VG_(clo_log_fd) = -1;
}
else
if (!res.isError && res.res > 0) {
Modified: trunk/coregrind/pub_core_options.h
===================================================================
--- trunk/coregrind/pub_core_options.h 2007-11-17 21:31:48 UTC (rev 7176)
+++ trunk/coregrind/pub_core_options.h 2007-11-17 22:29:25 UTC (rev 7177)
@@ -61,6 +61,12 @@
extern Bool VG_(clo_demangle);
/* Simulate child processes? default: NO */
extern Bool VG_(clo_trace_children);
+/* After a fork, the child's output can become confusingly
+ intermingled with the parent's output. This is especially
+ problematic when VG_(clo_xml) is True. Setting
+ VG_(clo_child_silent_after_fork) causes children to fall silent
+ after fork() calls. */
+extern Bool VG_(clo_child_silent_after_fork);
/* Where logging output is to be sent to.
|
|
From: <sv...@va...> - 2007-11-17 21:31:45
|
Author: sewardj
Date: 2007-11-17 21:31:48 +0000 (Sat, 17 Nov 2007)
New Revision: 7176
Log:
Don't pollute the XML output if the program terminates with a signal,
and for a couple of other minor warnings.
Modified:
trunk/coregrind/m_signals.c
Modified: trunk/coregrind/m_signals.c
===================================================================
--- trunk/coregrind/m_signals.c 2007-11-17 21:11:57 UTC (rev 7175)
+++ trunk/coregrind/m_signals.c 2007-11-17 21:31:48 UTC (rev 7176)
@@ -822,7 +822,7 @@
return VG_(mk_SysRes_Success)( 0 );
bad_signo:
- if (VG_(showing_core_errors)()) {
+ if (VG_(showing_core_errors)() && !VG_(clo_xml)) {
VG_(message)(Vg_UserMsg,
"Warning: bad signal number %d in sigaction()",
signo);
@@ -830,7 +830,7 @@
return VG_(mk_SysRes_Error)( VKI_EINVAL );
bad_signo_reserved:
- if (VG_(showing_core_errors)()) {
+ if (VG_(showing_core_errors)() && !VG_(clo_xml)) {
VG_(message)(Vg_UserMsg,
"Warning: ignored attempt to set %s handler in sigaction();",
signame(signo));
@@ -841,7 +841,7 @@
return VG_(mk_SysRes_Error)( VKI_EINVAL );
bad_sigkill_or_sigstop:
- if (VG_(showing_core_errors)()) {
+ if (VG_(showing_core_errors)() && !VG_(clo_xml)) {
VG_(message)(Vg_UserMsg,
"Warning: ignored attempt to set %s handler in sigaction();",
signame(signo));
@@ -1206,7 +1206,8 @@
core = False;
}
- if (VG_(clo_verbosity) > 1 || (could_core && info->si_code > VKI_SI_USER)) {
+ if ( (VG_(clo_verbosity) > 1 || (could_core && info->si_code > VKI_SI_USER))
+ && !VG_(clo_xml) ) {
VG_(message)(Vg_UserMsg, "");
VG_(message)(Vg_UserMsg,
"Process terminating with default action of signal %d (%s)%s",
|
|
From: <sv...@va...> - 2007-11-17 21:11:57
|
Author: sewardj
Date: 2007-11-17 21:11:57 +0000 (Sat, 17 Nov 2007)
New Revision: 7175
Log:
Make handling of setuid executables marginally more sensible, as
suggested in #119404.
Prior to this commit, if the current traced process attempted to
execve a setuid executable, an error was always returned. The revised
behaviour is:
If the current (traced) process attempts to execve a setuid
executable:
* If --trace-children=yes is not in effect, the execve is allowed.
* If --trace-children=yes is in effect, the execve is disallowed
(as at present), but an error message is printed (unless in XML mode),
so at least the execve does not fail silently any more.
As per discussion on #119404 we could probably do a lot better, but
these changes are at least simple, useful and uncontroversial.
Modified:
trunk/coregrind/m_libcfile.c
trunk/coregrind/m_syswrap/syswrap-generic.c
trunk/coregrind/m_ume.c
trunk/coregrind/pub_core_libcfile.h
trunk/coregrind/pub_core_ume.h
Modified: trunk/coregrind/m_libcfile.c
===================================================================
--- trunk/coregrind/m_libcfile.c 2007-11-17 18:35:54 UTC (rev 7174)
+++ trunk/coregrind/m_libcfile.c 2007-11-17 21:11:57 UTC (rev 7175)
@@ -332,12 +332,21 @@
if group matches, then use the group permissions, else
use other permissions.
- Note that we can't deal with SUID/SGID, so we refuse to run them
- (otherwise the executable may misbehave if it doesn't have the
- permissions it thinks it does).
+ Note that we can't deal properly with SUID/SGID. By default
+ (allow_setuid == False), we refuse to run them (otherwise the
+ executable may misbehave if it doesn't have the permissions it
+ thinks it does). However, the caller may indicate that setuid
+ executables are allowed, for example if we are going to exec them
+ but not trace into them (iow, client sys_execve when
+ clo_trace_children == False).
+
+ If VKI_EACCES is returned (iow, permission was refused), then
+ *is_setuid is set to True iff permission was refused because the
+ executable is setuid.
*/
/* returns: 0 = success, non-0 is failure */
-Int VG_(check_executable)(HChar* f)
+Int VG_(check_executable)(/*OUT*/Bool* is_setuid,
+ HChar* f, Bool allow_setuid)
{
/* This is something of a kludge. Really we should fix VG_(stat) to
do this itself, but not clear how to do it as it depends on
@@ -351,12 +360,16 @@
SysRes res = VG_(stat)(f, &st);
# endif
+ if (is_setuid)
+ *is_setuid = False;
+
if (res.isError) {
return res.err;
}
- if (st.st_mode & (VKI_S_ISUID | VKI_S_ISGID)) {
- /* VG_(printf)("Can't execute suid/sgid executable %s\n", exe); */
+ if ( (st.st_mode & (VKI_S_ISUID | VKI_S_ISGID)) && !allow_setuid ) {
+ if (is_setuid)
+ *is_setuid = True;
return VKI_EACCES;
}
Modified: trunk/coregrind/m_syswrap/syswrap-generic.c
===================================================================
--- trunk/coregrind/m_syswrap/syswrap-generic.c 2007-11-17 18:35:54 UTC (rev 7174)
+++ trunk/coregrind/m_syswrap/syswrap-generic.c 2007-11-17 21:11:57 UTC (rev 7175)
@@ -2361,6 +2361,7 @@
ThreadState* tst;
Int i, j, tot_args;
SysRes res;
+ Bool setuid_allowed;
PRINT("sys_execve ( %p(%s), %p, %p )", ARG1, ARG1, ARG2, ARG3);
PRE_REG_READ3(vki_off_t, "execve",
@@ -2388,8 +2389,10 @@
}
// Do the important checks: it is a file, is executable, permissions are
- // ok, etc.
- res = VG_(pre_exec_check)((const Char*)ARG1, NULL);
+ // ok, etc. We allow setuid executables to run only in the case when
+ // we are not simulating them, that is, they to be run natively.
+ setuid_allowed = VG_(clo_trace_children) ? False : True;
+ res = VG_(pre_exec_check)((const Char*)ARG1, NULL, setuid_allowed);
if (res.isError) {
SET_STATUS_Failure( res.err );
return;
Modified: trunk/coregrind/m_ume.c
===================================================================
--- trunk/coregrind/m_ume.c 2007-11-17 18:35:54 UTC (rev 7174)
+++ trunk/coregrind/m_ume.c 2007-11-17 21:11:57 UTC (rev 7175)
@@ -45,6 +45,7 @@
#include "pub_core_libcassert.h" // VG_(exit), vg_assert
#include "pub_core_mallocfree.h" // VG_(malloc), VG_(free)
#include "pub_core_syscall.h" // VG_(strerror)
+#include "pub_core_options.h" // VG_(clo_xml)
#include "pub_core_ume.h" // self
/* --- !!! --- EXTERNAL HEADERS start --- !!! --- */
@@ -636,12 +637,14 @@
} ExeFormat;
// Check the file looks executable.
-SysRes VG_(pre_exec_check)(const HChar* exe_name, Int* out_fd)
+SysRes
+VG_(pre_exec_check)(const HChar* exe_name, Int* out_fd, Bool allow_setuid)
{
Int fd, ret;
SysRes res;
Char buf[4096];
SizeT bufsz = 4096, fsz;
+ Bool is_setuid = False;
// Check it's readable
res = VG_(open)(exe_name, VKI_O_RDONLY, 0);
@@ -651,9 +654,18 @@
fd = res.res;
// Check we have execute permissions
- ret = VG_(check_executable)((HChar*)exe_name);
+ ret = VG_(check_executable)(&is_setuid, (HChar*)exe_name, allow_setuid);
if (0 != ret) {
VG_(close)(fd);
+ if (is_setuid && !VG_(clo_xml)) {
+ VG_(message)(Vg_UserMsg, "");
+ VG_(message)(Vg_UserMsg,
+ "Warning: Can't execute setuid/setgid executable: %s",
+ exe_name);
+ VG_(message)(Vg_UserMsg, "Possible workaround: remove "
+ "--trace-children=yes, if in effect");
+ VG_(message)(Vg_UserMsg, "");
+ }
return VG_(mk_SysRes_Error)(ret);
}
@@ -697,7 +709,7 @@
Int fd;
Int ret;
- res = VG_(pre_exec_check)(exe, &fd);
+ res = VG_(pre_exec_check)(exe, &fd, False/*allow_setuid*/);
if (res.isError)
return res.err;
@@ -800,7 +812,8 @@
VG_(printf)("valgrind: %s: is a directory\n", exe_name);
// Was it not executable?
- } else if (0 != VG_(check_executable)(exe_name)) {
+ } else if (0 != VG_(check_executable)(NULL, exe_name,
+ False/*allow_setuid*/)) {
VG_(printf)("valgrind: %s: %s\n", exe_name, VG_(strerror)(ret));
// Did it start with "#!"? If so, it must have been a bad interpreter.
Modified: trunk/coregrind/pub_core_libcfile.h
===================================================================
--- trunk/coregrind/pub_core_libcfile.h 2007-11-17 18:35:54 UTC (rev 7174)
+++ trunk/coregrind/pub_core_libcfile.h 2007-11-17 21:11:57 UTC (rev 7175)
@@ -71,7 +71,8 @@
extern Int VG_(access) ( HChar* path, Bool irusr, Bool iwusr, Bool ixusr );
/* Is the file executable? Returns: 0 = success, non-0 is failure */
-extern Int VG_(check_executable)(HChar* f);
+extern Int VG_(check_executable)(/*OUT*/Bool* is_setuid,
+ HChar* f, Bool allow_setuid);
extern SysRes VG_(pread) ( Int fd, void* buf, Int count, Int offset );
Modified: trunk/coregrind/pub_core_ume.h
===================================================================
--- trunk/coregrind/pub_core_ume.h 2007-11-17 18:35:54 UTC (rev 7174)
+++ trunk/coregrind/pub_core_ume.h 2007-11-17 21:11:57 UTC (rev 7175)
@@ -69,7 +69,8 @@
// the kernel: ie. it's a file, it's readable and executable, and it's in
// either ELF or "#!" format. On success, 'out_fd' gets the fd of the file
// if it's non-NULL. Otherwise the fd is closed.
-extern SysRes VG_(pre_exec_check)(const HChar* exe_name, Int* out_fd);
+extern SysRes VG_(pre_exec_check)(const HChar* exe_name, Int* out_fd,
+ Bool allow_setuid);
// Does everything short of actually running 'exe': finds the file,
// checks execute permissions, sets up interpreter if program is a script,
|
|
From: Florian K. <br...@ac...> - 2007-11-17 19:09:57
|
On Saturday 17 November 2007 9:40 am, Bart Van Assche wrote: > A new drd version is available at the following location: > http://home.euphonynet.be/bvassche/valgrind/valgrind-7173-drd-2007-11-17.pa >tch.gz > I got the following compiler error with gcc 3.3.5 and glibc 2.3.2: drd_preloaded.c: In function `vg_set_main_thread_state': drd_preloaded.c:165: error: `pthread_spinlock_t' undeclared (first use in this function) I had to add #define _XOPEN_SOURCE 600 or #define -GNU_SOURCE to get it to compile. Cheers, Florian |
|
From: Julian S. <js...@ac...> - 2007-11-17 18:41:42
|
> Hmm.. Is ( and ) really better?
Hmm .. no. It seems like the evidence is not in my favour :-)
> weidendo@linux:~> echo %q{foo}
> %q{foo}
> weidendo@linux:~> echo %q(foo)
> bash: syntax error near unexpected token `('
> weidendo@linux:~>
That's in bash. In csh:
> echo %q{foo}
%qfoo
> echo %q(foo)
Badly placed ()'s.
So in csh both are borked, but ( ) is more borked than { }.
Can I change my vote back to { } please?
J
|
|
From: Julian S. <js...@ac...> - 2007-11-17 18:37:33
|
On Saturday 17 November 2007 13:51, Bart Van Assche wrote: > I propose to use the prefix exp_ instead of exp-. My motivation is as > follows: * The rule all-local from the top-level Makefile.am (which > installs tool executable and redirections into the .in_place directory) > fails for tools which have a hyphen in their name. > * The core fails to load the file <cpu>-<os>/vgpreload_<tool name>.so > when the tool name contains a hypen. I just fixed the build system for in-place runs to handle this case. (r7174). J |
|
From: <sv...@va...> - 2007-11-17 18:35:51
|
Author: sewardj
Date: 2007-11-17 18:35:54 +0000 (Sat, 17 Nov 2007)
New Revision: 7174
Log:
Makefile.tool-inplace.am: correctly handle tool names with dashes in,
using same changes to magic sed scripts as were recently applied to
Makefile.install.am.
Modified:
trunk/Makefile.install.am
trunk/Makefile.tool-inplace.am
Modified: trunk/Makefile.install.am
===================================================================
--- trunk/Makefile.install.am 2007-11-17 09:43:25 UTC (rev 7173)
+++ trunk/Makefile.install.am 2007-11-17 18:35:54 UTC (rev 7174)
@@ -9,6 +9,8 @@
# and not in
# $prefix/lib/valgrind/omega-x86-linux/exp
# or similarly mutant place.
+#
+# Note there is identical sed magic in Makefile.tool-inplace.am.
# What the second for loop does: it copies libcoregrind.a and libvex.a
# into the correct (target-specific) lib dirs at install time.
Modified: trunk/Makefile.tool-inplace.am
===================================================================
--- trunk/Makefile.tool-inplace.am 2007-11-17 09:43:25 UTC (rev 7173)
+++ trunk/Makefile.tool-inplace.am 2007-11-17 18:35:54 UTC (rev 7174)
@@ -1,8 +1,14 @@
+
+# For a description of what these magic sed commands do, see comments
+# in Makefile.install.am (which has identical magic)
+
all-local:
- for f in $(noinst_PROGRAMS); do \
- p=`echo $$f | sed -e 's/^[^-]*-//' -e 's/\..*$$//'`; \
- n=`echo $$f | sed -e 's/-[^-]\{1,\}-[^-.]\{1,\}//'`; \
- mkdir -p $(inplacedir)/$$p; \
- rm -f $(inplacedir)/$$p/$$n; \
- ln -f -s ../../$(subdir)/$$f $(inplacedir)/$$p/$$n; \
- done
+ if [ -n "$(noinst_PROGRAMS)" ] ; then \
+ for f in $(noinst_PROGRAMS); do \
+ name=`echo $$f | sed -e 's/-\([^-]*-[^-.]*\)\(\..*\)\?$$/\2/'`; \
+ plat=`echo $$f | sed -e 's/^.*-\([^-]*-[^-.]*\)\(\..*\)\?$$/\1/'`; \
+ mkdir -p $(inplacedir)/$$plat; \
+ rm -f $(inplacedir)/$$plat/$$name; \
+ ln -f -s ../../$(subdir)/$$f $(inplacedir)/$$plat/$$name; \
+ done ; \
+ fi
|
|
From: Bart V. A. <bar...@gm...> - 2007-11-17 14:40:18
|
A new drd version is available at the following location: http://home.euphonynet.be/bvassche/valgrind/valgrind-7173-drd-2007-11-17.patch.gz Changes compared to version 2007-11-11: - Renamed the tool drd into exp_drd. - Moved the suppression file from the drd-directory to the top-level directory. - 'make install' now correctly installs drd's suppression file. - Moved the client requests for obtainging Valgrind's thread ID and setting the thread name from the core to drd. - Removed several small core changes that were not necessary for drd's operation. - fp_race regression test now also succeeds on AMD-64. - Added some missing files for the pth_detached2 regression test. Most important known bugs: - drd is soon killed by the OOM handler when started with bigger clients. - drd/default.supp has to be installed manually in the installation dir. You can apply this patch with the following commands: cd valgrind zcat ../valgrind-7146-drd-2007-11-11.patch.gz | patch -p0 chmod a+x exp_drd/tests/filter* |
|
From: Josef W. <Jos...@gm...> - 2007-11-17 14:22:30
|
On Saturday 17 November 2007, Julian Seward wrote:
> I would prefer to use ( ) instead of { } around VAR. { and }
> interact really badly with shells and are generally a pain to
> work with.
Hmm.. Is ( and ) really better?
weidendo@linux:~> echo %q{foo}
%q{foo}
weidendo@linux:~> echo %q(foo)
bash: syntax error near unexpected token `('
weidendo@linux:~>
But I do not really have any preference.
Josef
>
> J
>
|
|
From: Bart V. A. <bar...@gm...> - 2007-11-17 12:51:39
|
On Oct 5, 2007 1:50 AM, Nicholas Nethercote <nj...@cs...> wrote: > > Julian and I have been discussing for a while the idea of creating a > category of "experimental" tools in the Valgrind source tree. These > would be tools that are not necessarily mature, but may be of interest > to people. This would make it much easier for users to try out > experimental tools -- they would be included in the Valgrind distribution -- > which in turn might accelerate their development. > > The core Valgrind developers would maintain experimental tools at the > minimum level of keeping them compiling, eg. if the core/tool > interface changes, as it does occasionally. But each tool would have > to have a nominated maintainer who would be reponsible for responding to bug > reports, feature requests, and who would continue development. > > These tools would be given an "exp-" prefix to their name to indicate > their experimental nature, and they would be marked clearly as experimental > on the website and in the manual. Experimental tools could lose the "exp-" > prefix once they reached a certain level of maturity and popularity. > The tools would have to be licensed as GPLv2-or-later, like the rest of > Valgrind. I propose to use the prefix exp_ instead of exp-. My motivation is as follows: * The rule all-local from the top-level Makefile.am (which installs tool executable and redirections into the .in_place directory) fails for tools which have a hyphen in their name. * The core fails to load the file <cpu>-<os>/vgpreload_<tool name>.so when the tool name contains a hypen. I found out the above by trying to use the name exp-drd for my data race detection tool, which did not work. All regression tests passed however after I switched to the name exp_drd. Bart. |
|
From: <sv...@va...> - 2007-11-17 09:43:24
|
Author: sewardj
Date: 2007-11-17 09:43:25 +0000 (Sat, 17 Nov 2007)
New Revision: 7173
Log:
Spelling fixes and misc tidying for the manual. (Brian Gough)
Modified:
trunk/callgrind/docs/cl-format.xml
trunk/callgrind/docs/cl-manual.xml
trunk/docs/xml/FAQ.xml
trunk/docs/xml/manual-core.xml
trunk/docs/xml/manual-intro.xml
trunk/docs/xml/valgrind-manpage.xml
trunk/helgrind/docs/hg-manual.xml
trunk/massif/docs/ms-manual.xml
trunk/memcheck/docs/mc-manual.xml
trunk/memcheck/docs/mc-tech-docs.xml
Modified: trunk/callgrind/docs/cl-format.xml
===================================================================
--- trunk/callgrind/docs/cl-format.xml 2007-11-17 02:46:42 UTC (rev 7172)
+++ trunk/callgrind/docs/cl-format.xml 2007-11-17 09:43:25 UTC (rev 7173)
@@ -73,7 +73,7 @@
<para>Thus, the first cost line specifies that in line 15 of source file
"file.f" there is code belonging to function "main". While running, 90 CPU
cycles passed by, and 2 of the 14 instructions executed were floating point
-operations. Similarily, the next line specifies that there were 12 instructions
+operations. Similarly, the next line specifies that there were 12 instructions
executed in the context of function "main" which can be related to line 16 in
file "file.f", taking 20 CPU cycles. If a cost line specifies less event counts
than given in the "events" line, the rest is assumed to be zero. I.e., there
@@ -93,8 +93,8 @@
<para>The most important extension to the original format of Cachegrind is the
ability to specify call relationship among functions. More generally, you
-specify assoziations among positions. For this, the second part of the
-file also can contain assoziation specifications. These look similar to
+specify associations among positions. For this, the second part of the
+file also can contain association specifications. These look similar to
position specifications, but consist of 2 lines. For calls, the format
looks like
<screen>
@@ -109,7 +109,7 @@
source file. The 2nd line looks like a regular cost line with the difference
that inclusive cost spent inside of the function call has to be specified.</para>
-<para>Other assoziations which or for example (conditional) jumps. See the
+<para>Other associations which or for example (conditional) jumps. See the
reference below for details.</para>
</sect2>
@@ -198,7 +198,7 @@
fn=(3)
20 700</screen></para>
-<para>As position specifications carry no information themself, but only change
+<para>As position specifications carry no information themselves, but only change
the meaning of subsequent cost lines or associations, they can appear
everywhere in the file without any negative consequence. Especially, you can
define name compression mappings directly after the header, and before any cost
@@ -225,7 +225,7 @@
<title>Subposition Compression</title>
<para>If a Callgrind data file should hold costs for each assembler instruction
-of a program, you specify subpostion "instr" in the "positions:" header line,
+of a program, you specify subposition "instr" in the "positions:" header line,
and each cost line has to include the address of some instruction. Addresses
are allowed to have a size of 64bit to support 64bit architectures. Thus,
repeating similar, long addresses for almost every line in the data file can
@@ -239,7 +239,7 @@
of the last cost line, and starts with a "+" to specify a positive difference,
a "-" to specify a negative difference, or consists of "*" to specify the same
subposition. Because absolute subpositions always are positive (ie. never
-prefixed by "-"), any relative specification is non-ambigous; additionally,
+prefixed by "-"), any relative specification is non-ambiguous; additionally,
absolute and relative subposition specifications can be mixed freely.
Assume the following example (subpositions can always be specified
as hexadecimal numbers, beginning with "0x"):
@@ -292,7 +292,7 @@
<screen>event: Ir : Instruction Fetches
events: Ir Dr</screen></para>
-<para>In this example, "Dr" itself has no long name assoziated. The order of
+<para>In this example, "Dr" itself has no long name associated. The order of
"event:" lines and the "events:" line is of no importance. Additionally,
inherited event types can be introduced for which no raw data is available, but
which are calculated from given types. Suppose the last example, you could add
@@ -339,7 +339,7 @@
| ('#' NoNewLineChar*)
| CostLine
| PositionSpecification
- | AssoziationSpecification</screen>
+ | AssociationSpecification</screen>
<screen>CostLine := SubPositionList Costs?</screen>
<screen>SubPositionList := (SubPosition+ Space+)+</screen>
<screen>SubPosition := Number | "+" Number | "-" Number | "*"</screen>
@@ -349,7 +349,7 @@
<screen>CostPosition := "ob" | "fl" | "fi" | "fe" | "fn"</screen>
<screen>CalledPosition := " "cob" | "cfl" | "cfn"</screen>
<screen>PositionName := ( "(" Number ")" )? (Space* NoNewLineChar* )?</screen>
-<screen>AssoziationSpecification := CallSpezification
+<screen>AssociationSpecification := CallSpecification
| JumpSpecification</screen>
<screen>CallSpecification := CallLine "\n" CostLine</screen>
<screen>CallLine := "calls=" Space* Number Space+ SubPositionList</screen>
@@ -433,7 +433,7 @@
</listitem>
<listitem>
- <para><computeroutput>events: event type abbrevations</computeroutput> [Cachegrind]</para>
+ <para><computeroutput>events: event type abbreviations</computeroutput> [Cachegrind]</para>
<para>A list of short names of the event types logged in this file.
The order is the same as in cost lines. The first event type is the
second or third number in a cost line, depending on the value of
Modified: trunk/callgrind/docs/cl-manual.xml
===================================================================
--- trunk/callgrind/docs/cl-manual.xml 2007-11-17 02:46:42 UTC (rev 7172)
+++ trunk/callgrind/docs/cl-manual.xml 2007-11-17 09:43:25 UTC (rev 7173)
@@ -283,7 +283,7 @@
and <option><xref linkend="opt.dump-after"/>=funcprefix</option>.
To zero cost counters before entering a function, use
<option><xref linkend="opt.zero-before"/>=funcprefix</option>.
- The prefix method for specifying function names was choosen to
+ The prefix method for specifying function names was chosen to
ease the use with C++: you don't have to specify full
signatures.</para> <para>You can specify these options multiple
times for different function prefixes.</para>
@@ -412,10 +412,10 @@
cut off uninteresting areas.</para>
<para>Despite the meaningless of inclusive costs in cycles, the big
- drawback for visualization motivates the possibility to temporarely
+ drawback for visualization motivates the possibility to temporarily
switch off cycle detection in KCachegrind, which can lead to
misguiding visualization. However, often cycles appear because of
- unlucky superposition of independant call chains in a way that
+ unlucky superposition of independent call chains in a way that
the profile result will see a cycle. Neglecting uninteresting
calls with very small measured inclusive cost would break these
cycles. In such cases, incorrect handling of cycles by not detecting
@@ -436,7 +436,7 @@
symbol explosion. The latter imposes large memory requirement for Callgrind
with possible out-of-memory conditions, and big profile data files.</para>
- <para>A further possibility to avoid cycles in Callgrinds profile data
+ <para>A further possibility to avoid cycles in Callgrind's profile data
output is to simply leave out given functions in the call graph. Of course, this
also skips any call information from and to an ignored function, and thus can
break a cycle. Candidates for this typically are dispatcher functions in event
@@ -619,7 +619,7 @@
</term>
<listitem>
<para>Dump profile data every <count> basic blocks.
- Whether a dump is needed is only checked when Valgrinds internal
+ Whether a dump is needed is only checked when Valgrind's internal
scheduler is run. Therefore, the minimum setting useful is about 100000.
The count is a 64-bit value to make long dump periods possible.
</para>
Modified: trunk/docs/xml/FAQ.xml
===================================================================
--- trunk/docs/xml/FAQ.xml 2007-11-17 02:46:42 UTC (rev 7172)
+++ trunk/docs/xml/FAQ.xml 2007-11-17 09:43:25 UTC (rev 7173)
@@ -193,7 +193,7 @@
much more slowly, but should detect the use of the out-of-date
code.</para>
- <para>Alternativaly, if you have the source code to the JIT compiler
+ <para>Alternatively, if you have the source code to the JIT compiler
you can insert calls to the
<computeroutput>VALGRIND_DISCARD_TRANSLATIONS</computeroutput>
client request to mark out-of-date code, saving you from using
@@ -555,7 +555,7 @@
<para>As for eager reporting of copies of uninitialised memory values,
this has been suggested multiple times. Unfortunately, almost all
- programs legitimately copy uninitialise memory values around (because
+ programs legitimately copy uninitialised memory values around (because
compilers pad structs to preserve alignment) and eager checking leads to
hundreds of false positives. Therefore Memcheck does not support eager
checking at this time.</para>
Modified: trunk/docs/xml/manual-core.xml
===================================================================
--- trunk/docs/xml/manual-core.xml 2007-11-17 02:46:42 UTC (rev 7172)
+++ trunk/docs/xml/manual-core.xml 2007-11-17 09:43:25 UTC (rev 7173)
@@ -113,7 +113,7 @@
looked in detail into fixing this, and unfortunately the result is that
doing so would give a further significant slowdown in what is already a slow
tool. So the best solution is to turn off optimisation altogether. Since
-this often makes things unmanagably slow, a reasonable compromise is to use
+this often makes things unmanageably slow, a reasonable compromise is to use
<computeroutput>-O</computeroutput>. This gets you the majority of the
benefits of higher optimisation levels whilst keeping relatively small the
chances of false positives or false negatives from Memcheck. Also, you
@@ -422,7 +422,7 @@
<listitem>
<para>Second line: name of the tool(s) that the suppression is for
(if more than one, comma-separated), and the name of the suppression
- itself, separated by a colon (Nb: no spaces are allowed), eg:</para>
+ itself, separated by a colon (n.b.: no spaces are allowed), eg:</para>
<programlisting><![CDATA[
tool_name1,tool_name2:suppression_name]]></programlisting>
@@ -530,7 +530,7 @@
<para>As mentioned above, Valgrind's core accepts a common set of flags.
The tools also accept tool-specific flags, which are documented
-seperately for each tool.</para>
+separately for each tool.</para>
<para>You invoke Valgrind like this:</para>
@@ -732,7 +732,7 @@
causes the log file name to be qualified using the contents of the
environment variable <computeroutput>$VAR</computeroutput>. This
is useful when running MPI programs. For further details, see
- <link linkend="manual-core.comment">Section 2.3 "The Commentary"</link>
+ <link linkend="manual-core.comment">the commentary</link>
in the manual.
</para>
</listitem>
@@ -751,7 +751,7 @@
be used in conjunction with the
<computeroutput>valgrind-listener</computeroutput> program. For
further details, see
- <link linkend="manual-core.comment">Section 2.3 "The Commentary"</link>
+ <link linkend="manual-core.comment">the commentary</link>
in the manual.</para>
</listitem>
</varlistentry>
@@ -890,7 +890,7 @@
</listitem>
</varlistentry>
- <varlistentry id="opt.gen-suppressions" xreflabel="--gen-supressions">
+ <varlistentry id="opt.gen-suppressions" xreflabel="--gen-suppressions">
<term>
<option><![CDATA[--gen-suppressions=<yes|no|all> [default: no] ]]></option>
</term>
@@ -1096,7 +1096,7 @@
<para>The GNU C library (<function>libc.so</function>), which is
used by all programs, may allocate memory for its own uses.
Usually it doesn't bother to free that memory when the program
- ends - there would be no point, since the Linux kernel reclaims
+ ends—there would be no point, since the Linux kernel reclaims
all process resources when a process exits anyway, so it would
just slow things down.</para>
@@ -1418,7 +1418,7 @@
<term><command><computeroutput>VALGRIND_DESTROY_MEMPOOL</computeroutput>:</command></term>
<listitem>
<para>This should be used in conjunction with
- <computeroutput>VALGRIND_CREATE_MEMPOOL</computeroutput>
+ <computeroutput>VALGRIND_CREATE_MEMPOOL</computeroutput>.
Again, see the comments in <filename>valgrind.h</filename> for
information on how to use it.</para>
</listitem>
@@ -1428,7 +1428,7 @@
<term><command><computeroutput>VALGRIND_MEMPOOL_ALLOC</computeroutput>:</command></term>
<listitem>
<para>This should be used in conjunction with
- <computeroutput>VALGRIND_CREATE_MEMPOOL</computeroutput>
+ <computeroutput>VALGRIND_CREATE_MEMPOOL</computeroutput>.
Again, see the comments in <filename>valgrind.h</filename> for
information on how to use it.</para>
</listitem>
@@ -1438,7 +1438,7 @@
<term><command><computeroutput>VALGRIND_MEMPOOL_FREE</computeroutput>:</command></term>
<listitem>
<para>This should be used in conjunction with
- <computeroutput>VALGRIND_CREATE_MEMPOOL</computeroutput>
+ <computeroutput>VALGRIND_CREATE_MEMPOOL</computeroutput>.
Again, see the comments in <filename>valgrind.h</filename> for
information on how to use it.</para>
</listitem>
@@ -1505,8 +1505,8 @@
<term><command><computeroutput>VALGRIND_STACK_CHANGE(id, start, end)</computeroutput>:</command></term>
<listitem>
<para>Changes a previously registered stack. Informs
- Valgrind that the previously registerer stack with stack id
- <computeroutput>id</computeroutput> has changed it's start and end
+ Valgrind that the previously registered stack with stack id
+ <computeroutput>id</computeroutput> has changed its start and end
values. Use this if your user-level thread package implements
stack growth.</para>
</listitem>
@@ -1548,7 +1548,7 @@
<para>Your program will use the native
<computeroutput>libpthread</computeroutput>, but not all of its facilities
-will work. In particular, synchonisation of processes via shared-memory
+will work. In particular, synchronisation of processes via shared-memory
segments will not work. This relies on special atomic instruction sequences
which Valgrind does not emulate in a way which works between processes.
Unfortunately there's no way for Valgrind to warn when this is happening,
@@ -1599,7 +1599,7 @@
<title>Function wrapping</title>
<para>
-Valgrind versions 3.2.0 and above and can do function wrapping on all
+Valgrind versions 3.2.0 and above can do function wrapping on all
supported targets. In function wrapping, calls to some specified
function are intercepted and rerouted to a different, user-supplied
function. This can do whatever it likes, typically examining the
@@ -2197,7 +2197,7 @@
programs behave as if they had been run on a machine with 64-bit IEEE
floats, for example PowerPC. On amd64 FP arithmetic is done by
default on SSE2, so amd64 looks more like PowerPC than x86 from an FP
- perspective, and there are far fewer noticable accuracy differences
+ perspective, and there are far fewer noticeable accuracy differences
than with x86.</para>
<para>Rounding: Valgrind does observe the 4 IEEE-mandated rounding
@@ -2212,7 +2212,7 @@
negative number, etc), division by zero, overflow, underflow,
inexact (loss of precision).</para>
- <para>For each exception, two courses of action are defined by 754:
+ <para>For each exception, two courses of action are defined by IEEE754:
either (1) a user-defined exception handler may be called, or (2) a
default action is defined, which "fixes things up" and allows the
computation to proceed without throwing an exception.</para>
Modified: trunk/docs/xml/manual-intro.xml
===================================================================
--- trunk/docs/xml/manual-intro.xml 2007-11-17 02:46:42 UTC (rev 7172)
+++ trunk/docs/xml/manual-intro.xml 2007-11-17 09:43:25 UTC (rev 7173)
@@ -153,7 +153,7 @@
it supports. Then, each tool has its own chapter in this manual. You
only need to read the documentation for the core and for the tool(s) you
actually use, although you may find it helpful to be at least a little
-bit familar with what all tools do. If you're new to all this, you probably
+bit familiar with what all tools do. If you're new to all this, you probably
want to run the Memcheck tool. The final chapter explains how to write a
new tool.</para>
Modified: trunk/docs/xml/valgrind-manpage.xml
===================================================================
--- trunk/docs/xml/valgrind-manpage.xml 2007-11-17 02:46:42 UTC (rev 7172)
+++ trunk/docs/xml/valgrind-manpage.xml 2007-11-17 09:43:25 UTC (rev 7173)
@@ -79,7 +79,7 @@
<listitem>
<para><option>callgrind</option> adds call graph tracing to cachegrind. It can be
used to get call counts and inclusive cost for each call happening in your
- program. In addition to cachegrind, callgrind can annotate threads separatly,
+ program. In addition to cachegrind, callgrind can annotate threads separately,
and every instruction of disassembler output of your program with the number of
instructions executed and cache misses incurred.</para>
</listitem>
Modified: trunk/helgrind/docs/hg-manual.xml
===================================================================
--- trunk/helgrind/docs/hg-manual.xml 2007-11-17 02:46:42 UTC (rev 7172)
+++ trunk/helgrind/docs/hg-manual.xml 2007-11-17 09:43:25 UTC (rev 7173)
@@ -1,6 +1,7 @@
<?xml version="1.0"?> <!-- -*- sgml -*- -->
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
- "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[ <!ENTITY % vg-entities SYSTEM "../../docs/xml/vg-entities.xml"> %vg-entities; ]>
<chapter id="hg-manual" xreflabel="Helgrind: thread error detector">
@@ -320,7 +321,7 @@
points of these two threads, so you can see which threads it is
referring to.</para>
</listitem>
- <listitem><para>Helgrind tries to provide an explaination of why the
+ <listitem><para>Helgrind tries to provide an explanation of why the
race exists: "<computeroutput>Location 0x601034 has never been
protected by any lock</computeroutput>".</para>
</listitem>
@@ -878,7 +879,7 @@
<para>Make sure your application, and all the libraries it uses,
use the POSIX threading primitives. Helgrind needs to be able to
see all events pertaining to thread creation, exit, locking and
- other syncronisation events. To do so it intercepts many POSIX
+ other synchronisation events. To do so it intercepts many POSIX
pthread_ functions.</para>
<para>Do not roll your own threading primitives (mutexes, etc)
Modified: trunk/massif/docs/ms-manual.xml
===================================================================
--- trunk/massif/docs/ms-manual.xml 2007-11-17 02:46:42 UTC (rev 7172)
+++ trunk/massif/docs/ms-manual.xml 2007-11-17 09:43:25 UTC (rev 7173)
@@ -1,6 +1,7 @@
<?xml version="1.0"?> <!-- -*- sgml -*- -->
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
- "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[ <!ENTITY % vg-entities SYSTEM "../../docs/xml/vg-entities.xml"> %vg-entities; ]>
<chapter id="ms-manual" xreflabel="Massif: a heap profiler">
Modified: trunk/memcheck/docs/mc-manual.xml
===================================================================
--- trunk/memcheck/docs/mc-manual.xml 2007-11-17 02:46:42 UTC (rev 7172)
+++ trunk/memcheck/docs/mc-manual.xml 2007-11-17 09:43:25 UTC (rev 7173)
@@ -167,7 +167,7 @@
<listitem>
<para>Controls how <constant>memcheck</constant> handles word-sized,
word-aligned loads from addresses for which some bytes are
- addressible and others are not. When <varname>yes</varname>, such
+ addressable and others are not. When <varname>yes</varname>, such
loads do not produce an address error. Instead, loaded bytes
originating from illegal addresses are marked as uninitialised, and
those corresponding to legal addresses are handled in the normal
@@ -418,12 +418,12 @@
</listitem>
<listitem>
<para>Also, if a system call needs to read from a buffer provided by
- your program, Memcheck checks that the entire buffer is addressible
+ your program, Memcheck checks that the entire buffer is addressable
and has valid data, ie, it is readable.</para>
</listitem>
<listitem>
<para>Also, if the system call needs to write to a user-supplied
- buffer, Memcheck checks that the buffer is addressible.</para>
+ buffer, Memcheck checks that the buffer is addressable.</para>
</listitem>
</itemizedlist>
</para>
@@ -937,7 +937,7 @@
<para>This apparently strange choice reduces the amount of confusing
information presented to the user. It avoids the unpleasant
phenomenon in which memory is read from a place which is both
- unaddressible and contains invalid values, and, as a result, you get
+ unaddressable and contains invalid values, and, as a result, you get
not only an invalid-address (read/write) error, but also a
potentially large set of uninitialised-value errors, one for every
time the value is used.</para>
@@ -958,24 +958,24 @@
<itemizedlist>
<listitem>
- <para>malloc/new/new[]: the returned memory is marked as addressible
+ <para>malloc/new/new[]: the returned memory is marked as addressable
but not having valid values. This means you have to write to it
before you can read it.</para>
</listitem>
<listitem>
- <para>calloc: returned memory is marked both addressible and valid,
+ <para>calloc: returned memory is marked both addressable and valid,
since calloc clears the area to zero.</para>
</listitem>
<listitem>
<para>realloc: if the new size is larger than the old, the new
- section is addressible but invalid, as with malloc.</para>
+ section is addressable but invalid, as with malloc.</para>
</listitem>
<listitem>
<para>If the new size is smaller, the dropped-off section is marked
- as unaddressible. You may only pass to realloc a pointer previously
+ as unaddressable. You may only pass to realloc a pointer previously
issued to you by malloc/calloc/realloc.</para>
</listitem>
@@ -983,7 +983,7 @@
<para>free/delete/delete[]: you may only pass to these functions a
pointer previously issued to you by the corresponding allocation
function. Otherwise, Memcheck complains. If the pointer is indeed
- valid, Memcheck marks the entire area it points at as unaddressible,
+ valid, Memcheck marks the entire area it points at as unaddressable,
and places the block in the freed-blocks-queue. The aim is to defer
as long as possible reallocation of this block. Until that happens,
all attempts to access it will elicit an invalid-address error, as
Modified: trunk/memcheck/docs/mc-tech-docs.xml
===================================================================
--- trunk/memcheck/docs/mc-tech-docs.xml 2007-11-17 02:46:42 UTC (rev 7172)
+++ trunk/memcheck/docs/mc-tech-docs.xml 2007-11-17 09:43:25 UTC (rev 7173)
@@ -708,7 +708,7 @@
do stores and loads of V bits to/from the sparse array which
keeps track of V bits in memory, and
<computeroutput>VGM_(handle_esp_assignment)</computeroutput>,
- which messes with memory addressibility resulting from
+ which messes with memory addressability resulting from
changes in <computeroutput>%ESP</computeroutput>.</para>
</listitem>
@@ -1185,7 +1185,7 @@
<listitem>
<para><computeroutput>LEA1</computeroutput> and
<computeroutput>LEA2</computeroutput> are not strictly
- necessary, but allow faciliate better translations. They
+ necessary, but facilitate better translations. They
record the fancy x86 addressing modes in a direct way, which
allows those amodes to be emitted back into the final
instruction stream more or less verbatim.</para>
@@ -1302,7 +1302,7 @@
from the synthesised shadow memory that Valgrind maintains.
In fact they do more than that, since they also do
address-validity checks, and emit complaints if the
- read/written addresses are unaddressible.</para>
+ read/written addresses are unaddressable.</para>
</listitem>
<listitem>
@@ -1716,7 +1716,7 @@
because it is vital the instrumenter always has an up-to-date
<computeroutput>%ESP</computeroutput> value available,
<computeroutput>%ESP</computeroutput> changes affect
- addressibility of the memory around the simulated stack
+ addressability of the memory around the simulated stack
pointer.</para>
<para>The implication of the above paragraph is that the
@@ -2594,9 +2594,9 @@
VALGRIND_MAKE_READABLE(addr, len)]]></programlisting>
<para>and also, to check that memory is
-addressible/initialised,</para>
+addressable/initialised,</para>
<programlisting><![CDATA[
- VALGRIND_CHECK_ADDRESSIBLE(addr, len)
+ VALGRIND_CHECK_ADDRESSABLE(addr, len)
VALGRIND_CHECK_INITIALISED(addr, len)]]></programlisting>
<para>I then include in my sources a header defining these
@@ -2691,7 +2691,7 @@
run it on post-CPP'd C/C++ source. The parser/prettyprinter
is probably not as hard as it sounds; I would write it in Haskell,
a powerful functional language well suited to doing symbolic
- computation, with which I am intimately familar. There is
+ computation, with which I am intimately familiar. There is
already a C parser written in Haskell by someone in the
Haskell community, and that would probably be a good starting
point.</para>
|
|
From: Oswald B. <os...@kd...> - 2007-11-17 09:23:44
|
On Sat, Nov 17, 2007 at 03:41:24AM +0100, Julian Seward wrote:
> On Saturday 17 November 2007 01:13, Nicholas Nethercote wrote:
> > That sounds ok. In summary:
> >
> > --log-file=<pattern>
>
> That sounds good to me. With patterns
>
> %p process ID
> %q(VAR) contents of $VAR
>
> I would prefer to use ( ) instead of { } around VAR. { and }
> interact really badly with shells and are generally a pain to
> work with.
>
oh, and ( ) do not interact badly with shells, huh? ;)
apart from that, { } is perfectly fine as long as there is no comma in
between.
last but not least, { } just feels more "natural" in scripting context.
only makefiles use $() for variable expansion, but there it has some
more meanings, too.
--
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.
|
|
From: Tom H. <th...@cy...> - 2007-11-17 03:51:37
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2007-11-17 03:15:01 GMT 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 == 317 tests, 59 stderr failures, 1 stdout failure, 27 post failures == memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/long_namespace_xml (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/x86/bug152022 (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/xor-undef-x86 (stderr) memcheck/tests/xml1 (stderr) massif/tests/alloc-fns-A (post) massif/tests/alloc-fns-B (post) massif/tests/basic (post) massif/tests/big-alloc (post) massif/tests/culling1 (stderr) massif/tests/culling2 (stderr) massif/tests/custom_alloc (post) massif/tests/deep-A (post) massif/tests/deep-B (stderr) massif/tests/deep-B (post) massif/tests/deep-C (stderr) massif/tests/deep-C (post) massif/tests/deep-D (post) massif/tests/ignoring (post) massif/tests/insig (post) massif/tests/long-time (post) massif/tests/new-cpp (post) massif/tests/null (post) massif/tests/one (post) massif/tests/overloaded-new (post) massif/tests/peak (post) massif/tests/peak2 (stderr) massif/tests/peak2 (post) massif/tests/realloc (stderr) massif/tests/realloc (post) massif/tests/thresholds_0_0 (post) massif/tests/thresholds_0_10 (post) massif/tests/thresholds_10_0 (post) massif/tests/thresholds_10_10 (post) massif/tests/thresholds_5_0 (post) massif/tests/thresholds_5_10 (post) massif/tests/zero1 (post) massif/tests/zero2 (post) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/hg06_readshared (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc02_simple_tls (stderr) helgrind/tests/tc03_re_excl (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc12_rwl_trivial (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) |
|
From: Tom H. <th...@cy...> - 2007-11-17 03:27:45
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2007-11-17 03:05:08 GMT 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 == 351 tests, 6 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) |
|
From: Tom H. <th...@cy...> - 2007-11-17 03:13:04
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-11-17 03:00:03 GMT 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 == 353 tests, 24 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) |
|
From: Tom H. <th...@cy...> - 2007-11-17 03:11:10
|
Nightly build on dellow ( x86_64, Fedora 8 ) started at 2007-11-17 03:10:04 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... failed Last 20 lines of verbose log follow echo checking dependency style of g++... gcc3 checking for ranlib... ranlib checking for perl... /usr/bin/perl checking for gdb... /usr/bin/gdb checking dependency style of gcc... gcc3 checking for a supported version of gcc... ok (gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33)) checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking for a supported CPU... ok (x86_64) checking for use as an inner Valgrind... no checking for a 64-bit only build... no checking for a 32-bit only build... no checking for a supported OS... ok (linux-gnu) checking for the kernel version... 2.6 family (2.6.23.1-49.fc8) checking for 32 bit build support... yes checking for a supported CPU/OS combination... ok (x86_64-linux-gnu) checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking the libc version... unsupported version configure: error: Valgrind requires glibc version 2.2 - 2.6 |
|
From: <sv...@va...> - 2007-11-17 02:46:40
|
Author: sewardj
Date: 2007-11-17 02:46:42 +0000 (Sat, 17 Nov 2007)
New Revision: 7172
Log:
Update.
Modified:
trunk/docs/internals/3_2_BUGSTATUS.txt
Modified: trunk/docs/internals/3_2_BUGSTATUS.txt
===================================================================
--- trunk/docs/internals/3_2_BUGSTATUS.txt 2007-11-17 02:05:57 UTC (rev 7171)
+++ trunk/docs/internals/3_2_BUGSTATUS.txt 2007-11-17 02:46:42 UTC (rev 7172)
@@ -29,6 +29,9 @@
124478 glibc-fix memcheck reports uninitialized bytes on
timer_create() while it should not
+127371 fixed java vm giving unhandled instruction bytes:
+ 0x26 0x2E 0x64 0x65
+
128359 glibc-fix Please suppress the uninitialized bytes report
on getifaddrs() (glibc 2.3.3)
@@ -41,8 +44,8 @@
137396 fixed :-) I would really like helgrind to work again...
137714 vx1787 x86/amd64->IR: 0x66 0xF 0xF7 0xC6 (maskmovq, maskmovdq)
-145559 valgrind aborts when malloc_stats is called
-145609 valgrind aborts all runs with 'repeated section!'
+145559 r7168 valgrind aborts when malloc_stats is called
+145609 queried valgrind aborts all runs with 'repeated section!'
145622 --db-attach broken again on x86-64
145837 ==149519
145887 PPC32: getitimer() system call is not supported (patch)
@@ -50,9 +53,9 @@
146252 queried amd64->IR: handle Group 5 extended CALL and JMP insns
with non-reg operands of sz==8
146701 ==134990
-146781 Adding support for private futexes
+146781 r7169 Adding support for private futexes
-147325 valgrind internal error on syscall (SYS_io_destroy, 0)
+147325 r7170 valgrind internal error on syscall (SYS_io_destroy, 0)
147498 vx1795 amd64->IR: 0xF0 0xF 0xB0 0xF (lock cmpxchg %cl,(%rdi))
147628 vx1796 SALC opcode 0xd6 unimplemented
147825 r6793 crash on amd64-linux with gcc 4.2 and glibc 2.6 (CFI)
@@ -69,11 +72,11 @@
149182 vx1784/5 PPC Trap instructions not implemented in valgrind
149838 marginal x86->IR: 0xF 0xAE 0xD 0xE0 (FXRSTOR ?)
149519 r6813/4 ppc32: V aborts with SIGSEGV on execution of a signal handler
-149878 add (proper) check for calloc integer overflow
+149878 marginal add (proper) check for calloc integer overflow
149892 ==137714
-150044 SEGV during stack deregister
-150045 Valgrind doesn't recognize pthread stack as a stack
+150044 r7171 SEGV during stack deregister
+150045 fixable?? Valgrind doesn't recognize pthread stack as a stack
when context switching
150380 dwarf/gcc interoperation (dwarf3 read problems)
(related to 129937 ?)
|
|
From: Julian S. <js...@ac...> - 2007-11-17 02:41:37
|
On Saturday 17 November 2007 01:13, Nicholas Nethercote wrote:
> That sounds ok. In summary:
>
> --log-file=<pattern>
>
> --cachegrind-out-file=<pattern>
>
> --massif-out-file=<pattern>
>
> --callgrind-out-file=<pattern>
That sounds good to me. With patterns
%p process ID
%q(VAR) contents of $VAR
I would prefer to use ( ) instead of { } around VAR. { and }
interact really badly with shells and are generally a pain to
work with.
J
|
|
From: <sv...@va...> - 2007-11-17 02:05:55
|
Author: sewardj
Date: 2007-11-17 02:05:57 +0000 (Sat, 17 Nov 2007)
New Revision: 7171
Log:
Stack registration stuff: don't dereference NULL pointers (Eric
Sharkey, #150044).
Modified:
trunk/coregrind/m_stacks.c
Modified: trunk/coregrind/m_stacks.c
===================================================================
--- trunk/coregrind/m_stacks.c 2007-11-17 01:49:06 UTC (rev 7170)
+++ trunk/coregrind/m_stacks.c 2007-11-17 02:05:57 UTC (rev 7171)
@@ -154,7 +154,7 @@
VG_(debugLog)(2, "stacks", "deregister stack %lu\n", id);
- if (current_stack->id == id) {
+ if (current_stack && current_stack->id == id) {
current_stack = NULL;
}
@@ -209,7 +209,8 @@
if (current_stack == NULL ||
new_SP < current_stack->start || new_SP > current_stack->end) {
Stack* new_stack = find_stack_by_addr(new_SP);
- if (new_stack && new_stack->id != current_stack->id) {
+ if (new_stack
+ && (current_stack == NULL || new_stack->id != current_stack->id)) {
/* The stack pointer is now in another stack. Update the current
stack information and return without doing anything else. */
current_stack = new_stack;
|
|
From: <sv...@va...> - 2007-11-17 01:49:07
|
Author: sewardj
Date: 2007-11-17 01:49:06 +0000 (Sat, 17 Nov 2007)
New Revision: 7170
Log:
Don't segfault on syscall (SYS_io_destroy, 0). (Jakub Jelinek) Fixes
#147325.
Modified:
trunk/coregrind/m_syswrap/syswrap-linux.c
Modified: trunk/coregrind/m_syswrap/syswrap-linux.c
===================================================================
--- trunk/coregrind/m_syswrap/syswrap-linux.c 2007-11-17 01:35:08 UTC (rev 7169)
+++ trunk/coregrind/m_syswrap/syswrap-linux.c 2007-11-17 01:49:06 UTC (rev 7170)
@@ -1223,17 +1223,18 @@
// file-descriptors are closed...
PRE(sys_io_destroy)
{
- struct vki_aio_ring *r;
- SizeT size;
+ SizeT size = 0;
PRINT("sys_io_destroy ( %llu )", (ULong)ARG1);
PRE_REG_READ1(long, "io_destroy", vki_aio_context_t, ctx);
// If we are going to seg fault (due to a bogus ARG1) do it as late as
// possible...
- r = (struct vki_aio_ring *)ARG1;
- size = VG_PGROUNDUP(sizeof(struct vki_aio_ring) +
- r->nr*sizeof(struct vki_io_event));
+ if (ML_(safe_to_deref)( (void*)ARG1, sizeof(struct vki_aio_ring))) {
+ struct vki_aio_ring *r = (struct vki_aio_ring *)ARG1;
+ size = VG_PGROUNDUP(sizeof(struct vki_aio_ring) +
+ r->nr*sizeof(struct vki_io_event));
+ }
SET_STATUS_from_SysRes( VG_(do_syscall1)(SYSNO, ARG1) );
|
|
From: <sv...@va...> - 2007-11-17 01:35:08
|
Author: sewardj
Date: 2007-11-17 01:35:08 +0000 (Sat, 17 Nov 2007)
New Revision: 7169
Log:
Add support for private futexes (whatever they might be). Patch from
Eric Dumazet. Fixes #146781.
Modified:
trunk/coregrind/m_syswrap/syswrap-linux.c
trunk/include/vki/vki-linux.h
Modified: trunk/coregrind/m_syswrap/syswrap-linux.c
===================================================================
--- trunk/coregrind/m_syswrap/syswrap-linux.c 2007-11-16 22:29:27 UTC (rev 7168)
+++ trunk/coregrind/m_syswrap/syswrap-linux.c 2007-11-17 01:35:08 UTC (rev 7169)
@@ -844,21 +844,25 @@
PRINT("sys_futex ( %p, %d, %d, %p, %p )", ARG1,ARG2,ARG3,ARG4,ARG5);
switch(ARG2) {
case VKI_FUTEX_CMP_REQUEUE:
+ case VKI_FUTEX_CMP_REQUEUE | VKI_FUTEX_PRIVATE_FLAG:
PRE_REG_READ6(long, "futex",
vki_u32 *, futex, int, op, int, val,
struct timespec *, utime, vki_u32 *, uaddr2, int, val3);
break;
case VKI_FUTEX_REQUEUE:
+ case VKI_FUTEX_REQUEUE | VKI_FUTEX_PRIVATE_FLAG:
PRE_REG_READ5(long, "futex",
vki_u32 *, futex, int, op, int, val,
struct timespec *, utime, vki_u32 *, uaddr2);
break;
case VKI_FUTEX_WAIT:
+ case VKI_FUTEX_WAIT | VKI_FUTEX_PRIVATE_FLAG:
PRE_REG_READ4(long, "futex",
vki_u32 *, futex, int, op, int, val,
struct timespec *, utime);
break;
case VKI_FUTEX_WAKE:
+ case VKI_FUTEX_WAKE | VKI_FUTEX_PRIVATE_FLAG:
case VKI_FUTEX_FD:
PRE_REG_READ3(long, "futex",
vki_u32 *, futex, int, op, int, val);
@@ -874,16 +878,20 @@
switch(ARG2) {
case VKI_FUTEX_WAIT:
+ case VKI_FUTEX_WAIT | VKI_FUTEX_PRIVATE_FLAG:
if (ARG4 != 0)
PRE_MEM_READ( "futex(timeout)", ARG4, sizeof(struct vki_timespec) );
break;
case VKI_FUTEX_REQUEUE:
+ case VKI_FUTEX_REQUEUE | VKI_FUTEX_PRIVATE_FLAG:
case VKI_FUTEX_CMP_REQUEUE:
+ case VKI_FUTEX_CMP_REQUEUE | VKI_FUTEX_PRIVATE_FLAG:
PRE_MEM_READ( "futex(futex2)", ARG5, sizeof(Int) );
break;
case VKI_FUTEX_WAKE:
+ case VKI_FUTEX_WAKE | VKI_FUTEX_PRIVATE_FLAG:
case VKI_FUTEX_FD:
/* no additional pointers */
break;
Modified: trunk/include/vki/vki-linux.h
===================================================================
--- trunk/include/vki/vki-linux.h 2007-11-16 22:29:27 UTC (rev 7168)
+++ trunk/include/vki/vki-linux.h 2007-11-17 01:35:08 UTC (rev 7169)
@@ -1151,6 +1151,7 @@
#define VKI_FUTEX_FD (2)
#define VKI_FUTEX_REQUEUE (3)
#define VKI_FUTEX_CMP_REQUEUE (4)
+#define VKI_FUTEX_PRIVATE_FLAG (128)
struct vki_robust_list {
struct vki_robust_list __user *next;
|
|
From: <js...@ac...> - 2007-11-17 01:20:46
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-11-17 02:00:01 CET 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 == 284 tests, 25 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (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 == 284 tests, 25 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stdout) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sat Nov 17 02:10:05 2007 --- new.short Sat Nov 17 02:20:47 2007 *************** *** 8,10 **** ! == 284 tests, 25 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) --- 8,10 ---- ! == 284 tests, 25 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) *************** *** 25,27 **** helgrind/tests/tc07_hbl1 (stderr) - helgrind/tests/tc08_hbl2 (stdout) helgrind/tests/tc08_hbl2 (stderr) --- 25,26 ---- |
|
From: Josef W. <Jos...@gm...> - 2007-11-17 00:52:23
|
On Saturday 17 November 2007, Nicholas Nethercote wrote: > On Fri, 16 Nov 2007, Josef Weidendorfer wrote: > > > I am not really settled about "--out-file". I just think that options for > > similar functions in different tools should show some consistency. > > So I am really fine with an option "--<toolname>-out-file=..." with support > > for patterns (like %p). > > > > So I would change the according callgrind option to "--callgrind-out-file=...", > > independent of the fact that callgrind could produce further files with > > additional suffix. > > > > Is this OK? > > That sounds ok. In summary: > > --log-file=<pattern> > > --cachegrind-out-file=<pattern> > > --massif-out-file=<pattern> > > --callgrind-out-file=<pattern> > > The latter could also be --callgrind-out-prefix, but I'm ok with > --callgrind-out-file. The thing is that for normal use, it is the not a prefix, but the output file name. And even in other cases with multiple files, one will have exactly this name. So I think that should be fine. > We could also shorten the options names, eg. --cg-out-file, but I'm not too > fussed about that. I think the option will not be used to often; so a long name should be ok. The nice thing is that the long name matches quite fine the default output file name (for all of cachegrind, callgrind, massif). Josef > > Nick > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |