valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] [Valgrind-developers] Valgrind-3.21.0.RC1 is available for testing

[Nicholas N. <n.n...@gm...>]

Hi,

My plans for the release:

   - I have one more significant improvement to `cg_annotate` to come,
   which will add merge and diff capability to it, in a way that is better
   than the merge/diff capability provided by `cg_merge` and `cg_diff`.
   - I need to update the Cachegrind docs and the NEWS file for all the
   changes I've made.

I know these will be happening late in the release cycle, but because it's
all Python code it should require less testing. The likelihood of
platform-specific differences in behaviour is much lower than in most other
code within Valgrind.

Nick

On Sat, 15 Apr 2023 at 12:07, Mark Wielaard <ma...@kl...> wrote:

> An RC1 tarball for 3.21.0 is now available at
> https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2
> (md5sum = a3c7eeff47262cecdf5f1d68b38710b7)
> (sha1sum = 46fc5898415001e045abc1b4e2909a41144ed9c4)
> https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2.asc
>
> Please give it a try in configurations that are important for you and
> report any problems you have, either on this mailing list, or
> (preferably) via our bug tracker at
> https://bugs.kde.org/enter_bug.cgi?product=valgrind
>
> There are still some patches being reviewed and a RC2 will appear end
> of next week.  If nothing critical emerges after that, a final release
> will happen on Friday 28 April.
>
>
>
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>

[Valgrind-users] Valgrind-3.21.0.RC1 is available for testing

[Mark W. <ma...@kl...>]

An RC1 tarball for 3.21.0 is now available at
https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2
(md5sum = a3c7eeff47262cecdf5f1d68b38710b7)
(sha1sum = 46fc5898415001e045abc1b4e2909a41144ed9c4)
https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2.asc

Please give it a try in configurations that are important for you and
report any problems you have, either on this mailing list, or
(preferably) via our bug tracker at
https://bugs.kde.org/enter_bug.cgi?product=valgrind

There are still some patches being reviewed and a RC2 will appear end
of next week.  If nothing critical emerges after that, a final release
will happen on Friday 28 April.

[Valgrind-users] A bit more (pre-release) automation

[Mark W. <ma...@kl...>]

Hi,

Working towards a new release (3.21.0 currently planned for April 28)
there is a bit more automation to show pre-releases and documentation:

https://snapshots.sourceware.org/valgrind/trunk/

Every 15 minutes a buildbot will check for new commits and create a
dist, html manual pages and documentation downloads from latest git
trunk (currently the git master branch, after the release we'll switch
to using the main branch).

Be careful, these aren't official releases, it is as if getting a
random git checkout, but hopefully it is useful to see what is coming
and have the latest (draft) documentation for new features for the
next release. If you try these out please explicitly mention which
snapshot you used in any bug reports.

Cheers,

Mark

Re: [Valgrind-users] RFC: changing Cachegrind default to `--cache-sim=no`

[David F. <fa...@kd...>]

On mardi 4 avril 2023 12:11:18 CEST Nicholas Nethercote wrote:
> On Tue, 4 Apr 2023 at 19:24, David Faure <fa...@kd...> wrote:
> > But then, with no cache simulation and no call stacks, what's left in
> > `cachegrind --cache-sim=no`?
> 
> From the email that started this thread:
> 
> If you run with `--cache-sim=no` then the cache simulation is disabled and
> > you just get one event: Ir. (This is "instruction cache reads", which is
> > equivalent to "instructions executed".)

Ah, right, sorry.

So to summarize the big picture:
cachegrind -> instructions count, without call stacks, useful for overall numbers or with cg_annotate
callgrind -> instructions count, with call stacks, best viewed in kcachegrind


I wish those two could do cycles and not just instructions, but I guess this requires a good cache simulator again, back to square one ;)
(perf does cycles, but doesn't give exact number of method calls, that's one benefit of cachegrind/callgrind)

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: [Valgrind-users] RFC: changing Cachegrind default to `--cache-sim=no`

[Nicholas N. <n.n...@gm...>]

On Tue, 4 Apr 2023 at 19:24, David Faure <fa...@kd...> wrote:

>
> But then, with no cache simulation and no call stacks, what's left in
> `cachegrind --cache-sim=no`?
>

>From the email that started this thread:

If you run with `--cache-sim=no` then the cache simulation is disabled and
> you just get one event: Ir. (This is "instruction cache reads", which is
> equivalent to "instructions executed".)
>

Re: [Valgrind-users] RFC: changing Cachegrind default to `--cache-sim=no`

[David F. <fa...@kd...>]

On lundi 3 avril 2023 23:46:46 CEST Nicholas Nethercote wrote:
> On Mon, 3 Apr 2023 at 21:36, David Faure <fa...@kd...> wrote:
> > But then, what's the difference between `cachegrind --cache-sim=no`
> > and `callgrind`?
> > 
> > https://accu.org/journals/overload/20/111/floyd_1886/ says
> > "The main differences are that Callgrind has more information about the
> > callstack whilst cachegrind gives more information about cache hit rates."
> > 
> > Wouldn't one want callstacks? (if this means stack traces).
> > I know I must be missing something, thanks for enlightening me.
> 
> Callgrind is a forked and extended version of Cachegrind. It also simulates
> a cache, with a slightly different simulation to Cachegrind's. The fact
> that both tools exist is due to historical reasons; if starting from
> scratch today you wouldn't deliberately split them.

Thanks for the information. This is indeed confusing - like anything that is 
"due to historical reasons" ;-)

