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
(32) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
1
(30) |
2
(8) |
3
(5) |
4
(5) |
|
5
(3) |
6
(9) |
7
(5) |
8
(14) |
9
(17) |
10
(27) |
11
(10) |
|
12
(6) |
13
(10) |
14
(7) |
15
(16) |
16
(9) |
17
(14) |
18
(8) |
|
19
(5) |
20
(13) |
21
(21) |
22
(13) |
23
(4) |
24
(1) |
25
(4) |
|
26
(2) |
27
(7) |
28
(4) |
29
(5) |
30
(12) |
|
|
|
From: Florian K. <fl...@ei...> - 2015-04-03 14:30:09
|
On 03.04.2015 04:14, Petar Jovanovic wrote:
>
> Field _valEx is used on MIPS only for pipe system call when kernel can
> return an array of two file descriptors. Otherwise, this field is undefined
> (actually, it has a value that happened to be in v1 register, which can be
> an arbitrary value and it is not deterministic). Thus, comparing _valEx
> does not make sense for an arbitrary SysRes.
Yes. But comparing _valEx makes sense when it has a deterministic value
(i.e. after a pipe call). So not comparing the _valEx value at all does
not sound right either. How is this (for mips64):
Index: coregrind/m_syscall.c
===================================================================
--- coregrind/m_syscall.c (revision 15062)
+++ coregrind/m_syscall.c (working copy)
@@ -859,6 +859,7 @@
ULong V0 = do_syscall_WRK(a1,a2,a3,a4,a5,a6,sysno,v1_a3);
ULong V1 = (ULong)v1_a3[0];
ULong A3 = (ULong)v1_a3[1];
+ if (sysno != _NR_pipe) V1 = 0; // V1 is unused for this syscall
return VG_(mk_SysRes_mips64_linux)( V0, V1, A3 );
#else
Does that help?
> Your yesterday's change r15060 breaks MIPS port in general, as comparing
> _valEx will fail immediately.
I made the change because the code as is was looked just wrong.
Florian
|
|
From: Rhys K. <rhy...@gm...> - 2015-04-03 10:58:03
|
OS X reports the following failure with the recently introduced none/tests/bigcode, although the underlying components of that test have been in place for some time. https://bugs.kde.org/show_bug.cgi?id=345824 Am investigating, but reported for good governance. Rhys On 2 April 2015 at 09:51, <sv...@va...> wrote: > Author: philippe > Date: Wed Apr 1 23:51:07 2015 > New Revision: 15062 > > Log: > Add a test that triggers sector recycling > (cfr bug fix in revision 15058: without 15058, the below test > loops for ever). > > Added: > trunk/none/tests/bigcode.stderr.exp > trunk/none/tests/bigcode.stdout.exp > trunk/none/tests/bigcode.vgtest > Modified: > trunk/none/tests/Makefile.am > > Modified: trunk/none/tests/Makefile.am > > ============================================================================== > --- trunk/none/tests/Makefile.am (original) > +++ trunk/none/tests/Makefile.am Wed Apr 1 23:51:07 2015 > @@ -68,6 +68,7 @@ > ansi.stderr.exp ansi.vgtest \ > args.stderr.exp args.stdout.exp args.vgtest \ > async-sigs.stderr.exp async-sigs.stderr.exp-mips32 > async-sigs.vgtest \ > + bigcode.vgtest bigcode.stderr.exp bigcode.stdout.exp \ > bitfield1.stderr.exp bitfield1.vgtest \ > bug129866.vgtest bug129866.stderr.exp bug129866.stdout.exp \ > closeall.stderr.exp closeall.vgtest \ > > Added: trunk/none/tests/bigcode.stderr.exp > > ============================================================================== > --- trunk/none/tests/bigcode.stderr.exp (added) > +++ trunk/none/tests/bigcode.stderr.exp Wed Apr 1 23:51:07 2015 > @@ -0,0 +1,2 @@ > + > + > > Added: trunk/none/tests/bigcode.stdout.exp > > ============================================================================== > --- trunk/none/tests/bigcode.stdout.exp (added) > +++ trunk/none/tests/bigcode.stdout.exp Wed Apr 1 23:51:07 2015 > @@ -0,0 +1,2 @@ > +mode 1: 20000 copies of f(), 1 reps > +....................result = -37457500 > > Added: trunk/none/tests/bigcode.vgtest > > ============================================================================== > --- trunk/none/tests/bigcode.vgtest (added) > +++ trunk/none/tests/bigcode.vgtest Wed Apr 1 23:51:07 2015 > @@ -0,0 +1,8 @@ > +# this test exercises m_transtab.c sector recycling > +# and sanity check when recycling sectors. To ensure we recycle > +# sectors, we put a small number of sectors. > +# use --stats=yes if you want to verify that the below still > +# recycles a (already used) sector. > +prog: ../../perf/bigcode > +args: 1 > +vgopts: --num-transtab-sectors=2 --sanity-level=4 > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Petar J. <mip...@gm...> - 2015-04-03 02:14:34
|
Hi Florian, Sorry for not responding to this earlier. Field _valEx is used on MIPS only for pipe system call when kernel can return an array of two file descriptors. Otherwise, this field is undefined (actually, it has a value that happened to be in v1 register, which can be an arbitrary value and it is not deterministic). Thus, comparing _valEx does not make sense for an arbitrary SysRes. Your yesterday's change r15060 breaks MIPS port in general, as comparing _valEx will fail immediately. Petar On Mon, Mar 23, 2015 at 8:36 PM, Florian Krohm <fl...@ei...> wrote: > r12616 (merge mips32 port) adds a new field '_valEx' to the SysRes > structure. However, the function sr_EQ which tests two SysRes values for > equality ignores that field. > That doesn't look right. But in case it is correct there should be some > verbiage as to why _valEx does not matter for equality. > > Florian > |
Author: florian
Date: Thu Apr 2 23:02:24 2015
New Revision: 15064
Log:
Add testcase for BZ 231357.
To do that a small enhancement to vg_regtest was needed:
(1) New declaration to allow specifying an environemnt variable
that is set prior to invoking valgrind.
eg: env: VAR=VAL
There can be more than one such declaration
(2) prog-asis: program_name
This is like prog: except the program name is not prefixed with
the testdir.
Added:
trunk/none/tests/bug231357.stderr.exp
trunk/none/tests/bug231357.stdout.exp
trunk/none/tests/bug231357.vgtest
Modified:
trunk/none/tests/Makefile.am
trunk/tests/vg_regtest.in
Modified: trunk/none/tests/Makefile.am
==============================================================================
--- trunk/none/tests/Makefile.am (original)
+++ trunk/none/tests/Makefile.am Thu Apr 2 23:02:24 2015
@@ -71,6 +71,7 @@
bigcode.vgtest bigcode.stderr.exp bigcode.stdout.exp \
bitfield1.stderr.exp bitfield1.vgtest \
bug129866.vgtest bug129866.stderr.exp bug129866.stdout.exp \
+ bug231357.vgtest bug231357.stderr.exp bug231357.stdout.exp \
closeall.stderr.exp closeall.vgtest \
cmdline0.stderr.exp cmdline0.stdout.exp cmdline0.vgtest \
cmdline1.stderr.exp cmdline1.stdout.exp cmdline1.vgtest \
Added: trunk/none/tests/bug231357.stderr.exp
==============================================================================
(empty)
Added: trunk/none/tests/bug231357.stdout.exp
==============================================================================
--- trunk/none/tests/bug231357.stdout.exp (added)
+++ trunk/none/tests/bug231357.stdout.exp Thu Apr 2 23:02:24 2015
@@ -0,0 +1 @@
+/tmp/bruhaha/test.sh
Added: trunk/none/tests/bug231357.vgtest
==============================================================================
--- trunk/none/tests/bug231357.vgtest (added)
+++ trunk/none/tests/bug231357.vgtest Thu Apr 2 23:02:24 2015
@@ -0,0 +1,5 @@
+prereq: rm -rf /tmp/bruhaha && mkdir /tmp/bruhaha && echo '#!/bin/echo' > /tmp/bruhaha/test.sh && chmod +x /tmp/bruhaha/test.sh
+env: PATH=/tmp/bruhaha:$PATH
+prog-asis: test.sh
+vgopts: -q
+cleanup: rm -rf /tmp/bruhaha
Modified: trunk/tests/vg_regtest.in
==============================================================================
--- trunk/tests/vg_regtest.in (original)
+++ trunk/tests/vg_regtest.in Thu Apr 2 23:02:24 2015
@@ -59,7 +59,9 @@
#
# Each test is defined in a file <test>.vgtest, containing one or more of the
# following lines, in any order:
-# - prog: <prog to run> (compulsory)
+# - prog: <prog to run>
+# - prog-asis: <prog to run>
+# - env: <environment variable for prog> (default: none)
# - args: <args for prog> (default: none)
# - vgopts: <Valgrind options> (default: none;
# multiple are allowed)
@@ -80,11 +82,16 @@
# - post: <post-test check command> (default: none)
# - cleanup: <post-test cleanup cmd> (default: none)
#
+# One of prog or prog-asis must be specified.
# If prog or probB is a relative path, it will be prefix with the test directory.
+# prog-asis will be taken as is, i.e. not prefixed with the test directory.
# Note that filters are necessary for stderr results to filter out things that
# always change, eg. process id numbers.
# Note that if a progB is specified, it is started in background (before prog).
#
+# There can be more than one env: declaration. Here is an example:
+# env: PATH=/opt/bin:$PATH
+#
# Expected stdout (filtered) is kept in <test>.stdout.exp* (can be more
# than one expected output). It can be missing if it would be empty. Expected
# stderr (filtered) is kept in <test>.stderr.exp*. There must be at least
@@ -154,6 +161,7 @@
my $prereq; # prerequisite test to satisfy before running test
my $post; # check command after running test
my $cleanup; # cleanup command to run
+my @env = (); # environment variable to set prior calling $prog
my @failures; # List of failed tests
@@ -302,6 +310,8 @@
$vgopts = $vgopts . " " . $addvgopts; # Nb: Make sure there's a space!
} elsif ($line =~ /^\s*prog:\s*(.*)$/) {
$prog = validate_program(".", $1, 0, 0);
+ } elsif ($line =~ /^\s*prog-asis:\s*(.*)$/) {
+ $prog = $1;
} elsif ($line =~ /^\s*args:\s*(.*)$/) {
$args = $1;
} elsif ($line =~ /^\s*stdout_filter:\s*(.*)$/) {
@@ -332,6 +342,8 @@
$post = $1;
} elsif ($line =~ /^\s*cleanup:\s*(.*)$/) {
$cleanup = $1;
+ } elsif ($line =~ /^\s*env:\s*(.*)$/) {
+ push @env,$1;
} else {
die "Bad line in $f: $line\n";
}
@@ -466,13 +478,19 @@
} else {
printf("%-16s valgrind $extraopts $vgopts $prog $args\n", "$name:");
}
-
+
+ # Collect environment variables, if any.
+ my $envvars = "";
+ foreach my $e (@env) {
+ $envvars = "$envvars $e";
+ }
+
# Pass the appropriate --tool option for the directory (can be overridden
# by an "args:" line, though).
my $tool=determine_tool();
if (defined $outer_valgrind ) {
# in an outer-inner setup, only set VALGRIND_LIB_INNER
- mysystem( "VALGRIND_LIB_INNER=$valgrind_lib "
+ mysystem( "$envvars VALGRIND_LIB_INNER=$valgrind_lib "
. "$outer_valgrind "
. "--tool=" . $outer_tool . " "
. "$outer_args "
@@ -484,7 +502,7 @@
} else {
# Set both VALGRIND_LIB and VALGRIND_LIB_INNER in case this Valgrind
# was configured with --enable-inner.
- mysystem( "VALGRIND_LIB=$valgrind_lib VALGRIND_LIB_INNER=$valgrind_lib "
+ mysystem( "$envvars VALGRIND_LIB=$valgrind_lib VALGRIND_LIB_INNER=$valgrind_lib "
. "$valgrind --command-line-only=yes --memcheck:leak-check=no "
. "--tool=$tool $extraopts $vgopts "
. "$prog $args > $name.stdout.out 2> $name.stderr.out");
|
|
From: Philippe W. <phi...@sk...> - 2015-04-02 20:05:16
|
On Thu, 2015-04-02 at 21:27 +0200, Ivo Raisr wrote: > > Back to memcheck annotations in setHelperAnns(). I tried to add > another > > element of fxState for FP and - what surprise - no effect on x86 > +amd64/Linux. > All tests passed, nothing failed. I suspect that all this is working due to the default value: --vex-iropt-register-updates=unwindregs-at-mem-access Even if the dirty helper does not indicate that the FP must be up to date at dirty helper call, the above flag will ensure the FP has a correct value. I am wondering what is the behaviour of memcheck if we fix the dirty helper (i.e. indicate it reads FP) but use sp-at-mem-access for --vex-iropt-register-updates ? Are all tests still ok ? Philippe |
|
From: Ivo R. <iv...@iv...> - 2015-04-02 19:27:29
|
2015-03-31 19:40 GMT+02:00 Julian Seward <js...@ac...>: > On 30/03/15 11:14, Ivo Raisr wrote: > > Please could you shed some light on why setHelperAnns() > > in mc_translate.c annotates all memcheck's dirty helpers > > to indicate that IP and SP could be read? > > > > I guess the reason is that IP and SP are required for > > stack unwinding in case one of these dirty helpers > > detect a problem which needs to be reported. > > Yes, that is correct. > Thank you for confirmation. > > > But if this is so, then why also FP is not present in annotations? > > Hmm. I don't know. My first impression is that this is a bug. > > How did you detect this? By code inspection, or did you see some > unwind failures -- that is, direct evidence of unwind failures? > Code inspection. But further inspection showed that not all architectures have a register equivalent to FP. Primary suspects are ARM/ARM64, which do not even contain any sane value for offset_FP in the VEX guest layout. This means exp-sgcheck on such arches probably produces strange results. Back to memcheck annotations in setHelperAnns(). I tried to add another element of fxState for FP and - what surprise - no effect on x86+amd64/Linux. All tests passed, nothing failed. I have no access to arm to test there. But what I found is that annotations on dirty helpers injected *by tools* are not processed in any way. Only annotations on dirty helpers injected by guest->IR translation are processed by tool instrumentation functions. So I tried to remove annotations in setHelperAnns(). And - what surprise - no effect on x86+amd64/Linux. All tests passed, nothing failed. So this confirms my previous finding. Patch to add FP in setHelperAnns() is posted in bug report: https://bugs.kde.org/show_bug.cgi?id=345811 I. |
Author: florian
Date: Thu Apr 2 17:07:41 2015
New Revision: 15063
Log:
When skipping white space after #! to find the interpreter
only skip ' ' and tabs.
Added:
trunk/none/tests/shell_valid4 (with props)
trunk/none/tests/shell_valid4.stderr.exp
trunk/none/tests/shell_valid4.stdout.exp
trunk/none/tests/shell_valid4.vgtest
Modified:
trunk/coregrind/m_ume/script.c
trunk/none/tests/Makefile.am
Modified: trunk/coregrind/m_ume/script.c
==============================================================================
--- trunk/coregrind/m_ume/script.c (original)
+++ trunk/coregrind/m_ume/script.c Thu Apr 2 17:07:41 2015
@@ -55,7 +55,7 @@
// Find interpreter name, make sure it's an absolute path (starts with
// '/') and has at least one more char. First, skip over any space
// between the #! and the start of the interpreter name
- while (interp < end && VG_(isspace)(*interp)) interp++;
+ while (interp < end && (*interp == ' ' || *interp == '\t')) interp++;
// overrun?
if (interp >= end) return False; // can't find start of interp name
Modified: trunk/none/tests/Makefile.am
==============================================================================
--- trunk/none/tests/Makefile.am (original)
+++ trunk/none/tests/Makefile.am Thu Apr 2 17:07:41 2015
@@ -159,6 +159,7 @@
shell_valid1 shell_valid1.vgtest shell_valid1.stderr.exp \
shell_valid2 shell_valid2.vgtest shell_valid2.stderr.exp \
shell_valid3 shell_valid3.vgtest shell_valid3.stderr.exp \
+ shell_valid4 shell_valid4.vgtest shell_valid4.stderr.exp shell_valid4.stdout.exp \
shell_zerolength shell_zerolength.vgtest shell_zerolength.stderr.exp \
shell_zerolength.stderr.exp-dash \
sha1_test.stderr.exp sha1_test.vgtest \
Added: trunk/none/tests/shell_valid4
==============================================================================
--- trunk/none/tests/shell_valid4 (added)
+++ trunk/none/tests/shell_valid4 Thu Apr 2 17:07:41 2015
@@ -0,0 +1,3 @@
+#!
+/bin/echo
+
Added: trunk/none/tests/shell_valid4.stderr.exp
==============================================================================
(empty)
Added: trunk/none/tests/shell_valid4.stdout.exp
==============================================================================
--- trunk/none/tests/shell_valid4.stdout.exp (added)
+++ trunk/none/tests/shell_valid4.stdout.exp Thu Apr 2 17:07:41 2015
@@ -0,0 +1 @@
+
Added: trunk/none/tests/shell_valid4.vgtest
==============================================================================
--- trunk/none/tests/shell_valid4.vgtest (added)
+++ trunk/none/tests/shell_valid4.vgtest Thu Apr 2 17:07:41 2015
@@ -0,0 +1,7 @@
+#
+# This test used to write
+# ./shell_valid4
+# to stdout which is not what happens when executed natively.
+#
+prog: shell_valid4
+vgopts: -q
|
|
From: Josef W. <Jos...@gm...> - 2015-04-02 12:25:28
|
Am 02.04.2015 um 04:36 schrieb Shujunjun: > From the backtrace information, it can see that at the first time _vgw00000ZZ_libcZdsoZd6_malloc call itself. This is normal. It is not the wrapper calling itself, but the malloc implementation jumping into an initialization, and then calling malloc recursively. The jump is "replacing" the previous stack frame (tail recursion optimization). A backtrace then looks like the wrapper would call itself. You can use callgrind to see this (just run any binary). The first time malloc (actually __libc_malloc) is called, it jumps to a function (malloc_hook_ini), which first runs an initialization function (ptmalloc_init) before calling malloc recursively. Your tool obviously needs to handle recursive malloc calls, It may be enough to have a special case for the first call. Josef |
|
From: zejian ju <juz...@gm...> - 2015-04-02 06:39:07
|
2015-04-02 14:33 GMT+08:00 zejian ju <juz...@gm...>: > > > 2015-04-01 18:07 GMT+08:00 Julian Seward <js...@ac...>: > >> >> > Is any one working on the port to arm64-android? >> >> It should already work. At least, I made it work for arm64-android >> (Android 4.5 running on ARM Juno) a couple of months back. See >> README.android in the top level directory for more info. > > Thank you for your response, but I do not find any clue about arm64 in > README.android. Is it described in other place? > Very sorry for the last message, I just find it in the README.android from the trunk. I checked against the latest release version formerly. --zenk |
|
From: zejian ju <juz...@gm...> - 2015-04-02 06:33:21
|
2015-04-01 18:07 GMT+08:00 Julian Seward <js...@ac...>: > > > Is any one working on the port to arm64-android? > > It should already work. At least, I made it work for arm64-android > (Android 4.5 running on ARM Juno) a couple of months back. See > README.android in the top level directory for more info. Thank you for your response, but I do not find any clue about arm64 in README.android. Is it described in other place? --zenk |
|
From: Shujunjun <shu...@hu...> - 2015-04-02 02:36:53
|
Thank you for your suggestion.
I rewrite my code, remove the "sprinf" and "write" but the problem is still exist.
I use gdb+vgdb to trace it. It seems had same problem I said before.
In prog.c when call "malloc" for "addr1", the wrapper function run as follow:
break point 1
break point 2
break point 1
break point 2
break point3
break point3
but when call "malloc" for "addr2", the wrapper function run as follow:
break point 1
break point 2
break point3
From the backtrace information, it can see that at the first time _vgw00000ZZ_libcZdsoZd6_malloc call itself.
######in test.wrap.sub.c
#include <stdio.h>
#include "valgrind.h"
int catch_before = 0;
int catch_after = 0;
long I_WRAP_SONAME_FNNAME_ZZ(libcZdsoZd6, malloc)( long x )
{
int result = 0;
OrigFn fn;
catch_before += 1; //// break point 1
VALGRIND_GET_ORIG_FN(fn);
CALL_FN_W_W(result, fn, x); //// break point 2
catch_after += 3; //// break point3
result += 1;
return result ;
}
#### in prog.c
#include <stdio.h>
#include <stdlib.h>
extern int catch_before;
extern int catch_after;
int test2()
{ int * addr1 = 0;
int * addr2 = 0;
addr1 = (int *)malloc( 10 * sizeof(int));
addr2 = (int *)malloc( 10 * sizeof(int));
return (int)addr1 * (int)addr2;
}
int main()
{
return test2();
}
####### information of running gdb+vgdb
Breakpoint 1, 0x0000000000400928 in _vgw00000ZZ_libcZdsoZd6_malloc ()
(gdb) bt
#0 0x0000000000400928 in _vgw00000ZZ_libcZdsoZd6_malloc ()
#1 0x000000000040059f in test2 ()
#2 0x00000000004006da in main ()
(gdb) c
Continuing.
Breakpoint 2, 0x0000000000400961 in _vgw00000ZZ_libcZdsoZd6_malloc ()
(gdb) bt
#0 0x0000000000400961 in _vgw00000ZZ_libcZdsoZd6_malloc ()
#1 0x000000000040059f in test2 ()
#2 0x00000000004006da in main ()
(gdb) c
Continuing.
Breakpoint 1, 0x0000000000400928 in _vgw00000ZZ_libcZdsoZd6_malloc ()
(gdb) bt
#0 0x0000000000400928 in _vgw00000ZZ_libcZdsoZd6_malloc ()
#1 0x00000000004009af in _vgw00000ZZ_libcZdsoZd6_malloc ()
#2 0x000000000040059f in test2 ()
#3 0x00000000004006da in main ()
(gdb) c
Continuing.
Breakpoint 2, 0x0000000000400961 in _vgw00000ZZ_libcZdsoZd6_malloc ()
(gdb) bt
#0 0x0000000000400961 in _vgw00000ZZ_libcZdsoZd6_malloc ()
#1 0x00000000004009af in _vgw00000ZZ_libcZdsoZd6_malloc ()
#2 0x000000000040059f in test2 ()
#3 0x00000000004006da in main ()
(gdb) c
Continuing.
Breakpoint 3, 0x00000000004009c0 in _vgw00000ZZ_libcZdsoZd6_malloc ()
(gdb) bt
#0 0x00000000004009c0 in _vgw00000ZZ_libcZdsoZd6_malloc ()
#1 0x00000000004009af in _vgw00000ZZ_libcZdsoZd6_malloc ()
#2 0x000000000040059f in test2 ()
#3 0x00000000004006da in main ()
(gdb) c
Continuing.
Breakpoint 3, 0x00000000004009c0 in _vgw00000ZZ_libcZdsoZd6_malloc ()
(gdb) bt
#0 0x00000000004009c0 in _vgw00000ZZ_libcZdsoZd6_malloc ()
#1 0x000000000040059f in test2 ()
#2 0x00000000004006da in main ()
(gdb) c
Continuing.
Breakpoint 1, 0x0000000000400928 in _vgw00000ZZ_libcZdsoZd6_malloc ()
(gdb) bt
#0 0x0000000000400928 in _vgw00000ZZ_libcZdsoZd6_malloc ()
#1 0x00000000004005ad in test2 ()
#2 0x00000000004006da in main ()
(gdb) c
Continuing.
Breakpoint 2, 0x0000000000400961 in _vgw00000ZZ_libcZdsoZd6_malloc ()
(gdb) bt
#0 0x0000000000400961 in _vgw00000ZZ_libcZdsoZd6_malloc ()
#1 0x00000000004005ad in test2 ()
#2 0x00000000004006da in main ()
(gdb) c
Continuing.
Breakpoint 3, 0x00000000004009c0 in _vgw00000ZZ_libcZdsoZd6_malloc ()
(gdb) bt
#0 0x00000000004009c0 in _vgw00000ZZ_libcZdsoZd6_malloc ()
#1 0x00000000004005ad in test2 ()
#2 0x00000000004006da in main ()
shu...@hu...
Best Regards.
________________________________________
发件人: Philippe Waroquiers [phi...@sk...]
发送时间: 2015年4月2日 3:32
收件人: Shujunjun
抄送: val...@li...
主题: Re: [Valgrind-developers] Bugs when wrap "malloc" called at the first time.
You should get the original fn before doing anything else, to ensure
to follow the following user manual paragraph:
"VALGRIND_GET_ORIG_FN: once in the wrapper, the first priority is to
get hold of the address of the original (and any other supporting
information needed). This is stored in a value of opaque type OrigFn.
The information is acquired using VALGRIND_GET_ORIG_FN. It is crucial
to make this macro call before calling any other wrapped function in
the same thread."
You might e.g. imagine that sprintf is calling malloc to do its
work.
Unknown result might happen if you do not follow the above.
Once the above is done, you might use gdb+vgdb and debug your wrappers
when running under valgrind to e.g. see who is calling them when and why.
Philippe
On Wed, 2015-04-01 at 08:25 +0000, Shujunjun wrote:
> Hi,
> I use I_WRAP_SONAME_FNNAME_ZZ to wrap “malloc”,it's quite strange when
> the guest program call "malloc" at the first time.
> The first time "malloc" called in the "prog.c", it seems to call the
> "//block 1" code twice and call the "//block 2" twice in
> "test.wrap.sub.c".
> But the second "malloc" called in the "prog.c", it seems normally.
>
>
>
> PS. It's only appeared at shared library.
>
>
>
> Following is my test code and output.
>
>
> ######in test.wrap.sub.c
> #include <stdio.h>
> #include "valgrind.h"
> int catch_before = 0;
> int catch_after = 0;
> long I_WRAP_SONAME_FNNAME_ZZ(libcZdsoZd6, malloc)( long x )
> {
> int result = 0;
> char buffer[60];
> OrigFn fn;
>
> ////////////block 1
> catch_before += 1;
> sprintf(buffer, "----------- 111 wrap malloc: %x bytes, at:0x%x\n",
> x, result);
> write(1, buffer, strlen(buffer));
>
> VALGRIND_GET_ORIG_FN(fn);
> CALL_FN_W_W(result, fn, x);
>
> ////////////block 2
> (void) sprintf(buffer, "---------- 222 wrap malloc: %x bytes, at:0x%
> x\n", x, result);
> (void) write(1, buffer, strlen(buffer));
> catch_after += 3;
> result += 1;
>
> return result ;
> }
>
> #### in prog.c
> #include <stdio.h>
> #include <stdlib.h>
> extern int catch_before;
> extern int catch_after;
> int test2()
> { int * addr1 = 0;
> int * addr2 = 0;
>
> printf("1.1 catch:%d %d\n", catch_before, catch_after);
> addr1 = (int *)malloc( 10 * sizeof(int));
> printf("2.1 catch:%d %d addr:0x%x \n", catch_before, catch_after,
> addr1);
>
> printf("3.1 catch:%d %d\n", catch_before, catch_after);
> addr2 = (int *)malloc( 10 * sizeof(int));
> printf("4.1 catch:%d %d addr:0x%x \n", catch_before, catch_after,
> addr2);
> return (int)addr1 * (int)addr2;
> }
> int main()
> {
> return test2();
> }
>
> ########compile
> gcc -c -m32 prog.c -O0 -o prog.32.o
> gcc -o wrap.32.o -O0 -c -m32 test.wrap.sub.c
> gcc prog.32.o wrap.32.o -O0 -m32 -o prog.wrap.32.exe
> #########run with --tool=lackey or --tool=callgrind (eg. #valgrind
> --tool=lackey --trace-redir=yes ./prog.wrap.32.exe)
> 1.1 catch:0 0
> --12339-- REDIR: 0x40a7f50 (libc.so.6:malloc) redirected to 0x80487ce
> (malloc)
> ----------- 111 wrap malloc: 190 bytes, at:0x0
> ----------- 111 wrap malloc: 190 bytes, at:0x0
> ---------- 222 wrap malloc: 190 bytes, at:0x804b008
> ---------- 222 wrap malloc: 190 bytes, at:0x804b009
> 2.1 catch:2 6 addr:0x804b00a
> 3.1 catch:2 6
> ----------- 111 wrap malloc: 28 bytes, at:0x0
> ---------- 222 wrap malloc: 28 bytes, at:0x804b1a0
> 4.1 catch:3 9 addr:0x804b1a1
>
>
>
> shu...@hu...
>
> Best Regards.
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________ Valgrind-developers mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Philippe W. <phi...@sk...> - 2015-04-01 22:57:12
|
On Thu, 2015-04-02 at 00:41 +0200, Julian Seward wrote:
> On 01/04/15 21:25, Philippe Waroquiers wrote:
> > On Tue, 2015-03-31 at 15:28 -0300, Andres Tiraboschi wrote:
> >> But if you want to replace functions from pthread like helgrind and
> >> drd do you have to replace the client malloc/free
> >> I don't know why.
> > To my knowledge, there is no need to replace malloc/free to have
> > helgrind or drd working.
>
> Well, I think it is important, because both tools need to know when
> memory is freed and later re-allocated. Without that, they would report
> false races on memory that has been freed and then reallocated to a
> different thread. In effect the freeing marks the memory as un-tracked
> and causes them to "forget" what they know about it.
>
> Also, it helps generate better error messages. With malloc/free
> intercepting, we can generate address descriptions like "address X
> is N bytes inside a block of size M allocated at ..".
Yes for sure, for these tools to properly detect errors,
malloc replacement is highly recommended.
But the question discussed initially is: is it *mandatory*
to replace malloc/free/... if you want to wrap pthread functions
and not have a segmentation violation ?
I answered no, and "proved that" by telling that helgrind does
not crash when e.g. using it with tcmalloc and not using
--soname-synonyms=...
In such a case, malloc/tcmalloc is *not* replaced, but still
helgrind (or drd) will not crash.
So, in summary, the discussion status is:
1. it is not mandatory to replace malloc if you want to wrap
a pthread function
2. the segmentation violation encountered by Andres in
his small trial to wrap pthread is IMO not caused
by not replacing malloc. It is just that replacing malloc
bypasses the segv I believe.
Philippe
|
|
From: <sv...@va...> - 2015-04-01 22:51:15
|
Author: philippe
Date: Wed Apr 1 23:51:07 2015
New Revision: 15062
Log:
Add a test that triggers sector recycling
(cfr bug fix in revision 15058: without 15058, the below test
loops for ever).
Added:
trunk/none/tests/bigcode.stderr.exp
trunk/none/tests/bigcode.stdout.exp
trunk/none/tests/bigcode.vgtest
Modified:
trunk/none/tests/Makefile.am
Modified: trunk/none/tests/Makefile.am
==============================================================================
--- trunk/none/tests/Makefile.am (original)
+++ trunk/none/tests/Makefile.am Wed Apr 1 23:51:07 2015
@@ -68,6 +68,7 @@
ansi.stderr.exp ansi.vgtest \
args.stderr.exp args.stdout.exp args.vgtest \
async-sigs.stderr.exp async-sigs.stderr.exp-mips32 async-sigs.vgtest \
+ bigcode.vgtest bigcode.stderr.exp bigcode.stdout.exp \
bitfield1.stderr.exp bitfield1.vgtest \
bug129866.vgtest bug129866.stderr.exp bug129866.stdout.exp \
closeall.stderr.exp closeall.vgtest \
Added: trunk/none/tests/bigcode.stderr.exp
==============================================================================
--- trunk/none/tests/bigcode.stderr.exp (added)
+++ trunk/none/tests/bigcode.stderr.exp Wed Apr 1 23:51:07 2015
@@ -0,0 +1,2 @@
+
+
Added: trunk/none/tests/bigcode.stdout.exp
==============================================================================
--- trunk/none/tests/bigcode.stdout.exp (added)
+++ trunk/none/tests/bigcode.stdout.exp Wed Apr 1 23:51:07 2015
@@ -0,0 +1,2 @@
+mode 1: 20000 copies of f(), 1 reps
+....................result = -37457500
Added: trunk/none/tests/bigcode.vgtest
==============================================================================
--- trunk/none/tests/bigcode.vgtest (added)
+++ trunk/none/tests/bigcode.vgtest Wed Apr 1 23:51:07 2015
@@ -0,0 +1,8 @@
+# this test exercises m_transtab.c sector recycling
+# and sanity check when recycling sectors. To ensure we recycle
+# sectors, we put a small number of sectors.
+# use --stats=yes if you want to verify that the below still
+# recycles a (already used) sector.
+prog: ../../perf/bigcode
+args: 1
+vgopts: --num-transtab-sectors=2 --sanity-level=4
|
|
From: Julian S. <js...@ac...> - 2015-04-01 22:41:51
|
On 01/04/15 21:25, Philippe Waroquiers wrote: > On Tue, 2015-03-31 at 15:28 -0300, Andres Tiraboschi wrote: >> But if you want to replace functions from pthread like helgrind and >> drd do you have to replace the client malloc/free >> I don't know why. > To my knowledge, there is no need to replace malloc/free to have > helgrind or drd working. Well, I think it is important, because both tools need to know when memory is freed and later re-allocated. Without that, they would report false races on memory that has been freed and then reallocated to a different thread. In effect the freeing marks the memory as un-tracked and causes them to "forget" what they know about it. Also, it helps generate better error messages. With malloc/free intercepting, we can generate address descriptions like "address X is N bytes inside a block of size M allocated at ..". J |
|
From: Philippe W. <phi...@sk...> - 2015-04-01 21:03:11
|
On Wed, 2015-04-01 at 22:40 +0200, Matthias Schwarzott wrote: > > (the last command to show this gdb is connected to a V gdbsrv. > Ok, I did not try again for some time. Testing/validation/bug reports (and bug fixes if needed) welcome :). > >> Else I propose to add a monitor command to trigger the already > >> implemented core-dump writing of valgrind. > > It is intended to remove this capability to generate a core > > dump from inside valgrind, as this is fragile/missing some registers > > values/contains one single thread/... > What does that mean for valgrind alone? Will you really remove writing > core-dumps from the normal valgrind signal handlers? Ouch, no. I confused 2 pieces of code. > How should it react on signals that normally write core-dumps? It will continue to core dump as of today, because this core dump code will stay :). Philippe |
|
From: Philippe W. <phi...@sk...> - 2015-04-01 20:43:20
|
On Wed, 2015-04-01 at 17:23 -0300, Andres Tiraboschi wrote: > But in drd_malloc_wrappers.c for example if you comment > "VG_(needs_malloc_replacement)(drd_malloc, ..." in > DRD_(register_malloc_wrappers) when pthread_create is called you'll > have the following segmentation fault. > > --6540-- VG_USERREQ__CLIENT_CALL2: func=0x0 > ==6540== > ==6540== Process terminating with default action of signal 11 (SIGSEGV) > . > . > . > Segmentation fault (core dumped) Yes. This is because you are now removing a *part* of the functionality needed to replace malloc. Then malloc replacement still happens, and then it segv, because the call to VG_(needs_malloc_replacement) is the one that provides some info needed when malloc replacement happens. Malloc replacement is activated by another mechanism (LD_PRELOAD of an .so with specially crafted function names that the Valgrind debug info reader recognises). Replacement/wrapping of functions in Valgrind is non trivial. What you do above just makes it crash, as you have then a partially implemented replacement. Philippe |
|
From: Matthias S. <zz...@ge...> - 2015-04-01 20:40:15
|
Am 01.04.2015 um 22:04 schrieb Philippe Waroquiers: > On Wed, 2015-04-01 at 12:37 +0200, Matthias Schwarzott wrote: >> Hi! >> >> Sometimes I want to write a core-dump of the current status when I am in >> gdb attached to valgrind. >> But the gdb-command gcore does not work with vgdb. > ? > Here is works (gdb 7.9) > (gdb) gcore > Saved corefile core.42000 > (gdb) mo h > general valgrind monitor commands: > .... > (the last command to show this gdb is connected to a V gdbsrv. Ok, I did not try again for some time. > However, it looks like the core dump might not be fully functional: > (gdb) core core.42000 > [New LWP 14340] > warning: Error reading shared library list entry at 0x2118e0 > Program terminated with signal SIGTRAP, Trace/breakpoint trap. > #0 test () at trivialleak.c:8 > 8 leak = (void*)malloc( 1 ); > (gdb) bt > #0 test () at trivialleak.c:8 > #1 0x0804840f in main () at trivialleak.c:12 > (gdb) > > > (the shared lib list entry looks bizarre to me). > >> Else I propose to add a monitor command to trigger the already >> implemented core-dump writing of valgrind. > It is intended to remove this capability to generate a core > dump from inside valgrind, as this is fragile/missing some registers > values/contains one single thread/... What does that mean for valgrind alone? Will you really remove writing core-dumps from the normal valgrind signal handlers? How should it react on signals that normally write core-dumps? Regards Matthias |
|
From: Andres T. <and...@ta...> - 2015-04-01 20:23:33
|
But in drd_malloc_wrappers.c for example if you comment "VG_(needs_malloc_replacement)(drd_malloc, ..." in DRD_(register_malloc_wrappers) when pthread_create is called you'll have the following segmentation fault. --6540-- VG_USERREQ__CLIENT_CALL2: func=0x0 ==6540== ==6540== Process terminating with default action of signal 11 (SIGSEGV) . . . Segmentation fault (core dumped) This the same segmentation fault I was having and I solved replacing malloc/free. I have no idea why this. 2015-04-01 17:11 GMT-03:00 Philippe Waroquiers <phi...@sk...>: > On Wed, 2015-04-01 at 16:37 -0300, Andres Tiraboschi wrote: >> Actually they replace malloc(at least in valgrind 3.10.1). For example >> in the source of drd look at drd_malloc_wrappers.c > No. > They do something so that *potentially* malloc/free/... are replaced. > But by default, the replacement will *not* happen for a static malloc > or for a tcmalloc or any other alternate malloc library. > > So, that makes me believe there is no need to have malloc replaced > to have this tools working (with reduced functionality of course, > because they will not observe any malloc activity). > > So, I still believe the segv you are seeing is not related to > 'non replacement of malloc/free/...' but that you have another > problem. > > Philippe > >> >> 2015-04-01 16:25 GMT-03:00 Philippe Waroquiers <phi...@sk...>: >> > On Tue, 2015-03-31 at 15:28 -0300, Andres Tiraboschi wrote: >> >> But if you want to replace functions from pthread like helgrind and >> >> drd do you have to replace the client malloc/free >> >> I don't know why. >> > To my knowledge, there is no need to replace malloc/free to have >> > helgrind or drd working. >> > >> > A "proof" of that is that if you use an alternate malloc lib (e.g. >> > tcmalloc) or a static malloc library, >> > by default, no replacement will be done. Still these tools do >> > not crash. >> > >> > So, the segv you are seeing is I believe not related to >> > 'non replacement of malloc/free/...'. >> > Replacing malloc might just by chance bypass the real underlying >> > problem. >> > >> > Philippe >> > >> > >> >> >> >> 2015-03-30 15:26 GMT-03:00 Philippe Waroquiers <phi...@sk...>: >> >> > On Mon, 2015-03-30 at 15:10 -0300, Andres Tiraboschi wrote: >> >> >> I was making a tool for valgrind for measuring things related with threads. >> >> >> I made it work but for that, surprisingly I had to replace mallocs and >> >> >> frees with VG_(needs_malloc_replacement). >> >> >> If I don't do this I get a segmentation fault. >> >> >> >> >> >> In drd if I make that the tool doens't replace the mallocs and frees >> >> >> there is the same segmentation fault. >> >> >> >> >> >> I couldn't find any documentation about this, so I don't know if this >> >> >> is supposed to be like this or is a bug. >> >> > No, it is not mandatory to replace (client) malloc/free. >> >> > >> >> > There are several tools that do not replace malloc/free. >> >> > E.g. cachegrind and callgrind are not replacing client malloc/free. >> >> > >> >> > Philippe >> >> > >> >> > >> > >> > > > |
|
From: <sv...@va...> - 2015-04-01 20:18:33
|
Author: philippe
Date: Wed Apr 1 21:18:26 2015
New Revision: 3116
Log:
Add the standard end of the file marker used elsewhere
Modified:
trunk/priv/multiarch_main_main.c
Modified: trunk/priv/multiarch_main_main.c
==============================================================================
--- trunk/priv/multiarch_main_main.c (original)
+++ trunk/priv/multiarch_main_main.c Wed Apr 1 21:18:26 2015
@@ -67,3 +67,7 @@
#define VEXMULTIARCH 1
#include "main_main.c"
+
+/*---------------------------------------------------------------*/
+/*--- end multiarch_main_main.c ---*/
+/*---------------------------------------------------------------*/
|
|
From: Philippe W. <phi...@sk...> - 2015-04-01 20:10:43
|
On Wed, 2015-04-01 at 16:37 -0300, Andres Tiraboschi wrote: > Actually they replace malloc(at least in valgrind 3.10.1). For example > in the source of drd look at drd_malloc_wrappers.c No. They do something so that *potentially* malloc/free/... are replaced. But by default, the replacement will *not* happen for a static malloc or for a tcmalloc or any other alternate malloc library. So, that makes me believe there is no need to have malloc replaced to have this tools working (with reduced functionality of course, because they will not observe any malloc activity). So, I still believe the segv you are seeing is not related to 'non replacement of malloc/free/...' but that you have another problem. Philippe > > 2015-04-01 16:25 GMT-03:00 Philippe Waroquiers <phi...@sk...>: > > On Tue, 2015-03-31 at 15:28 -0300, Andres Tiraboschi wrote: > >> But if you want to replace functions from pthread like helgrind and > >> drd do you have to replace the client malloc/free > >> I don't know why. > > To my knowledge, there is no need to replace malloc/free to have > > helgrind or drd working. > > > > A "proof" of that is that if you use an alternate malloc lib (e.g. > > tcmalloc) or a static malloc library, > > by default, no replacement will be done. Still these tools do > > not crash. > > > > So, the segv you are seeing is I believe not related to > > 'non replacement of malloc/free/...'. > > Replacing malloc might just by chance bypass the real underlying > > problem. > > > > Philippe > > > > > >> > >> 2015-03-30 15:26 GMT-03:00 Philippe Waroquiers <phi...@sk...>: > >> > On Mon, 2015-03-30 at 15:10 -0300, Andres Tiraboschi wrote: > >> >> I was making a tool for valgrind for measuring things related with threads. > >> >> I made it work but for that, surprisingly I had to replace mallocs and > >> >> frees with VG_(needs_malloc_replacement). > >> >> If I don't do this I get a segmentation fault. > >> >> > >> >> In drd if I make that the tool doens't replace the mallocs and frees > >> >> there is the same segmentation fault. > >> >> > >> >> I couldn't find any documentation about this, so I don't know if this > >> >> is supposed to be like this or is a bug. > >> > No, it is not mandatory to replace (client) malloc/free. > >> > > >> > There are several tools that do not replace malloc/free. > >> > E.g. cachegrind and callgrind are not replacing client malloc/free. > >> > > >> > Philippe > >> > > >> > > > > > |
|
From: <sv...@va...> - 2015-04-01 20:06:33
|
Author: philippe
Date: Wed Apr 1 21:06:26 2015
New Revision: 15061
Log:
Commit the VEX makefile changes needed to have the libvexmultiarch
build and installed by default
Modified:
trunk/Makefile.vex.am
Modified: trunk/Makefile.vex.am
==============================================================================
--- trunk/Makefile.vex.am (original)
+++ trunk/Makefile.vex.am Wed Apr 1 21:06:26 2015
@@ -99,12 +99,18 @@
rm -f auxprogs/genoffsets.s
#----------------------------------------------------------------------------
-# libvex-<platform>.a
+# libvex-<platform>-<os>.a : containing all VEX objects, including
+# a main_main.o compiled in single arch (guest==host).
+# libvexmultiarch-<platform>-<os>.a, only containing multiarch_main_main.o,
+# which is main_main.c compiled so that any guest/host combination
+# can be done at runtime.
#----------------------------------------------------------------------------
-pkglib_LIBRARIES = libvex-@VGCONF_ARCH_PRI@-@VGCONF_OS@.a
+pkglib_LIBRARIES = libvex-@VGCONF_ARCH_PRI@-@VGCONF_OS@.a \
+ libvexmultiarch-@VGCONF_ARCH_PRI@-@VGCONF_OS@.a
if VGCONF_HAVE_PLATFORM_SEC
-pkglib_LIBRARIES += libvex-@VGCONF_ARCH_SEC@-@VGCONF_OS@.a
+pkglib_LIBRARIES += libvex-@VGCONF_ARCH_SEC@-@VGCONF_OS@.a \
+ libvexmultiarch-@VGCONF_ARCH_SEC@-@VGCONF_OS@.a
endif
LIBVEX_SOURCES_COMMON = \
@@ -153,6 +159,8 @@
priv/host_mips_defs.c \
priv/host_mips_isel.c
+LIBVEXMULTIARCH_SOURCES = priv/multiarch_main_main.c
+
LIBVEX_CFLAGS = \
-Wbad-function-cast \
-fstrict-aliasing
@@ -170,3 +178,18 @@
$(AM_CFLAGS_@VGCONF_PLATFORM_SEC_CAPS@) $(LIBVEX_CFLAGS)
endif
+libvexmultiarch_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_SOURCES = \
+ $(LIBVEXMULTIARCH_SOURCES)
+libvexmultiarch_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_CPPFLAGS = \
+ $(AM_CPPFLAGS_@VGCONF_PLATFORM_PRI_CAPS@) -Ipriv
+libvexmultiarch_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_CFLAGS = \
+ $(AM_CFLAGS_@VGCONF_PLATFORM_PRI_CAPS@) $(LIBVEX_CFLAGS)
+if VGCONF_HAVE_PLATFORM_SEC
+libvexmultiarch_@VGCONF_ARCH_SEC@_@VGCONF_OS@_a_SOURCES = \
+ $(LIBVEXMULTIARCH_SOURCES)
+libvexmultiarch_@VGCONF_ARCH_SEC@_@VGCONF_OS@_a_CPPFLAGS = \
+ $(AM_CPPFLAGS_@VGCONF_PLATFORM_SEC_CAPS@) -Ipriv
+libvexmultiarch_@VGCONF_ARCH_SEC@_@VGCONF_OS@_a_CFLAGS = \
+ $(AM_CFLAGS_@VGCONF_PLATFORM_SEC_CAPS@) $(LIBVEX_CFLAGS)
+endif
+
|
|
From: <sv...@va...> - 2015-04-01 20:06:00
|
Author: philippe
Date: Wed Apr 1 21:05:50 2015
New Revision: 3115
Log:
Improve comments, add the copyright notice
Modified:
trunk/priv/multiarch_main_main.c
Modified: trunk/priv/multiarch_main_main.c
==============================================================================
--- trunk/priv/multiarch_main_main.c (original)
+++ trunk/priv/multiarch_main_main.c Wed Apr 1 21:05:50 2015
@@ -1,2 +1,69 @@
+/*---------------------------------------------------------------*/
+/*--- Begin multiarch_main_main.c ---*/
+/*---------------------------------------------------------------*/
+
+/*
+ This file is part of Valgrind, a dynamic binary instrumentation
+ framework.
+
+ Copyright (C) 2015 Philippe Waroquiers
+
+ This program is free software; you can redistribute it and/or
+ modify it under the terms of the GNU General Public License as
+ published by the Free Software Foundation; either version 2 of the
+ License, or (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ 02110-1301, USA.
+
+ The GNU General Public License is contained in the file COPYING.
+
+ Neither the names of the U.S. Department of Energy nor the
+ University of California nor the names of its contributors may be
+ used to endorse or promote products derived from this software
+ without prior written permission.
+*/
+
+/* This file is used to have main_main.c compiled with VEXMULTIARCH
+ defined, so that all host and guest arch are callable from LibVEX_Translate
+ and other functions defined in main_main.c.
+ The resulting object file will be put in libvexmultiarch-<platform>-os>.a.
+
+ The valgrind tools are making the assumption that host and guest are
+ the same. So, no need to drag the full set of archs when
+ linking a tool.
+ The VEX library is nicely split in arch independent and arch dependent
+ objects. Only main_main.c is dragging the various arch specific files.
+ So, main_main.c (the main entry point of the VEX library) is compiled
+ only for the current guest/host arch.
+
+ This file ensures we recompile main_main.c with all archs activated.
+
+ So, a VEX user can decide (at link time) to use a 'single arch' VEX lib,
+ or to use a multiarch VEX lib.
+ If t1.o is a 'main' that calls LibVEX_Translate, then
+ to link with a single arch VEX lib, use e.g. the following :
+ gcc -o t1single t1.o -LInst/lib/valgrind -lvex-amd64-linux -lgcc
+
+ to link with a multi arch VEX lib, you must insert
+ -lvexmultiarch-amd64-linux *before* -lvex-amd64-linux
+ i.e;
+ gcc -o t1multi t1.o \
+ -LInst/lib/valgrind -lvexmultiarch-x86-linux -lvex-amd64-linux -lgcc
+
+ t1single will only be able to translate from amd64 to amd64.
+ t1multi will be able to translate from any arch supported by VEX
+ to any other arch supported by VEX.
+ Note however that multiarch support is experimental and poorly
+ or not tested.
+*/
+
#define VEXMULTIARCH 1
#include "main_main.c"
|
|
From: Philippe W. <phi...@sk...> - 2015-04-01 20:03:56
|
On Wed, 2015-04-01 at 12:37 +0200, Matthias Schwarzott wrote: > Hi! > > Sometimes I want to write a core-dump of the current status when I am in > gdb attached to valgrind. > But the gdb-command gcore does not work with vgdb. ? Here is works (gdb 7.9) (gdb) gcore Saved corefile core.42000 (gdb) mo h general valgrind monitor commands: .... (the last command to show this gdb is connected to a V gdbsrv. However, it looks like the core dump might not be fully functional: (gdb) core core.42000 [New LWP 14340] warning: Error reading shared library list entry at 0x2118e0 Program terminated with signal SIGTRAP, Trace/breakpoint trap. #0 test () at trivialleak.c:8 8 leak = (void*)malloc( 1 ); (gdb) bt #0 test () at trivialleak.c:8 #1 0x0804840f in main () at trivialleak.c:12 (gdb) (the shared lib list entry looks bizarre to me). > Else I propose to add a monitor command to trigger the already > implemented core-dump writing of valgrind. It is intended to remove this capability to generate a core dump from inside valgrind, as this is fragile/missing some registers values/contains one single thread/... > My experimental patch adds a monitor command "v.do core". > It can be called multiple times and will just write multiple coredumps > vgcore.PID.NO > > Does gdbserver know about the currently selected thread in gdb? GDB typically has to indicate to gdbsrv on which thread to work. > > I will post this patch the next days. I think it would be better to see how gcore works (e.g. with multiple threads), and if needed fix the problems if they are some, rather than to invest on the valgrind core dump feature that it on its way out (if I have the time to cleanup in 3.11 the --db-attach that has been announced obsolete in 3.10) Philippe |
|
From: Andres T. <and...@ta...> - 2015-04-01 19:37:12
|
Actually they replace malloc(at least in valgrind 3.10.1). For example in the source of drd look at drd_malloc_wrappers.c 2015-04-01 16:25 GMT-03:00 Philippe Waroquiers <phi...@sk...>: > On Tue, 2015-03-31 at 15:28 -0300, Andres Tiraboschi wrote: >> But if you want to replace functions from pthread like helgrind and >> drd do you have to replace the client malloc/free >> I don't know why. > To my knowledge, there is no need to replace malloc/free to have > helgrind or drd working. > > A "proof" of that is that if you use an alternate malloc lib (e.g. > tcmalloc) or a static malloc library, > by default, no replacement will be done. Still these tools do > not crash. > > So, the segv you are seeing is I believe not related to > 'non replacement of malloc/free/...'. > Replacing malloc might just by chance bypass the real underlying > problem. > > Philippe > > >> >> 2015-03-30 15:26 GMT-03:00 Philippe Waroquiers <phi...@sk...>: >> > On Mon, 2015-03-30 at 15:10 -0300, Andres Tiraboschi wrote: >> >> I was making a tool for valgrind for measuring things related with threads. >> >> I made it work but for that, surprisingly I had to replace mallocs and >> >> frees with VG_(needs_malloc_replacement). >> >> If I don't do this I get a segmentation fault. >> >> >> >> In drd if I make that the tool doens't replace the mallocs and frees >> >> there is the same segmentation fault. >> >> >> >> I couldn't find any documentation about this, so I don't know if this >> >> is supposed to be like this or is a bug. >> > No, it is not mandatory to replace (client) malloc/free. >> > >> > There are several tools that do not replace malloc/free. >> > E.g. cachegrind and callgrind are not replacing client malloc/free. >> > >> > Philippe >> > >> > > > |
|
From: Philippe W. <phi...@sk...> - 2015-04-01 19:31:55
|
You should get the original fn before doing anything else, to ensure
to follow the following user manual paragraph:
"VALGRIND_GET_ORIG_FN: once in the wrapper, the first priority is to
get hold of the address of the original (and any other supporting
information needed). This is stored in a value of opaque type OrigFn.
The information is acquired using VALGRIND_GET_ORIG_FN. It is crucial
to make this macro call before calling any other wrapped function in
the same thread."
You might e.g. imagine that sprintf is calling malloc to do its
work.
Unknown result might happen if you do not follow the above.
Once the above is done, you might use gdb+vgdb and debug your wrappers
when running under valgrind to e.g. see who is calling them when and why.
Philippe
On Wed, 2015-04-01 at 08:25 +0000, Shujunjun wrote:
> Hi,
> I use I_WRAP_SONAME_FNNAME_ZZ to wrap “malloc”,it's quite strange when
> the guest program call "malloc" at the first time.
> The first time "malloc" called in the "prog.c", it seems to call the
> "//block 1" code twice and call the "//block 2" twice in
> "test.wrap.sub.c".
> But the second "malloc" called in the "prog.c", it seems normally.
>
>
>
> PS. It's only appeared at shared library.
>
>
>
> Following is my test code and output.
>
>
> ######in test.wrap.sub.c
> #include <stdio.h>
> #include "valgrind.h"
> int catch_before = 0;
> int catch_after = 0;
> long I_WRAP_SONAME_FNNAME_ZZ(libcZdsoZd6, malloc)( long x )
> {
> int result = 0;
> char buffer[60];
> OrigFn fn;
>
> ////////////block 1
> catch_before += 1;
> sprintf(buffer, "----------- 111 wrap malloc: %x bytes, at:0x%x\n",
> x, result);
> write(1, buffer, strlen(buffer));
>
> VALGRIND_GET_ORIG_FN(fn);
> CALL_FN_W_W(result, fn, x);
>
> ////////////block 2
> (void) sprintf(buffer, "---------- 222 wrap malloc: %x bytes, at:0x%
> x\n", x, result);
> (void) write(1, buffer, strlen(buffer));
> catch_after += 3;
> result += 1;
>
> return result ;
> }
>
> #### in prog.c
> #include <stdio.h>
> #include <stdlib.h>
> extern int catch_before;
> extern int catch_after;
> int test2()
> { int * addr1 = 0;
> int * addr2 = 0;
>
> printf("1.1 catch:%d %d\n", catch_before, catch_after);
> addr1 = (int *)malloc( 10 * sizeof(int));
> printf("2.1 catch:%d %d addr:0x%x \n", catch_before, catch_after,
> addr1);
>
> printf("3.1 catch:%d %d\n", catch_before, catch_after);
> addr2 = (int *)malloc( 10 * sizeof(int));
> printf("4.1 catch:%d %d addr:0x%x \n", catch_before, catch_after,
> addr2);
> return (int)addr1 * (int)addr2;
> }
> int main()
> {
> return test2();
> }
>
> ########compile
> gcc -c -m32 prog.c -O0 -o prog.32.o
> gcc -o wrap.32.o -O0 -c -m32 test.wrap.sub.c
> gcc prog.32.o wrap.32.o -O0 -m32 -o prog.wrap.32.exe
> #########run with --tool=lackey or --tool=callgrind (eg. #valgrind
> --tool=lackey --trace-redir=yes ./prog.wrap.32.exe)
> 1.1 catch:0 0
> --12339-- REDIR: 0x40a7f50 (libc.so.6:malloc) redirected to 0x80487ce
> (malloc)
> ----------- 111 wrap malloc: 190 bytes, at:0x0
> ----------- 111 wrap malloc: 190 bytes, at:0x0
> ---------- 222 wrap malloc: 190 bytes, at:0x804b008
> ---------- 222 wrap malloc: 190 bytes, at:0x804b009
> 2.1 catch:2 6 addr:0x804b00a
> 3.1 catch:2 6
> ----------- 111 wrap malloc: 28 bytes, at:0x0
> ---------- 222 wrap malloc: 28 bytes, at:0x804b1a0
> 4.1 catch:3 9 addr:0x804b1a1
>
>
>
> shu...@hu...
>
> Best Regards.
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________ Valgrind-developers mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|