> Call stacks are often useful (I regularly use Callgrind as well as
> Cachegrind) but they aren't always necessary. Without them, Cachegrind runs
> faster than Callgrind and produces smaller data files. Cachegrind also
> supports diffing and merging different files, while Callgrind does not.

OK. I thought call stacks were mandatory for any tool to be useful
(they certainly are for KCachegrind (*)), but I now found the documentation on 
cg_annotate.

But then, with no cache simulation and no call stacks, what's left in 
`cachegrind --cache-sim=no`?


(*) This naming adds to the confusion: kcachegrind requires callgrind, it 
can't work with cachegrind... I know, historical reasons :-)

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: [Valgrind-users] RFC: proposal to remove user annotation from `cg_annotate`

[Nicholas N. <n.n...@gm...>]

There were no objections, and I have now removed user annotations from
`cg_annotate`.

Nick

On Wed, 29 Mar 2023 at 09:03, Nicholas Nethercote <n.n...@gm...>
wrote:

> Hi,
>
> I recently rewrote `cg_annotate`, `cg_diff`, and `cg_merge` in Python. The
> old versions were written in Perl, Perl, and C, respectively. The new
> versions are much nicer and easier to modify, and I have various ideas for
> improving `cg_annotate`. This email is about one of those ideas.
>
> A typical way to invoke `cg_annotate` is like this:
>
> > cg_annotate cachegrind.out.12345
>
> This implies `--auto=yes`, which requests line-by-line "auto-annotation"
> of source files. I.e. `cg_annotate` will automatically annotate all files
> in the profile that meet the significance threshold.
>
> It's also possible to do something like this:
>
> > cg_annotate --auto=no cachegrind.out.12345 a.c b.c
>
> Which instead requests "user annotation" of the files `a.c` and `b.c`.
>
> My thesis is that auto-annotation suffices in practice for all reasonable
> use cases, and that user annotation is unnecessary and can be removed.
>
> When I first wrote `cg_annotate` in 2002, only user annotation was
> implemented. Shortly after, I added the `--auto={yes,no}` option. Since
> then I've never used user annotation, and I suspect nobody else has either.
> User annotation is ok when dealing with tiny programs, but as soon as you
> are profiling a program with more than a handful of source files it becomes
> impractical.
>
> The only possible use cases I can think of for user annotation are as
> follows.
>
>    - If you want to see a particular file(s) annotated but you don't want
>    to see any others, then you can use user annotation in combination with
>    `--auto=no`. But it's trivial to search through the output for the
>    particular file, so this doesn't seem important.
>    - If the path to a file is somehow really messed up in the debug info,
>    it might be possible that auto-annotation would fail to find it, but user
>    annotation could find it, possibly in combination with `-I`. But this seems
>    unlikely. Some basic testing shows that gcc, clang and rustc all default to
>    using full paths in debug info. gcc supports `-fdebug-prefix-map` but that
>    seems to mostly be used for changing full paths to relative paths, which
>    will still work fine.
>
> Removing user annotation would (a) simplify the code and docs, and (b)
> enable the possibility of moving the merge functionality from `cg_merge`
> into `cg_annotate`, by allowing the user to specify multiple cachegrind.out
> files as input.
>
> So: is anybody using user annotation? Does anybody see any problems with
> this proposal?
>
> Thanks.
>
> Nick
>

Re: [Valgrind-users] RFC: changing Cachegrind default to `--cache-sim=no`

[Nicholas N. <n.n...@gm...>]

On Mon, 3 Apr 2023 at 21:36, David Faure <fa...@kd...> wrote:

>
> But then, what's the difference between `cachegrind --cache-sim=no`
> and `callgrind`?
>
> https://accu.org/journals/overload/20/111/floyd_1886/ says
> "The main differences are that Callgrind has more information about the
> callstack whilst cachegrind gives more information about cache hit rates."
>
> Wouldn't one want callstacks? (if this means stack traces).
> I know I must be missing something, thanks for enlightening me.
>

Callgrind is a forked and extended version of Cachegrind. It also simulates
a cache, with a slightly different simulation to Cachegrind's. The fact
that both tools exist is due to historical reasons; if starting from
scratch today you wouldn't deliberately split them.

Call stacks are often useful (I regularly use Callgrind as well as
Cachegrind) but they aren't always necessary. Without them, Cachegrind runs
faster than Callgrind and produces smaller data files. Cachegrind also
supports diffing and merging different files, while Callgrind does not.

Nick

Re: [Valgrind-users] RFC: changing Cachegrind default to `--cache-sim=no`

[David F. <fa...@kd...>]

[removing valgrind-developers, since I guess I can't post there]

On lundi 3 avril 2023 11:29:25 CEST Nicholas Nethercote wrote:
> I have been using `--cache-sim=no` almost exclusively for a long time. The
> cache simulation done by Valgrind is an approximation of the memory
> hierarchy of a 2002 AMD Athlon processor. Its accuracy for a modern memory
> hierarchy with three levels of cache, prefetching, non-LRU replacement, and
> who-knows-what-else is likely to be low. If you want to accurately know
> about cache behaviour you'd be much better off using hardware counters via
> `perf` or some other profiler.
> 
> But `--cache-sim=no` is still very useful because instruction execution
> counts are still very useful.
> 
> Therefore, I propose changing the default to `--cache-sim=no`. Does anyone
> have any objections to this?

I agree that simulating a cache from 2002 isn't very useful.

But then, what's the difference between `cachegrind --cache-sim=no`
and `callgrind`?

https://accu.org/journals/overload/20/111/floyd_1886/ says
"The main differences are that Callgrind has more information about the 
callstack whilst cachegrind gives more information about cache hit rates."

Wouldn't one want callstacks? (if this means stack traces).
I know I must be missing something, thanks for enlightening me.

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr
Working on KDE Frameworks 5

[Valgrind-users] RFC: changing Cachegrind default to `--cache-sim=no`

[Nicholas N. <n.n...@gm...>]

Hi,

Cachegrind has an option `--cache-sim`.

If you run with `--cache-sim=yes` (the default) it tells it Cachegrind to
do a full cache simulation with lots of events: Ir, I1mr, ILmr, Dr, D1mr,
DLmr, Dw, D1mw, DLmw.

If you run with `--cache-sim=no` then the cache simulation is disabled and
you just get one event: Ir. (This is "instruction cache reads", which is
equivalent to "instructions executed".)

I have been using `--cache-sim=no` almost exclusively for a long time. The
cache simulation done by Valgrind is an approximation of the memory
hierarchy of a 2002 AMD Athlon processor. Its accuracy for a modern memory
hierarchy with three levels of cache, prefetching, non-LRU replacement, and
who-knows-what-else is likely to be low. If you want to accurately know
about cache behaviour you'd be much better off using hardware counters via
`perf` or some other profiler.

But `--cache-sim=no` is still very useful because instruction execution
counts are still very useful.

Therefore, I propose changing the default to `--cache-sim=no`. Does anyone
have any objections to this?

Thanks.

Nick

Re: [Valgrind-users] about a stack fill option (as for malloc-fill and free-fill)

[Paul F. <pj...@wa...>]

On 29-03-23 04:41, John Reiser wrote:
>>>      Could it be possible to add an option like --heap-up-fill 
>>> --heap-down-fill (like for stack with malloc), that fills heap memory 
>>> with a specified values (when entering a function and leave a function)?
> 
>> tl;dr 2
>>
>> See
>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2723r0.html
> 
> The value zero is the worst possible value to use for such initialization,
> from the viewpoint of quickly producing better software by discovering
> and identifying bugs sooner.  Using the value zero tends to hide many bugs.
> 
> A much better value is 0x8181...81.  This value is non-zero, odd, negative
> as a signed integer, a very unlikely floating-point value, very often
> not a valid pointer value, and instantly recognizable in any dump of 
> memory.
> It was used to great success as the "core constant" (the value of 
> uninitialized
> RAM) by the Michigan Terminal System for IBM 360/67 and successors,
> from the early 1970s (50 years ago!) until the demise of MTS around 2000.

Hi John

The value 0 isn't all bad.

I quite often write code that uses enums that start with KIND_INVALID so 
then I can write asserts like assert(kind != KIND_INVALID);

0 is also the NULL pointer so if your code defends against NULL it will 
at least not crash. I agree with you about early detection of errors - 
in a previous job we had loads of "pass the parcel" code that just 
ignored errors and returned from functions without reporting an error. 
It was a nightmare to debug,

The value used with 'pattern' is 0xAA which isn't too bad either - 
fairly well known as being a test pattern.

A+
Paul

Re: [Valgrind-users] about a stack fill option (as for malloc-fill and free-fill)

[John R. <jr...@bi...>]

>>      Could it be possible to add an option like --heap-up-fill --heap-down-fill (like for stack with malloc), that fills heap memory with a specified values (when entering a function and leave a function)?

> tl;dr 2
> 
> See
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2723r0.html

The value zero is the worst possible value to use for such initialization,
from the viewpoint of quickly producing better software by discovering
and identifying bugs sooner.  Using the value zero tends to hide many bugs.

A much better value is 0x8181...81.  This value is non-zero, odd, negative
as a signed integer, a very unlikely floating-point value, very often
not a valid pointer value, and instantly recognizable in any dump of memory.
It was used to great success as the "core constant" (the value of uninitialized
RAM) by the Michigan Terminal System for IBM 360/67 and successors,
from the early 1970s (50 years ago!) until the demise of MTS around 2000.

[Valgrind-users] RFC: proposal to remove user annotation from `cg_annotate`

[Nicholas N. <n.n...@gm...>]

Hi,

I recently rewrote `cg_annotate`, `cg_diff`, and `cg_merge` in Python. The
old versions were written in Perl, Perl, and C, respectively. The new
versions are much nicer and easier to modify, and I have various ideas for
improving `cg_annotate`. This email is about one of those ideas.

A typical way to invoke `cg_annotate` is like this:

> cg_annotate cachegrind.out.12345

This implies `--auto=yes`, which requests line-by-line "auto-annotation" of
source files. I.e. `cg_annotate` will automatically annotate all files in
the profile that meet the significance threshold.

It's also possible to do something like this:

> cg_annotate --auto=no cachegrind.out.12345 a.c b.c

Which instead requests "user annotation" of the files `a.c` and `b.c`.

My thesis is that auto-annotation suffices in practice for all reasonable
use cases, and that user annotation is unnecessary and can be removed.

When I first wrote `cg_annotate` in 2002, only user annotation was
implemented. Shortly after, I added the `--auto={yes,no}` option. Since
then I've never used user annotation, and I suspect nobody else has either.
User annotation is ok when dealing with tiny programs, but as soon as you
are profiling a program with more than a handful of source files it becomes
impractical.

The only possible use cases I can think of for user annotation are as
follows.

   - If you want to see a particular file(s) annotated but you don't want
   to see any others, then you can use user annotation in combination with
   `--auto=no`. But it's trivial to search through the output for the
   particular file, so this doesn't seem important.
   - If the path to a file is somehow really messed up in the debug info,
   it might be possible that auto-annotation would fail to find it, but user
   annotation could find it, possibly in combination with `-I`. But this seems
   unlikely. Some basic testing shows that gcc, clang and rustc all default to
   using full paths in debug info. gcc supports `-fdebug-prefix-map` but that
   seems to mostly be used for changing full paths to relative paths, which
   will still work fine.

Removing user annotation would (a) simplify the code and docs, and (b)
enable the possibility of moving the merge functionality from `cg_merge`
into `cg_annotate`, by allowing the user to specify multiple cachegrind.out
files as input.

So: is anybody using user annotation? Does anybody see any problems with
this proposal?

Thanks.

Nick

Re: [Valgrind-users] about a stack fill option (as for malloc-fill and free-fill)

[Paul F. <pj...@wa...>]

On 28-03-23 11:40, Julien Allali wrote:
> Hi,
> 
>      Sometimes, valgrind detects error like "Conditional jump or move 
> depends" or "Use of uninitialized value" related to a variable in heap. 
> When using with gdb (--vgdb-error=1), a newbie (i.e. my students) can 
> have difficulties to understand as the value stored is 0 (because there 
> was zeros in heap, not because we set 0 to the variable).
> 
>      Could it be possible to add an option like --heap-up-fill 
> --heap-down-fill (like for stack with malloc), that fills heap memory 
> with a specified values (when entering a function and leave a function)?
> 
> Would it be complicated to implement?


Hi

tl;dr

I recommend using the vgdb monitor commands, they show what memcheck 
considers initialized or not. You just have to type something like

"memcheck monitor xb &var sizeof(var)"


tl;dr 2

See
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2723r0.html





Having a "stack  fill" in Valgrind would be very difficult. The problem 
is identifying exactly what is a stack allocation. Identifying a call to 
malloc is easy - we have the address of the function. Stack allocation 
is, roughly, just modifying the stack pointer.


The simplest case is where the callee does the stack allocation, on 
amd64 something like


   201910:       55                      push   %rbp
   201911:       48 89 e5                mov    %rsp,%rbp
   201914:       48 83 ec 10             sub    $0x10,%rsp


where the constant in the last line depends on the amount being 
allocated.  The initial push and move won't be there for optimized 
builds or if -fomit-frame-pointer is specified.

If the compiler is doing RVO then the stack memory will be allocated by 
the caller. See here

https://godbolt.org/z/qasjWGhsK

Line 25 in the asm output is where main allocates the space on the stack.

Then there is tail-call optimization where there is no call, just a jump 
to the callee. And then all of the other things that manipulate the 
stack pointer (alloca, C++ exceptions, signals, setjmp/longjmp). There 
are a few compiler options that affect stack use. On top of all that 
each compiler tends to do things differently.

I don't know what would be possible with DWARF, but that would only work 
with debug builds.

Going back to my second tl;dr

If I compile the godbolt example with

clang++-devel -ftrivial-auto-var-init=pattern jfb.cpp -o jfb

(that's LLVM 16)

then I get

   2019a2:       be aa 00 00 00          mov    $0xaa,%esi
   2019a7:       ba 00 10 00 00          mov    $0x1000,%edx
   2019ac:       e8 bf 00 00 00          call   201a70 <memset@plt>
   2019b1:       48 8d bd 00 f0 ff ff    lea    -0x1000(%rbp),%rdi
   2019b8:       e8 73 ff ff ff          call   201930 <_Z1fv>

which is the caller filling the 4k with 0xaa.



A+
Paul

[Valgrind-users] about a stack fill option (as for malloc-fill and free-fill)

[Julien A. <jul...@en...>]

Hi,

	Sometimes, valgrind detects error like "Conditional jump or move 
depends" or "Use of uninitialized value" related to a variable in heap. 
When using with gdb (--vgdb-error=1), a newbie (i.e. my students) can 
have difficulties to understand as the value stored is 0 (because there 
was zeros in heap, not because we set 0 to the variable).
	
	Could it be possible to add an option like --heap-up-fill 
--heap-down-fill (like for stack with malloc), that fills heap memory 
with a specified values (when entering a function and leave a function)?

Would it be complicated to implement?

thanks :)
Julien.

Re: [Valgrind-users] valgrind exits with an error when using mmap (mmap mdev device)

[Floyd, P. <pj...@wa...>]

On 15/03/2023 02:22, 骤变成玄武 via Valgrind-users wrote:
> 2  Problem description:
> -- source code:   mmap a mdev device
>
What i usually do is run pmap -x on the guest exe running standalong 
(adding a "sleep" if ncessary) and then running valgrind -d.

That should give you memory maps that you can compare.


A+

Paul

[Valgrind-users] valgrind exits with an error when using mmap (mmap mdev device)

[<101...@qq...>]

1  version:
    valgrind-3.20.0
    4.19.25-200.el7.bclinux.x86_64
    gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) 
2  Problem description:
-- source code:   mmap a mdev device

static int test_mmap_bar(void)
{
    const char *path="/sys/class/mdev_bus/0000:06:00.0/resource4";
    ...
    flags = O_RDWR;
    prot = PROT_READ | PROT_WRITE;
    unsigned long len = 4096;
    unsigned long offset = 0x320000;
    fd = open(path, flags | O_SYNC);
&nbsp; &nbsp; if (fd < 0) {
&nbsp; &nbsp; &nbsp; &nbsp; printf("[ERROR] open device err\n");
&nbsp; &nbsp; &nbsp; &nbsp; return -1;
&nbsp; &nbsp; }
&nbsp; &nbsp; addr = mmap(0, len, prot, MAP_SHARED, fd, offset);
&nbsp; &nbsp; if (addr == P_FAILED) {
&nbsp; &nbsp; &nbsp; &nbsp; printf("[ERROR] mmap faild\n");
&nbsp; &nbsp; }
...
}


--run with valgrind : 
&nbsp; &nbsp; &nbsp;valgrind --leak-check=full --show-leak-kinds=all -v --log-file=valgrind.log ./build/valgrind-test --base-virtaddr=0x4000000000
-- The valgrind log reported the following error with mmap：
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;valgrind: m_debuginfo/image.c:587 (set_CEnt): Assertion '! sr_isError(sr)' failed.
--strace valgrind:
&nbsp; &nbsp; 
&nbsp; &nbsp; open("/sys/class/mdev_bus/0000:06:00.0/resource4", O_RDWR|O_SYNC) = 94&nbsp; &nbsp; rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP SYS], NULL, 8) = 0
&nbsp; &nbsp; gettid()&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = 13758
&nbsp; &nbsp; read(1028, "Y", 1)&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = 1
&nbsp; &nbsp; mmap(0x4033000, 4096, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 94, 0x320000) = 0x4033000
&nbsp; &nbsp; syscall_332(0x5e, 0x58246543, 0x1000, 0xfff, 0x1003633aa0, 0) = 0
&nbsp; &nbsp; readlink("/proc/self/fd/94", "/sys/devices/pci0000:00/0000:00:"..., 4096) = 59
&nbsp; &nbsp; syscall_332(0xffffffffffffff9c, 0x597789da, 0, 0xfff, 0x10036346d0, 0) = 0
&nbsp; &nbsp; syscall_332(0x5e, 0x58246543, 0x1000, 0xfff, 0x1003634560, 0) = 0
&nbsp; &nbsp; pread64(94, 0x100299acd0, 8192, 0)&nbsp; &nbsp; &nbsp; = -1 EIO (Input/output error)
&nbsp; 
valgrind will do pread64&nbsp; after mmap ??




4&nbsp; run directly:
-- There is no problem with mmap
-- use pread64(..)&nbsp; will cause io error


5&nbsp; Quesions:
&nbsp; &nbsp; &nbsp; &nbsp;How can I use valgrind in this case

[Valgrind-users] Dependency issue with apt install Valgrind in Ubuntu Mate distro

[Jake H. <jak...@gm...>]

Hello experts,
I would like to start using Valgrind in my Ubunt Mate Linux distro.
Therefore I just ran the following terminal command:
sudo apt install valgrind

it didn't work as expected, here is the output:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libc6-i386 : Depends: libc6 (= 2.35-0ubuntu3) but 2.35-0ubuntu3.1 is to be
installed
E: Unable to correct problems, you have held broken packages.

Anyone did already faced the same issue? Can it be solved with a workaround?
Thank you in advance for your help!

Re: [Valgrind-users] Compilation fails on ARM

[Leon P. <leo...@gm...>]

Yes, you are right, John.
The error message comes from glibc, but I didn't look in this direction.

For those coming after me with this task, below is the way to do this. To
cross-compile Valgrind 3.20.0 I used the following script:

export CC=arm-linux-gnueabihf-gcc
export CXX=arm-linux-gnueabihf-g++
export CCFLAGS="-mcpu=cortex-a8 -mfpu=neon"
export LDFLAGS="
-Wl,--rpath=/lib/glibc.2.23,--dynamic-linker=/lib/glibc.2.23/ld-linux-armhf.so.3"
./configure --host=armv7-linux-gnueabihyf
--target=armv7-linux-gnueabihf --prefix=/opt/FS_HDVR/opt
make
make install

When this finished successfully, I need to run the following command to
execute MyApp under Valgrind:
export VALGRIND_LIB=/opt/libexec/valgrind; /opt/bin/valgrind MyApp
Note that most probably (I am not sure) the glibc should correspond to the
cross-compiler in use.
Anyway, now I can run Valgrind with my application(s).


THANKS FOR THE HELP!

On Wed, 1 Mar 2023 at 00:02, John Reiser <jr...@bi...> wrote:

> On 2/28/2023, Leon Pollak wrote:
> > I recall my previous mail about cross-compilation.
> > When i did exactly what is recommended, I managed to cross-compile.
> > The unexpected issue appeared when I run wvalgrind myappw:
> > FATAL: kernel too old
> > My kernel is 2.6.37 and seemed to be ok.
> > Is it final or can I do something further? Old Valgrind version, for
> example?
>
> The string "kernel too old" does not appear in the sources for valgrind
> 3.20.0,
> nor in the current 3.21.0, nor in previous 3.19.0.  The substring "too old"
> likewise does not appear in the sources, except for configuration tests
> such as:
>   ./configure:  { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING:
> 'missing' script is too old or missing" >&5
>
> So, which software wrote "FATAL: kernel too old"?  The utility 'strace'
> may help.
> Something like
>    strace -f -o strace.out -e trace=execve,write,writev,pwrite,pwritev
> wvalgrind myappw
> where 'execve' tells the command line for a given PID, and the
> 'write,writev,...'
> trace various system calls which write to file descriptors, reporting the
> associated
> process id PID.  Also run the 'strace' a second time with just the app,
> without valgrind.
> (By the way, what is the 'w' prefix and suffix in "wvalgrind myappw"?)
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Compilation fails on ARM

[John R. <jr...@bi...>]

On 2/28/2023, Leon Pollak wrote:
> I recall my previous mail about cross-compilation.
> When i did exactly what is recommended, I managed to cross-compile.
> The unexpected issue appeared when I run wvalgrind myappw:
> FATAL: kernel too old
> My kernel is 2.6.37 and seemed to be ok.
> Is it final or can I do something further? Old Valgrind version, for example?

The string "kernel too old" does not appear in the sources for valgrind 3.20.0,
nor in the current 3.21.0, nor in previous 3.19.0.  The substring "too old"
likewise does not appear in the sources, except for configuration tests such as:
  ./configure:  { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: 'missing' script is too old or missing" >&5

So, which software wrote "FATAL: kernel too old"?  The utility 'strace' may help.
Something like
   strace -f -o strace.out -e trace=execve,write,writev,pwrite,pwritev  wvalgrind myappw
where 'execve' tells the command line for a given PID, and the 'write,writev,...'
trace various system calls which write to file descriptors, reporting the associated
process id PID.  Also run the 'strace' a second time with just the app, without valgrind.
(By the way, what is the 'w' prefix and suffix in "wvalgrind myappw"?)

Re: [Valgrind-users] Compilation fails on ARM

[Leon P. <leo...@gm...>]

Thank you, John for your humor...:-)))
This is ARMv7 (Cortex-A8) the TI TMS320DM8148 CPU with 1GB RAM and there is
no chance to switch to something else.
The Valgrind manual says that it supports Linux 2.6.31 and younger, 2.6.37
seems to be younger...:-)
Why are you so pessimistic...:-)

On Tue, 28 Feb 2023 at 22:44, John Reiser <jr...@bi...> wrote:

> On 2/28/2023, Leon Pollak wrote:
> > I recall my previous mail about cross-compilation.
> > When i did exactly what is recommended, I managed to cross-compile.
> > The unexpected issue appeared when I run wvalgrind myappw:
> > FATAL: kernel too old
> > My kernel is 2.6.37 and seemed to be ok.
> > Is it final or can I do something further? Old Valgrind version, for
> example?
> Stop.  Give it up.  Find something else to do.  If this is your job,
> then find a new job as soon as you can, so that you can quit this insanity.
>
> Even OpenWRT runs Linux 5.11.  It seems likely that your environment
> is some ARM (v4 or v5) embedded system that has an app with a horrendous
> bug
> that you are trying to find and fix.  Trying to do this natively, running
> such an old kernel and probably with severely limited RAM, is insane.
>
> Get a 4GB or 8GB Raspberry Pi running a current Debian or Fedora Linux,
> and debug the app there.  The Pi has GPIO, USB, Ethernet, camera, and
> dot-matrix display interfaces.  If there are other sensors on your
> device, then you should have hardware adapters so that they can use
> USB interfacing, so that you *can* use a Pi as a real-time development
> environment.  If your management won't spend the time or money to
> make or procure such adapters for the sensors, then there is *NO* hope.
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Compilation fails on ARM

[John R. <jr...@bi...>]

On 2/28/2023, Leon Pollak wrote:
> I recall my previous mail about cross-compilation.
> When i did exactly what is recommended, I managed to cross-compile.
> The unexpected issue appeared when I run wvalgrind myappw:
> FATAL: kernel too old
> My kernel is 2.6.37 and seemed to be ok.
> Is it final or can I do something further? Old Valgrind version, for example?
Stop.  Give it up.  Find something else to do.  If this is your job,
then find a new job as soon as you can, so that you can quit this insanity.

Even OpenWRT runs Linux 5.11.  It seems likely that your environment
is some ARM (v4 or v5) embedded system that has an app with a horrendous bug
that you are trying to find and fix.  Trying to do this natively, running
such an old kernel and probably with severely limited RAM, is insane.

Get a 4GB or 8GB Raspberry Pi running a current Debian or Fedora Linux,
and debug the app there.  The Pi has GPIO, USB, Ethernet, camera, and
dot-matrix display interfaces.  If there are other sensors on your
device, then you should have hardware adapters so that they can use
USB interfacing, so that you *can* use a Pi as a real-time development
environment.  If your management won't spend the time or money to
make or procure such adapters for the sensors, then there is *NO* hope.

Re: [Valgrind-users] Compilation fails on ARM

[Leon P. <leo...@gm...>]

I recall my previous mail about cross-compilation.
When i did exactly what is recommended, I managed to cross-compile.
The unexpected issue appeared when I run wvalgrind myappw:
FATAL: kernel too old
My kernel is 2.6.37 and seemed to be ok.
Is it final or can I do something further? Old Valgrind version, for
example?

Thank a lot!!!

On Tue, 28 Feb 2023 at 13:52, Leon Pollak <leo...@gm...> wrote:

> Thank you, Paul - you were right - I missed the autogen.sh script.
> Doing it and trying to satisfy its and configure requirements brought me
> to so many incompatible version errors, that I gave up on "native"
> compilation (for DM8148 arm Cortex-A8, Linux 2.6.37) and decided to switch
> to cross-compilation. My PC is x86_64 Fedora 35.
> So, autogen.sh ran smoothly.
> Than I ran:
> export CROSS_COMPILE=/opt/gcc-linaro/bin/arm-linux-gnueabihf-
> ./configure --target=arm-linux-gnueabihf --host=x86_64-redhat-linux
> --prefix=/opt/valgrind CFLAGS=-static CC=${CROSS_COMPILE}gcc \
>              CPP=${CROSS_COMPILE}cpp CXX=${CROSS_COMPILE}g++
> LD=${CROSS_COMPILE}ld AR=${CROSS_COMPILE}ar
> Everything runs smoothly till:
> /opt/gcc-linaro/bin/arm-linux-gnueabihf-gcc -DHAVE_CONFIG_H -I. -I..  -I..
> -I../include -I../include -I../VEX/pub -I../VEX/pub -DVGA_amd64=1
> -DVGO_linux=1 -DVGP_amd64_linux=1 -DVGPV_amd64_linux_vanilla=1  -I../
> coregrind -DVG_LIBDIR="\"/opt/valgrind/libexec/valgrind"\"
> -DVG_PLATFORM="\"amd64-linux\""  -O2 -g -Wall -Wmissing-prototypes -Wshadow
> -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-align -Wc
> ast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-signedness
> -Wformat-security -Wignored-qualifiers -Wmissing-parameter-type
> -Wlogical-op -Wold-style-declaration -finline-functions
> -fno-stack-protector -f
> no-strict-aliasing -fno-builtin   -fomit-frame-pointer   -static -MT
> valgrind-launcher-linux.o -MD -MP -MF .deps/valgrind-launcher-linux.Tpo -c
> -o valgrind-launcher-linux.o `test -f 'launcher-linux.c' || echo '
> ./'`launcher-linux.c
> In file included from ../include/pub_tool_vki.h:61:0,
>                 from pub_core_vki.h:42,
>                 from launcher-linux.c:39:
> ../include/vki/vki-xen.h:82:2: error: #error "Need to define per-ARCH Xen
> types for this platform"
> #error "Need to define per-ARCH Xen types for this platform"
>  ^~~~~
> ../include/vki/vki-xen.h:85:1: error: ‘void’ must be the only parameter
> DEFINE_VKI_XEN_GUEST_HANDLE(void);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> and further thousands of errors.
>
>
> On Mon, 27 Feb 2023 at 23:24, Paul Floyd <pj...@wa...> wrote:
>
>>
>>
>> On 27-02-23 22:11, Leon Pollak wrote:
>> > Hello, all.
>> > I am trying to compile Valgrind 3.20.0 on ARMv7 Linux 2.6.37 (not
>> cross!).
>> > At first, compilation produced a lot of errors with binary constants in
>> > the form 0bXXXX, but I replaced them with normal numbers and
>> compilation
>> > continued.
>> > It failed with:
>> > ../coregrind/link_tool_exe_linux 0x58000000 gcc -std=gnu99     -o
>> > memcheck-arm-linux  -O2 -g -Wall -Wmissing-prototypes -Wshadow
>> > -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-qual
>> > -Wwrite-st
>> > rings -Wformat -Wformat-security -finline-functions
>> -fno-stack-protector
>> > -fno-strict-aliasing -fno-builtin   -marm -mcpu=cortex-a8 -O2 -static
>> > -nodefaultlibs -nostartfiles -u _start   memcheck_arm_linux-mc_leak
>> > check.o memcheck_arm_linux-mc_malloc_wrappers.o
>> > memcheck_arm_linux-mc_main.o memcheck_arm_linux-mc_main_asm.o
>> > memcheck_arm_linux-mc_translate.o memcheck_arm_linux-mc_machine.o
>> > memcheck_arm_linux-mc_errors.o ../
>> > coregrind/libcoregrind-arm-linux.a ../VEX/libvex-arm-linux.a -lgcc
>> > ../coregrind/libgcc-sup-arm-linux.a
>> > ../coregrind/link_tool_exe_linux: line 58: use: command not found
>> > ../coregrind/link_tool_exe_linux: line 59: use: command not found
>> > ../coregrind/link_tool_exe_linux: line 62: die: command not found
>> > ../coregrind/link_tool_exe_linux: line 70: syntax error near unexpected
>> > token `$ala'
>> > ../coregrind/link_tool_exe_linux: line 70: `    if (length($ala) < 3 ||
>> > index($ala, "0x") != 0);'
>>
>> It sounds to me as though the script is failing to find the perl
>> interpreter and is running in whatever your default shell is.
>>
>> Can you ensure that you have perl installed?
>>
>> Is the path in link_tool_exe_linux correct?
>> If not you may need to run "autogen.sh" in the top source directory and
>> then rerun configure.
>>
>> A+
>> Paul
>>
>>
>>
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
>

Re: [Valgrind-users] Compilation fails on ARM

[Leon P. <leo...@gm...>]

Thank you, Paul - you were right - I missed the autogen.sh script.
Doing it and trying to satisfy its and configure requirements brought me to
so many incompatible version errors, that I gave up on "native" compilation
(for DM8148 arm Cortex-A8, Linux 2.6.37) and decided to switch to
cross-compilation. My PC is x86_64 Fedora 35.
So, autogen.sh ran smoothly.
Than I ran:
export CROSS_COMPILE=/opt/gcc-linaro/bin/arm-linux-gnueabihf-
./configure --target=arm-linux-gnueabihf --host=x86_64-redhat-linux
--prefix=/opt/valgrind CFLAGS=-static CC=${CROSS_COMPILE}gcc \
             CPP=${CROSS_COMPILE}cpp CXX=${CROSS_COMPILE}g++
LD=${CROSS_COMPILE}ld AR=${CROSS_COMPILE}ar
Everything runs smoothly till:
/opt/gcc-linaro/bin/arm-linux-gnueabihf-gcc -DHAVE_CONFIG_H -I. -I..  -I..
-I../include -I../include -I../VEX/pub -I../VEX/pub -DVGA_amd64=1
-DVGO_linux=1 -DVGP_amd64_linux=1 -DVGPV_amd64_linux_vanilla=1  -I../
coregrind -DVG_LIBDIR="\"/opt/valgrind/libexec/valgrind"\"
-DVG_PLATFORM="\"amd64-linux\""  -O2 -g -Wall -Wmissing-prototypes -Wshadow
-Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-align -Wc
ast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-signedness
-Wformat-security -Wignored-qualifiers -Wmissing-parameter-type
-Wlogical-op -Wold-style-declaration -finline-functions
-fno-stack-protector -f
no-strict-aliasing -fno-builtin   -fomit-frame-pointer   -static -MT
valgrind-launcher-linux.o -MD -MP -MF .deps/valgrind-launcher-linux.Tpo -c
-o valgrind-launcher-linux.o `test -f 'launcher-linux.c' || echo '
./'`launcher-linux.c
In file included from ../include/pub_tool_vki.h:61:0,
                from pub_core_vki.h:42,
                from launcher-linux.c:39:
../include/vki/vki-xen.h:82:2: error: #error "Need to define per-ARCH Xen
types for this platform"
#error "Need to define per-ARCH Xen types for this platform"
 ^~~~~
../include/vki/vki-xen.h:85:1: error: ‘void’ must be the only parameter
DEFINE_VKI_XEN_GUEST_HANDLE(void);
^~~~~~~~~~~~~~~~~~~~~~~~~~~

and further thousands of errors.


On Mon, 27 Feb 2023 at 23:24, Paul Floyd <pj...@wa...> wrote:

>
>
> On 27-02-23 22:11, Leon Pollak wrote:
> > Hello, all.
> > I am trying to compile Valgrind 3.20.0 on ARMv7 Linux 2.6.37 (not
> cross!).
> > At first, compilation produced a lot of errors with binary constants in
> > the form 0bXXXX, but I replaced them with normal numbers and compilation
> > continued.
> > It failed with:
> > ../coregrind/link_tool_exe_linux 0x58000000 gcc -std=gnu99     -o
> > memcheck-arm-linux  -O2 -g -Wall -Wmissing-prototypes -Wshadow
> > -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-qual
> > -Wwrite-st
> > rings -Wformat -Wformat-security -finline-functions -fno-stack-protector
> > -fno-strict-aliasing -fno-builtin   -marm -mcpu=cortex-a8 -O2 -static
> > -nodefaultlibs -nostartfiles -u _start   memcheck_arm_linux-mc_leak
> > check.o memcheck_arm_linux-mc_malloc_wrappers.o
> > memcheck_arm_linux-mc_main.o memcheck_arm_linux-mc_main_asm.o
> > memcheck_arm_linux-mc_translate.o memcheck_arm_linux-mc_machine.o
> > memcheck_arm_linux-mc_errors.o ../
> > coregrind/libcoregrind-arm-linux.a ../VEX/libvex-arm-linux.a -lgcc
> > ../coregrind/libgcc-sup-arm-linux.a
> > ../coregrind/link_tool_exe_linux: line 58: use: command not found
> > ../coregrind/link_tool_exe_linux: line 59: use: command not found
> > ../coregrind/link_tool_exe_linux: line 62: die: command not found
> > ../coregrind/link_tool_exe_linux: line 70: syntax error near unexpected
> > token `$ala'
> > ../coregrind/link_tool_exe_linux: line 70: `    if (length($ala) < 3 ||
> > index($ala, "0x") != 0);'
>
> It sounds to me as though the script is failing to find the perl
> interpreter and is running in whatever your default shell is.
>
> Can you ensure that you have perl installed?
>
> Is the path in link_tool_exe_linux correct?
> If not you may need to run "autogen.sh" in the top source directory and
> then rerun configure.
>
> A+
> Paul
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Compilation fails on ARM

[Paul F. <pj...@wa...>]

On 27-02-23 22:11, Leon Pollak wrote:
> Hello, all.
> I am trying to compile Valgrind 3.20.0 on ARMv7 Linux 2.6.37 (not cross!).
> At first, compilation produced a lot of errors with binary constants in 
> the form 0bXXXX, but I replaced them with normal numbers and compilation 
> continued.
> It failed with:
> ../coregrind/link_tool_exe_linux 0x58000000 gcc -std=gnu99     -o 
> memcheck-arm-linux  -O2 -g -Wall -Wmissing-prototypes -Wshadow 
> -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-qual 
> -Wwrite-st
> rings -Wformat -Wformat-security -finline-functions -fno-stack-protector 
> -fno-strict-aliasing -fno-builtin   -marm -mcpu=cortex-a8 -O2 -static 
> -nodefaultlibs -nostartfiles -u _start   memcheck_arm_linux-mc_leak
> check.o memcheck_arm_linux-mc_malloc_wrappers.o 
> memcheck_arm_linux-mc_main.o memcheck_arm_linux-mc_main_asm.o 
> memcheck_arm_linux-mc_translate.o memcheck_arm_linux-mc_machine.o 
> memcheck_arm_linux-mc_errors.o ../
> coregrind/libcoregrind-arm-linux.a ../VEX/libvex-arm-linux.a -lgcc 
> ../coregrind/libgcc-sup-arm-linux.a
> ../coregrind/link_tool_exe_linux: line 58: use: command not found
> ../coregrind/link_tool_exe_linux: line 59: use: command not found
> ../coregrind/link_tool_exe_linux: line 62: die: command not found
> ../coregrind/link_tool_exe_linux: line 70: syntax error near unexpected 
> token `$ala'
> ../coregrind/link_tool_exe_linux: line 70: `    if (length($ala) < 3 || 
> index($ala, "0x") != 0);'

It sounds to me as though the script is failing to find the perl 
interpreter and is running in whatever your default shell is.

Can you ensure that you have perl installed?

Is the path in link_tool_exe_linux correct?
If not you may need to run "autogen.sh" in the top source directory and 
then rerun configure.

A+
Paul