Re: [Valgrind-users] valgrind usage in arm board

[John Reiser]

On 9/28/23 20:55, ramakanth varala wrote:

I gathered all info at this place https://pastebin.com/1sekb62v 



Looking at the previous messages of the thread in [Valgrind-users] mailing list,
I don't see any information about the context in which you are working.
Specifically:
  Which version of valgrind ?  (Run "valgrind --version".)
  Which hardware?
  Which operating system and version?
  Which Linux distribution and software [cross-]development environment?
  Which compiler and version, and which C run-time library and version?

Some of that info is *required* in order to help you,
and all of it makes it much easier for maintainers
to understand what the problem might be.

From the pastebin posting it apears that you are running Linux
on a 32-bit ARM system which uses /lib/ld-linux.so.3 as the
run-time dynamic linker.  But which version of the development
environment, compiler, and run-time C library?  Yes, it might
really matter.  Bottom line: give enough information so that
a maintainer can reproduce the problem that you see.

Getting down to specifics:

$ readelf --use-dynamic --symbols ./lib/ld-linux.so.3  > 
/home/labuser/rk/symbols-2.txt

The use of "./lib/ld-linux.so.3" instead of "/lib/ld-linux.so.3"
[the difference is a leading dot '.' or not] triggers alarm bells.
You must be *ABSOLUTELY CERTAIN* that those two files have
identical contents.  Particularly with "cross-system" environments,
it is trivially easy for them to differ inadvertently or on purpose.
Run both 'cmp' and 'sha256sum' to be sure that the contents are the same.
If the contents are not the same, then you must start over from the beginning.

Using a text editor on the contents of the pastebin posting:
=
:g/index$/p
   857: 0001a300   204 FUNCLOCAL  DEFAULT   10 index

:g/index$/?Symbol table?p
Symbol table '.symtab' contains 988 entries:

:g/index$/?$ cat?p
$ cat /home/labuser/rk/symbols-1.txt
=
Therefore the symbol 'index' does exist in the link-time symbols-1.txt,
but not in the run-time symbol table symbols-2.txt.  So if the real
/lib/ld-linux.so.3 has been stripped in order to save space, then
'index' will disappear, and valgrind will not be able to find it.

=
:g/strchr$/p
   933: 0001a300   204 FUNCLOCAL  DEFAULT   10 strchr

:g/strchr$/?Symbol table?p
Symbol table '.symtab' contains 988 entries:

:g/strchr$/?$ cat?p
$ cat /home/labuser/rk/symbols-1.txt
=
Therefore 'strchr' is a synonym for 'index', having the same value
0x0001a300 and the same properties, but a different name, and a
different position in the link-time symbol table.

Overall conclusion: you have found a bug in valgrind,
namely 'index' is optional, and not required as demanded by valgrind.
(Which version of valgrind?  :-) )
Please file a bug report, following the directions at
   https://valgrind.org/support/bug_reports.html
You will need to supply all the version info of the various pieces,
and the analysis of which symbols really are present, and _where_.



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] valgrind usage in arm board

[John Reiser]

On 9/26/23 23:15, ramakanth varala wrote:

valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:  index
valgrind:  in an object with soname matching:   ld-linux.so.3
*valgrind:  was not found whilst processing*
*valgrind:  symbols from the object with soname: ld-linux.so.3*


'index' is identical to 'strchr'.  (Run "man 3 index" to see documentation.)
It might be that the source code for your ld-linux.so has been scoured,
replacing all calls of 'index(' with calls to 'strchr(' instead.
If so, then 'index' will not appear in the symbol table,
and valgrind will have a bug, because: 'index' should be optional.

Please run your app under 'strace':
strace -f -o strace.out -e trace=file ./my_app args...
and look in file strace.out for two kinds of info:
any line containing "ENOENT" (file not found)
and any line containing "ld-linux" (part of the actual path used
for the run-time dynamic linker.)
Make sure that what you see makes sense.
Also run "readelf --segments ./my_app" and look for the PT_INTERP.

After discovering the actual path that was used for ld-linux,
then run "readelf --symbols /path/to/ld-linux  > symbols-1.txt"
and "readelf --use-dynamic --symbols /path/to/ld-linux  > symbols-2.txt" .
Then look in both symbols-[12].txt files to see about 'index' AND 'strchr'.






___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Help

[John Reiser]

==17348== Warning: invalid file descriptor 1024 in syscall close()

Your exe is probably trying to ensure all file descriptors are closed. You 
should probably use getrlimit() to query the upper limit rather than assume 
anything. Exes under Valgrind have a slighly lower limit because Valgrind uses 
some file descriptors itself (e.g., its log file).


See also the manual page for 'close_range', which is a system call in Linux >= 
5.9 and FreeBSD.
You may have to think about what the parameters should be, but 'close_range' is 
very efficient.



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Does Valgrind support AMD Ryzen 5 5600X processors

[John Reiser]

I am trying to find which of my systems will run valgrind, I know it will not 
run on my AMD FX-8370� and AMD FX-4350 systems. Does any one know if it should 
run on my AMD Ryzen 5 5600X (see failure below) ?

I have access to an Intel core 7 laptop (Haswell), would I stand a better 
chance with that, I am reluctant to move my whole project to the laptop if 
there is no chance of Valgrind working there too.




==5096== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
==5096== Command: QtWeather -s moira2
==5096==
vex amd64->IR: unhandled instruction bytes: 0xC4 0xE2 0x7D 0xDC 0xC9 0x48 0x39 
0xD1 0x73 0x37
vex amd64->IR:�� REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:�� VEX=1 VEX.L=1 VEX.n=0x0 ESC=0F38
vex amd64->IR:�� PFX.66=1 PFX.F2=0 PFX.F3=0
==5096== valgrind: Unrecognised instruction at address 0x5ee6282.
==5096==��� at 0x5EE6282: aeshash256_ge32(long long __vector(4), unsigned char 
const*, unsigned long) (in /opt/qt-6.4.0/lib/libQt6Core.so.6.4.0)


RTFM.  It's DOCUMENTED!!  https://valgrind.org/info/platforms.html
AMD64/Linux: up to and including AVX2. This is the primary development 
target and tends to be well supported.

So: Intel Haswell: yes.  If "grep aes /proc/cpuinfo" is not empty, then NO,
unless you tell the compiler and disto-supplied libraries to avoid aes.
Also search for 'aes' in "$ info gcc".


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] valgrind gets fatal signal when particular syscall is made by an executable

[John Reiser]

On a machine that has an old linux kernel, when valgrind 3.21.0 runs an
executable that contains a call to syscall 378 - valgrind fails after
being killed by a fatal signal.

The kernel on the machine is 3.10.0 x86_64 (the system is based on RedHad 5,
I think), libc 2.17, and the executable itself is 32 bit.


Please show the complete output of "uname -a".
In the linux git source code repository
  url = git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
there is no git tag "v3.10.0"; only "v3.10" and "v3.10.1", "v3.10.2", etc.


On this particular kernel, syscall 378 happens to be mapped to setprocns,


After checking out the code via "git checkout v3.10.1", then "grep -sr setprocns 
."
shows that the linux source code has no lines that contain "setprocns".
So there is an error in part of your claim.


valgrind thinks that an executable is trying to execute syscall preadv2, which
is indeed mapped to 378 on newer kernels, but doesn't exist in linux 3.10.0


It is correct that "grep -sr preadv2 ." shows no matching lines in linux 
v3.10.1.
However, "cd arch/x86; grep -sr 378 ." shows no syscall numbered 378.
Please verify what you are talking about.

"cd arch/x86; grep -sr setns ." does show these syscalls with a related name:
./syscalls/syscall_64.tbl:308   common  setns   sys_setns
./syscalls/syscall_32.tbl:346   i386setns   sys_setns


Older versions of valgrind (for example, valgrind 3.10.0) don't have this
problem, and succeed to execute the same executable on this machine.


Therefore one solution is to use a version of valgrind that is contemporaneous
with your kernel.  Check the list of versions and dates for both linux and
valgrind, and find the best match.


What can I do to fix the problem? Unfortunately I am stuck with having to
use such an old system, and therefore using newer kernel is not an option.


1. Double check the versions that you claim, and prove against the official 
sources.
2. The valgrind syscall table is in coregrind/m_syswrap/syswrap-x86-linux.c
   and syswrap-amd64-linux.c.  Therefore, modify the source code of valgrind
   to call utsname() during initialization, and alter the table
  static SyscallTableEntry syscall_table[] = { ... };
   accordingly.  Probably 'static' must be removed.  Also, 'const' should
   be removed if necessary.  [Why isn't the table 'const' in the first place?]

Note that any change in syscall numbers creates a giant incompatibility
for any app that is built using "the other" assignments.  No old apps
can be relied to run on newer systems, and no new apps can be relied
to run on older systems.  That's a disaster, and it is *NOT* "waiting to
happen"; it has already happened.



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] unhandled instruction bytes for vmovdqu64

[John Reiser]

Running valgrind on GnuCOBOL errors out with

vex amd64->IR: unhandled instruction bytes:
  0x62 0xF1 0xFE 0x8 0x6F 0x7 0x48 0xC7 0x5 0x6F
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
valgrind: Unrecognised instruction at address 0x4e75f20.
   at 0x4E75F20: cob_string_init (strings.c:742)



132 (gdb) disassemble /s
133 Dump of assembler code for function cob_string_init:
134 ../../libcob/strings.c:
135 741 {
136 742 string_dst_copy = *dst;
137 => 0x04e75f20 <+0>: vmovdqu64 (%rdi),%xmm0



Is there anything I can do this to still run the application with valgrind or 
do I need to wait for a hotfix?


As always: report the version of valgrind.  Run "valgrind --version",
then copy+paste the output here.  The version is the #1 clue for any 
investigation.



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] "Error accepting connection: Function not implemented", is this expected?

[John Reiser]

Upgrade valgrind *TODAY*.  The current version is valgrind-3.21.0.


On a RaspberryPi model 3 in 32-bit mode (armhf) running Debian 11 (bullseye),
then "apt-get install valgrind" installs valgrind-3.16.1 which is much better
than the valgrind-3.7.0 which complained "not implemented" for the "pac" app.

On the same machine (1 GiB RAM, 4 CPU), valgrind-3.22.0.GIT can be built
from source git://sourceware.org/git/valgrind.git.  It takes less than
one hour if you invoke "make -j4" to use all 4 CPU; no dynamic paging is used.



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] "Error accepting connection: Function not implemented", is this expected?

[John Reiser]

I am using Debian on RaspberryPi and everything is from the official
apt package manager.

Hardware architecture: armv7l GNU/Linux
OS version:Raspbian GNU/Linux 11 (bullseye)
Libmicrohttpd: stable, 0.9.72-2 armhf
Valgrind:  valgrind-3.7.0


Upgrade valgrind *TODAY*.  The current version is valgrind-3.21.0.
Valgrind-3.7.0 was released in November 2011: commit 
261bffdb4c2a52014ee10b4d68a75db0ec5834e60.
It is a waste of everyone's time to chase "not implemented" in software
that is over 11 years old and has been updated frequently since then.


re: https://github.com/alex-lt-kong/public-address-client
Fix your bugs:
1. README.md:  libao-devel must be installed, else "#include ao/ao.h" fails.
2. gcc ./src/utils.c -c -O2 -Wall -pedantic -Wextra -Wc++-compat  
-fsanitize=address -g
./src/utils.c: In function ‘handle_sound_name_queue’:
./src/utils.c:155:75: warning: format ‘%d’ expects argument of type ‘int’, but 
argument 4 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
  155 | syslog(LOG_INFO, "Currently playing: [%s], current sound_queue_size: 
%d",
  | 
 ~^
  | 
  |
  | 
  int
  | 
 %ld
  156 |sound_realpath, qs);
  |~~
  ||
  |size_t {aka long unsigned int}
./src/utils.c:169:1: warning: control reaches end of non-void function 
[-Wreturn-type]
  169 | }
  | ^

3. libasan is required.
4. libasan must be first in the list presented to /usr/bin/ld, else it does not 
work correctly:
   "ASan runtime does not come first in initial library list; you should
either link runtime to your application or manually preload it with 
LD_PRELOAD."
   -
   pac.out: $(SRC_DIR)/main.c queue.o utils.o
   $(CC) -lasan $(SRC_DIR)/main.c queue.o utils.o -o pac.out $(CFLAGS) 
$(LDFLAGS) $(SANITIZER)
   -


--




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] "Error accepting connection: Function not implemented", is this expected?

[John Reiser]

... each time a client makes a [HTTP] request, Valgrind complains "Error
accepting connection: Function not implemented" and my program fails to
handle the request as a result.


Which versions of each of these pieces are you running: Libmicrohttpd, valgrind,
hardware architecture, OS?

Please give the exact copy+paste of the invocation of valgrind that fails,
together with the output from Terminal that surrounds the complaint
"Error accepting connection: Function not implemented".

Please run under /usr/bin/strace, and report the twenty system calls that are 
run
shortly before the complaint:
strace -f -o strace.out valgrind ./my_app args...
You may wish to compare versus the output from strace on the same command
but without using 'valgrind'.

Then the best way to gain attention of valgrind *developers*
is to put all that info into a bug report at:  https://bugs.kde.org/ ,
and post here in the mailing list the URL of the bug report that you created.

--



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] tool=cachegrind always reports LL misses, even if the cache is bigger than the used memory

[John Reiser]

I would think that, regardless of cache size, the *first* access to a line
causes a miss.


The PowerPC and relatives have an instruction which force-allocates
(if necessary) AND zeroes an entire cache line, so in some ways the
"first" access is a Write which succeeds with no miss.



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

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

[John Reiser]

 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 mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Compilation fails on ARM

[John Reiser]

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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Compilation fails on ARM

[John Reiser]

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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Need Help

[John Reiser]

$ cat foo.s
.byte 0x66,0xF,0x3A,0x22
.byte 0,0,0,0
#
# For x86_64 on x86_64
#
$ gcc --version
gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
$ gcc -c foo.s
$ file foo.o
foo.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), stripped
$ gdb foo.o
GNU gdb (GDB) Fedora 12.1-2.fc36
(gdb) x/i 0
   0x0: pinsrd $0x0,(%rax),%xmm0
(gdb)
   0x6: add%al,(%rax)

#
# For i686 on x86_64
#
$ gcc -m32 -c foo.s
$ file foo.o
foo.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), stripped
$ gdb foo.o
(gdb) x/i 0
   0x0: pinsrd $0x0,(%eax),%xmm0
(gdb)
   0x6: add%al,(%eax)




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Cache conflict detection support in cachegrind

[John Reiser]

On 2023-01-29, Paul Floyd wrote:


My recommendations for this are:

1/ PMU/PMC (performance monitoring unit/counter) event counting tools (perf record on Linux, pmcstat on FreeBSD, Oracle Studio collect on Solaris, don't know for macOS). These can record events such as cache misses with the associated callstacks. You can then use tools HotSpot and 
perfgrind/kcachegrind (I hae used HotSpot but not perfgrind).


The big advantage of this is that the PMCs are part of the hardware and the 
overhead of doing this is minor. The only slight limitation is that then number 
of counters is limited.


Another disadvantage: the hardware does not know which accesses
belong to the target code versus which accesses belong to
the code of valgrind itself.

Even if the hardware could separate accesses on that basis, it does not know
about stack frames.  Allocating a stack frame shortly after CALL, and
discarding it shortly before RETURN, can be significant reasons for
cache misses, either immediately or in the near future.

Then there are system calls, which might significantly alter cache contents.
Sometimes the resulting cache misses should be included (they most certainly
do affect wall clock time), but in some other cases you may wish that the
operating system was ignored.

If the target program uses threads, then using memory for inter-thread
communication (semaphore, mutex, pipeline, etc.) becomes another factor.



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Timer delete

[John Reiser]

On 11/11/22 13:23, Domenico Panella wrote:

Operating System: Slackware 15.0 (Current) Kernel Version: 5.19.17 (64-bit) 
Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-8565U CPU @ 1.80GHz

A small example:

#include

 [[snip horrible formatting]]




It's a bug (or implementation constraint) in glibc timer.

When I run it under valgrind-3.19.0 with glibc-debuginfo and glibc-debugsource
installed (2.35-17.fc36.x86_64):  [Notice the annotation "LOOK HERE"]
=
$ valgrind --leak-check=full --sim-hints=no-nptl-pthread-stackcache ./a.out
==281161== Memcheck, a memory error detector
==281161== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==281161== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==281161== Command: ./a.out
==281161==
--281161:0:   sched WARNING: pthread stack cache cannot be disabled!  < LOOK HERE 
<
==281161==
==281161== HEAP SUMMARY:
==281161== in use at exit: 272 bytes in 1 blocks
==281161==   total heap usage: 3 allocs, 2 frees, 512 bytes allocated
==281161==
==281161== 272 bytes in 1 blocks are possibly lost in loss record 1 of 1
==281161==at 0x484A464: calloc (vg_replace_malloc.c:1328)
==281161==by 0x4012E42: UnknownInlinedFun (rtld-malloc.h:44)
==281161==by 0x4012E42: allocate_dtv (dl-tls.c:375)
==281161==by 0x4013841: _dl_allocate_tls (dl-tls.c:634)
==281161==by 0x48F5A98: allocate_stack (allocatestack.c:428)
==281161==by 0x48F5A98: pthread_create@@GLIBC_2.34 (pthread_create.c:647)
==281161==by 0x4900864: __timer_start_helper_thread (timer_routines.c:147)
==281161==by 0x48F9E36: __pthread_once_slow (pthread_once.c:116)
==281161==by 0x49002CA: timer_create@@GLIBC_2.34 (timer_create.c:70)
==281161==by 0x4011E2: main (timer.c:40)
==281161==
==281161== LEAK SUMMARY:
==281161==definitely lost: 0 bytes in 0 blocks
==281161==indirectly lost: 0 bytes in 0 blocks
==281161==  possibly lost: 272 bytes in 1 blocks
==281161==still reachable: 0 bytes in 0 blocks
==281161== suppressed: 0 bytes in 0 blocks
==281161==
==281161== For lists of detected and suppressed errors, rerun with: -s
==281161== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
=



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] bug report: bugzilla refused to accept this saying it contains spam. But it doesn't.

[John Reiser]

I think valgrind experienced a division by zero.

readdwarf.c:

   if (op_code >= info.li_opcode_base) {
  op_code -= info.li_opcode_base;
  Word adv = (op_code / info.li_line_range)    <--- line 831
    * info.li_min_insn_length;
  Int advAddr = adv;
  state_machine_regs.address += adv;


If you can re-build valgrind, then a quick-and-dirty work-around
might be

>   Word adv = (op_code / (info.li_line_range ?: 1))
> * info.li_min_insn_length;

where "x ?: y" is a deprecated-but-useful slang for "x ? x : y".

Also, one probable reason for the bug reporting system rejecting
your first submission is the many consecutive lines that begin with
"00:08.54 GECKO(319869) ".  The work-around for this is to put
the text of the valgrind complaint into an attachment, and say
"See the attachment for the full text of the valgrind complaint."


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Suggestion for the documentation of --error-exitcode

[John Reiser]

On 9/12/22 10:04, David Anderson wrote:

Thhe html documentation
http://www.valgrind.org/docs/manual/index.html
explains what --error-exitcode=9
does in case valgrind notes an error.



[[snip]]



It says nothing explicitly about what exit code is returned
if valgrind does not find an error. AFAICT.

In my tests, it appears that when valgrind
finds no problem valgrind returns the exit code
of the application under test if --error-exitcode is set non-zero.
I suggest that the web page should say that clearly.


The best way to handle this is to file a bug report:
https://valgrind.org/support/bug_reports.html
and then post here the URL of the bug report.
A bug report alerts multiple developers, and
will not get lost or forgotten.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] unable to read core generated by valgrind in gdb / aarch64

[John Reiser]

OK, but why would that break core files only with valgrind? Because when ran 
directly, the core files work perfectly fine.


[Rhetorical]  Why are there bugs?

[Practical]  The operating system itself is the writer of ordinary
core files, which contain process state: register values, copies of
Writable pages, partial information from Read-only pages, etc.
Valgrind is an in-process emulator.  As far as the OS is concerned,
the process is valgrind, not postgresql.  The register values
are those of the valgrind emulator internal code, not of the target
program that valgrind is emulating.

In order for the core file to look like it was generated for postgresql,
then valgrind must write the core file.  The spec for the layout
of a core file (the C-language 'struct' that corresponds to the
sequence of bytes in the file) is rife with opportunities for bugs.
First, the spec is hard to find, or may refer to other documents
that are hard to access.  (What _exactly_ is the entire programmer-
visible register state?)
Then the spec is not executable (directly compilable).  Often the
spec or the C_language 'struct' is not updated in timely manner
when the hardware or the OS changes.

In practice it is very easy for there to be a discrepancy involving
the presence, order, width, or alignment of various fields,
especially for condition codes, processor modes (32 or 64 bit?),
and optional register files or accelerators (floating point,
SIMD, vector units, etc.)




... attached is a simple .c file, with a trivial example (3 functions) and 
segfault (or abort). ...
The core file produced without valgrind is perfectly fine:

   $ gdb ./a.out core
   ...
   Core was generated by `./a.out'.
   Program terminated with signal SIGSEGV, Segmentation fault.
   #0  0x005594350734 in f3 () at valgrind-core-test.c:6
   6    *ptr = 'a';
   (gdb) bt
   #0  0x005594350734 in f3 () at valgrind-core-test.c:6
   #1  0x005594350750 in f2 () at valgrind-core-test.c:13
   #2  0x005594350768 in f1 () at valgrind-core-test.c:18
   #3  0x005594350780 in main () at valgrind-core-test.c:23

but when run under valgrind it looks like this:

   $ gdb ./a.out vgcore.1395835
   ...
   Core was generated by `'.
   Program terminated with signal SIGSEGV, Segmentation fault.
   #0  0x00108734 in ?? ()
   (gdb) bt
   #0  0x00108734 in ?? ()
   #1  0x00108780 in ?? ()
   #2  0x00108644 in ?? ()

However, when I do this on x86 (Fedora 34, gcc 11.3.1, valgrind 3.18.1) it 
works just fine and I get the same backtrace.

So perhaps this is specific to (either) gcc 10.2, or aarch64 platform.


Bingo!  You now have the raw material for a very good bug report:
"valgrind-generated core files lose debugging info on aarch64".
Please file a bug report; see  https://valgrind.org/support/bug_reports.html

(Also note that several values for program counter in the two tracebacks
agree in the lowest 12 bits (3 hex digits).  So this may be
some confusion about the placement ("relocation") of [groups of]
whole pages in the address space.)


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] unable to read core generated by valgrind in gdb / aarch64

[John Reiser]

[[Aggressive snipping, but relevant details preserved.]]


No threading is used. Postgres is multi-process, and uses shared memory for the 
shared cache (through shm_open etc.).


Multi-process plus shm_open() IS THREADING!  Not pthreads, but multiple
execution contexts that read and write the same memory, which is
subject to the same types of synchronization errors as pthreads.
Perhaps --tool=drd and --tool=helgrind can help.


[[Another topic]]

Sure, but that's more of a workaround - it does not make the core file useful, 
it provides alternative way to get to the same result. Plus it requires 
additional tooling/scripting, and I'd prefer keeping the tooling as simple as 
possible.


I made a specific suggestion that takes less than one hour: build a small test 
case
that performs a short chain of subroutine calls, with the last routine 
generating
a deliberate SIGABRT.  Run the test case under valgrind, get a core file from 
valgrind,
and see if gdb gives the correct traceback from that core file.  The objective
is to provide a strong clue about whether *every* core file generated by 
valgrind
(in your environment) fails to work well with gdb.  Perhaps solving the problem
that involves your larger and more-complex case can be subsumed by analyzing
something that is much simpler.

Please perform that experiment and report the results here.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] unable to read core generated by valgrind in gdb / aarch64

[John Reiser]

1. Describe the environment completely.


Also: Any kind of threading (pthreads, or shm_open, or mmap(,,,MAP_SHARED,,))
must be mentioned explicitly.  Multiple execution contexts which access
the same address space instance are a significant complicating factor.

If threading is involved, then try using "valgrind --tool=drd ..."
or --tool=helgrind, because those tools specifically target detecting
race conditions and other synchronization errors, much like --tool=memcheck
[the default tool when no --tool= is mentioned] targets errors involving
malloc() and free(), uninitialized variables, etc.


4. Walk before attempting to run.
Did you try a simple example?  Write a half-page program with 5 subroutines,
each of which calls the next one, and the last one sends SIGABRT to the process.



Does the .core file when run under valgrind give the correct traceback using 
gdb?


Specifically: apply valgrind to the small program which causes a deliberate 
SIGABRT,
and get a core file.  Does gdb give the correct traceback for that core file?
If not, then you have an ideal test case for filing a bug report against 
valgrind
because even the simple core file is bad.  If gdb does give a correct traceback
for the simple core file, then you have to keep looking for the source of the
problem on your larger program.



5. (Learn and) Use the built-in tools where possible.
Run the process interactively, invoking valgrind with "--vgdb-error=0",
and giving the debugger command "(gdb) continue" after establishing
connectivity between vgdb and the process.
See the valgrind manual, section 3.2.9 "vgdb command line options".
When the SIGABRT happens, then vgdb will allow you to use all the ordinary
gdb commands to get a backtrace, go up and down the stack, examine
variables and other memory, run
    (gdb) info proc
    (gdb) shell cat /proc/$PID/maps
to see exactly the layout of process memory, etc.
There are also special commands to access valgrind functionality
interactively, such as checking for memory leaks.



I already explained why I don't want / can't use the interactive gdb. I'm aware 
of the option, I've used it before, but in this case it's not very practical.


The gdb process does not *have* to be run interactively, it just takes more work
and patience to run non-interactively.  Run "valgrind --vgdb-error=0 ..."
and notice the last part of the printed instructions:

 and then give GDB the following command
 ==215935==   target remote | /path/to/libexec/valgrind/../../bin/vgdb 
--pid=215935
 ==215935== --pid is optional if only one valgrind process is running

So if there is only one valgrind process, then you do not need to know the pid.
Thus you can run gdb with re-directed stdin/stdout/stderr, or perhaps use the -x
command-line option.  This allows a static, pre-scripted list of gdb commands;
it may require a few iterations to get a good debug script.  (Try the commands
using the trivial SIGABRT case!)  Also get the full gdb manual (more than 800 
pages)
and look at the "thread apply all ..." and "frame apply all ..." commands.

It may be possible to perform some interactive "reconnaisance" to suggest
good things for the script to try.  Using --vgdb-error=0, put a breakpoint
on a likely location for the error (or shortly before the error),
and look around.  In the logged traceback:

  TRAP: FailedAssertion("prev_first_lsn < cur_txn->first_lsn", File: 
"reorderbuffer.c", Line: 902, PID: 536049)
  (ExceptionalCondition+0x98)[0x8f5cec]
  (+0x57a574)[0x682574]
  (+0x579edc)[0x681edc]
  (ReorderBufferAddNewTupleCids+0x60)[0x6864dc]
  (SnapBuildProcessNewCid+0x94)[0x68b6a4]

any of those named locations, or shortly before them, might be a good spot.
When execution stops at any one of the breakpoints, then look around
and see if you can find clues about "prev_first_lsn < cur_txn->first_lsn"
even though the error has not yet occurred.  Perhaps this will help
identify location(s) that might be closer to the actual error
when it does happen.  This might suggest commands for the non-interactive
gdb debugging script.



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] unable to read core generated by valgrind in gdb / aarch64

[John Reiser]

Any ideas what I might be doing wrong? Or how do I load the core file?


Why does use of valgrind cause programmers to forget general debugging 
technique?

1. Describe the environment completely.
The report does not say which compilers and compiler versions were used,
or if the compiler commands contained any directives about debugging format.
Such information is necessary to help understand what might be happening
with regard to debugging and tracebacks.

2. Get debugging information whenever invoking a compiler.
Traceback lines such as "(+0x57a574)[0x682574]" which lack the name
of a symbol or file, suggest that "-g" debugging info was not requested
for *all* compilations.  Start over ("make clean; rm -rf '*.[oa]'")
then re-compile every source file, making be sure to specify "-g"
and no variant of "-O" or "-On", except possibly "-O0".

3. Optimizing for speed comes after achieving correct execution.
If 'inline' is used anywhere, then re-compile with the compile-time argument
"-Dinline=/*empty*/" in order to #define 'inline' as a one-word comment.
If the behavior of the program changes (any difference at all, excepting
only slower execution), then there is a *design error* in the source code.
Fix that first.

4. Walk before attempting to run.
Did you try a simple example?  Write a half-page program with 5 subroutines,
each of which calls the next one, and the last one sends SIGABRT to the process.
Does the .core file when run under valgrind give the correct traceback using 
gdb?

5. (Learn and) Use the built-in tools where possible.
Run the process interactively, invoking valgrind with "--vgdb-error=0",
and giving the debugger command "(gdb) continue" after establishing
connectivity between vgdb and the process.
See the valgrind manual, section 3.2.9 "vgdb command line options".
When the SIGABRT happens, then vgdb will allow you to use all the ordinary
gdb commands to get a backtrace, go up and down the stack, examine
variables and other memory, run
   (gdb) info proc
   (gdb) shell cat /proc/$PID/maps
to see exactly the layout of process memory, etc.
There are also special commands to access valgrind functionality
interactively, such as checking for memory leaks.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] simple c program. How does the memory size calculated in Valgrind

[John Reiser]

==123254== HEAP SUMMARY:
==123254==     in use at exit: 0 bytes in 0 blocks
==123254==   total heap usage: 6 allocs, 6 frees, 2,084 bytes allocated


"2,084 bytes allocated" is the sum of all 6 arguments that were passed to 
malloc(),
calloc() [possibly by calling malloc()], realloc() [at least the increase], etc.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Valgrind trace Memory Addresses while running?

[John Reiser]

if we can get a list of all the physical addresses the program used, in the 
order the program accessed them, and whether read/write.




 For any real world application the size of the log would be overwhelmingly 
huge ... (unless you only want unique addresses).


Of course this is the purpose of data compression (such as gzip, etc).
You get some/much/most of the benefit of restricting to unique addresses
while still capturing the entire stream of references.

But as Paul noted, valgrind works in virtual addresses.
Getting all the actual physical addresses is close to impossible.
If you are working in an embedded device environment
and care only about a small handful of memory-mapped
device registers, then you can (must) process the
mapping yourself.





___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] memcheck is getting SIGKILLed before leak report is output

[John Reiser]

Is there anything that can be done with memcheck to make it consume less memory?


No.


Well, you can use the command-line argument "--num-callers=" to reduce 
the length
of tracebacks that are stored in the "red zones" just before and after an 
allocated block.
This might help enough if you have zillions of "still reachable" blocks.  But 
you get
shorter tracebacks, which might not give enough information to find and fix the 
leak
quickly.
If you do not have zillions of "still reachable" blocks, then --num-callers
will not help so much; but probably would not be needed anyway.




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] memcheck is getting SIGKILLed before leak report is output

[John Reiser]

Does heaptrack also show  the 'still reachable' types of leaks that memcheck 
does?


Heaptrack intercepts malloc+free+etc, then logs the parameters, result, and
traceback; but otherwise lets the progcess-original malloc+free+etc do the work.
Heaptrack does not notice, and does not care, what you do with the result of
malloc(), except whether or not the pointer returned by malloc() ever gets
passed as an argument to free().

When heaptrack performs analysis, then any result from malloc() that has not
been free()d is a "leak" as far as heaptrack is concerned.  So that includes
what memcheck calls "still reachable" but not (yet) a leak.


Any chance that the 'massif' tool would survive the OOM killer? This may be 
easier for me to get going as I already have valgrind built.


Worth a try if you have a day or so to spend.  Like all valgrind tools,
massif relies on emulating the instruction stream, so the basic ~10X
run-time slowdown applies.


Is there anything that can be done with memcheck to make it consume less memory?


No.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] memcheck is getting SIGKILLed before leak report is output

[John Reiser]

When running memcheck on a massive monolith embedded executable (237MB 
stripped, 1.8GiB unstripped), after I stop the executable under valgrind I see 
the “HEAP SUMMARY” but then valgrind dies before any leak reports are printed.

If finding memory leaks is the only goal (for instance, if you are satisfied
that memcheck has found all the overrun blocks, uninitialized reads, etc.)
then https://github.com/KDE/heaptrack  is the best tool.  The data-gathering
phase runs in any Linux process using LD_PRELOAD and libunwind.  The analysis
phase runs a GUI under KDE, and/or generates *useful* text reports: leaks by
individual size, leaks by total size for a given traceback, allocations
(leaked or not) by frequency or total size, etc.  I like the text-only
analysis, which avoids the requirement for KDE.  Heaptrack CPU overhead
tends to be around 20% or less, so it does not take forever.  Heaptrack
does require disk space to record data (sequential access only),
so you may need several gigabytes (locally or via network.)


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Memcheck Support For Per-Thread Caching

[John Reiser]

Does memcheck include support for per-thread caching (now enabled by default in 
glibc)?


Memcheck intercepts all calls on allocation and free-ing subroutines
(malloc, free, calloc, realloc, memalign, posix_memalign, brk, sbrk, mmap, ...)
and totally replaces each one with code that is internal to memcheck.
The glibc routines never are called at all.  Also, memcheck serializes
all execution, and executes code from only one thread at a time.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Possible to suppress low block count loss records?

[John Reiser]

We are trying to track down a suspected place in our code that keeps 
accumulating memory in a ‘still reachable’.

When I turn on still reachable and run my process for a few hours and then stop 
the process to get the valgrind reports there are over 2.7 million loss records 
which are mostly still reachables. It would take forever for valgrind to print 
this out.


It would take around one hour or less to *produce* the complete report
without printing it.  Re-direct stderr to a file, or use command-line options
--xml-fd= or --xml-file=.  See "valgrind --help" and/or the user manual
for other options to control error reporting.

Using any text editor on the report file, or inserting the 'sed'
(or 'awk') stream editor into the pipeline of error output,
enables filtering the error reports.


The large majority of “still reachable” that I want to ignore allocate just a 
few blocks. I would like to suppress these and only output “still reachables” 
that allocated 100 blocks or more.


Note that all the excluded reports (counts 1 through 99) have only 1 or 2
characters in their decimal representation, so you don't even need to
convert the field to a number to decide.


If not possible without patching valgrind, any hints on where I could patch 
valgrind to accomplish this?


Find the source location which prints the instance count, and adjust the code.
This is "standard engineering effort" for a programmer who is adept at using 
'grep',
even without prior experience with the source code of valgrind.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Valgrind crash on Texas Instrument AM3352 (armv7le) and QNX

[John Reiser]

I have 2 different boards running QNX 6.5 and mounting the exact same file 
system.
One board is based on an NXP iMX53 SoC and the other one on a Texas Instrument 
AM3352.
Since both SoC share the same instruction set (Cortex A8 - amv7le), they can 
run the same binaries.

However, whereas Valgrind 3.10.1 is working perfectly on the iMX53, it crashes 
on the AM3352 :



==1863697== Process terminating with default action of signal 11 (SIGSEGV): 
dumping core
==1863697==  Bad permissions for mapped region at address 0x245C
==1863697==at 0x1E4CC: mprotect (mprotect.c:33 in /proc/boot/libc.so.3)



Run valgrind with "-d -d -d -v -v -v" and compare the two systems, paying 
particular
attention to differences that involve "aspacem".

Does your QNX have tools such as gdb and strace or dtrace?
It will be helpful to know the address mappings at the time of the SIGSEGV.

--


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] armhf: illegal hardware instruction

[John Reiser]

Program received signal SIGILL, Illegal instruction.
vgPlain_am_startup (sp_at_startup=3204445696) at
m_aspacemgr/aspacemgr-linux.c:1626
1626   init_nsegment();
(gdb) x/i $pc
=> 0x58071090 :  vmov.i32d16, #0 ; 0x



As a reminder I do not have neon on this machine:

Features: half thumb fastmult vfp edsp thumbee vfpv3 tls idiva
idivt vfpd32 lpae


Therefore this is a gcc configuration problem.  Whoever configured the gcc
that was used to compile your valgrind assumed that neon would be present,
but your machine lacks neon.

Run "gcc --verbose".  On my RaspberryPi Model 2B I get (wrapped by hand
to reasonable line length):
-
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/10/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-6' \
  --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs \
  --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr \
  --with-gcc-major-version-only --program-suffix=-10 
--program-prefix=arm-linux-gnueabihf- \
  --enable-shared --enable-linker-build-id --libexecdir=/usr/lib 
--without-included-gettext \
  --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap 
--enable-clocale=gnu \
  --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new \
  --enable-gnu-unique-object --disable-libitm --disable-libquadmath 
--disable-libquadmath-support \
  --enable-plugin --enable-default-pie --with-system-zlib 
--enable-libphobos-checking=release \
  --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch 
--disable-sjlj-exceptions \
  --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb 
--disable-werror \
  --enable-checking=release --build=arm-linux-gnueabihf 
--host=arm-linux-gnueabihf \
  --target=arm-linux-gnueabihf
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20210110 (Debian 10.2.1-6)
-
where the important part now is "--with-arch=armv7-a --with-fpu=vfpv3-d16"
for which the "-d16" part restricts gcc to 16 double precision registers
even though my hardware has "vfpd32".

Consulting "info gcc", then searching for "neon", and examining "ARM Options",
it seems to me that the fix for gcc to assume vfp3 floating point with 32 
double-
precision registers and the half-precision floating-point conversion operations,
but omit neon, is the gcc command-line parameter 
"-march=armv7-a+vfpv3-fp16+nosimd".
You may want to use "-d16" somewhere, too.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] armhf: illegal hardware instruction

[John Reiser]

I did not make up those strace logs in my head, all I am trying to do
is Debian bug triaging. Turns out I did a pretty bad job at it:

1. The original Debian bug report seems to be PEBCAK, and I'll close
the bug as wontfix ASAP,



2. I was not paying attention to the gcc version I was using.


The original bug report  
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928224
specified the reproducing case "valgrind /bin/true".  That now works for me:
-
$ valgrind /bin/true
==399== Memcheck, a memory error detector
==399== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==399== Using Valgrind-3.20.0.GIT and LibVEX; rerun with -h for copyright info
==399== Command: /bin/true
==399==
==399==
==399== HEAP SUMMARY:
==399== in use at exit: 0 bytes in 0 blocks
==399==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==399==
==399== All heap blocks were freed -- no leaks are possible
==399==
==399== For lists of detected and suppressed errors, rerun with: -s
==399== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
-
in the environment:
-
$ valgrind --version
valgrind-3.20.0.GIT
$ gcc --version
gcc (Debian 10.2.1-6) 10.2.1 20210110
$ uname -a
Linux rpi2-20220121 5.10.0-15-armmp #1 SMP Debian 5.10.120-1 (2022-06-09) 
armv7l GNU/Linux
-
so the original bug report can be closed with "fixed in newer version"
or something like that.


So if my understanding is correct I can make valgrind produce this
"Illegal instruction" using either gcc-11 or gcc-12 (Debian package
from sid), BUT I can make valgrind run using gcc-10 (again Debian
package from sid). This also seems to be hardware specific since armhf
binary + gcc-12 runs properly on arm64 (armhf chroot).


Is it easy to install several versions (gcc-10, gcc-11, gcc-12, clang-13)
at the same time, and switch among them by using something like
   CC=/path/to/gcc-12 ./configure
Where can I find hints about this?



Would you kindly indicate if you believe the bug should be reported
back to valgrind bug tracker or gcc bug tracker ? If that matters,
clang 13.0 seems to also mess up valgrind code and binaries produced
return this "Illegal instruction".


SIGILL should be diagnosed using gdb to print the instruction stream
and register contents
-
(gdb) run args...
Program received signal SIGILL, Illegal instruction.
(gdb) x/i $pc   ## the faulting instruction
(gdb) x/12i   pc-6*4   ## disassemble the surrounding instructions
(Gdb) x/12xw $pc-6*4   ## and in 32-bit raw hexadecimal
(gdb) info reg   ## content of all registers
(gdb) x/16xw $sp   ## dump the active end of the stack
(gdb) bt   ## source-level backtrace
-
But with valgrind you must just "continue" the deliberate SIGILL and
SIGSEGV that valgrind uses.  Here is an actual run:
-
$ gdb valgrind
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Reading symbols from valgrind...
(gdb) run /bin/true
Starting program: /usr/local/bin/valgrind /bin/true
process 426 is executing new program: 
/usr/local/libexec/valgrind/memcheck-arm-linux

Program received signal SIGILL, Illegal instruction.
vgPlain_machine_get_hwcaps () at m_machine.c:1719
1719   __asm__ __volatile__(".word 0xF3044F54"); /* VMAXNM.F32 
q2,q2,q2 */

   ## Notice that this SIGILL is from valgrind trying to determine
   ## the actual hardware capabilities.  Valgrind knows what it is doing,
   ## so just 'continue' to let valgrind handle the SIGILL.

(gdb) c
Continuing.
==426== Memcheck, a memory error detector
==426== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==426== Using Valgrind-3.20.0.GIT and LibVEX; rerun with -h for copyright info
==426== Command: /bin/true
==426==

Program received signal SIGSEGV, Segmentation fault.   ## valgrind deliberate
0x62c68cc0 in ?? ()
(gdb) x/i $pc
=> 0x62c68cc0:   str r3, [r9]
(gdb) p $r9
$1 = 3187663772
(gdb) p/x $r9
$2 = 0xbdffe39c
(gdb) x/12i $pc-6*4
   0x62c68ca8:  ldr r3, [r8, #424]  ; 0x1a8
   0x62c68cac:  mov r1, r3
   0x62c68cb0:  movwr2, #62156  ; 0xf2cc
   0x62c68cb4:  movtr2, #22528  ; 0x5800
   0x62c68cb8:  blx r2
   0x62c68cbc:  ldr r3, [r8, #24]
=> 0x62c68cc0:   str r3, [r9]
   0x62c68cc4:  add r7, r9, #4
   0x62c68cc8:  mov r0, r7
   0x62c68ccc:  ldr r3, [r8, #428]  ; 0x1ac
   0x62c68cd0:  mov r1, r3
   0x62c68cd4:  movwr2, #62156  ; 0xf2cc
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.   ## valgrind deliberate
0x62c6cc0c in ?? ()
(gdb) x/i $pc
=> 0x62c6cc0c:   str r9, [r11]
(gdb) x/12i $pc-6*4
   0x62c6cbf4:  ldr r9, [r8, #416]  ; 0x1a0
   0x62c6cbf8:  mov r1, r9
   0x62c6cbfc:  movwr2, #62156  ; 0xf2cc
   0x62c6cc00:  movtr2, #22528  ; 0x5800
   0x62c6cc04:  blx r2
   0x62c6cc08:  ldr r9, [r8, #16]
=> 0x62c6cc0c:   str r9, [r11]
   0x62c6cc10:  add r9, r11, #4
   0x62c6cc14:  mov r0, r9
   0x62c6cc18:  ldr r3, [r8, #420]  ; 0x1a4
   0x62c6cc1c:  mov 

Re: [Valgrind-users] armhf: illegal hardware instruction

[John Reiser]

$ export RPI_MODEL=3
$ export DEBIAN_RELEASE=bullseye
$ wgethttps://raspi.debian.net/daily/raspi_${RPI_MODEL}_${DEBIAN_RELEASE}.img.xz


That gives arm64, not armhf (32-bit).


Choosing https://raspi.debian.net/tested/20220121_raspi_2_bullseye.img.xz
and running5.10.0-15-armmp #1 SMP Debian 5.10.120-1 (2022-06-09) armv7l 
GNU/Linux
on an old RaspberryPi Model 2B (32 bit, 1GB RAM, 4 CPU):
-
model name  : ARMv7 Processor rev 5 (v7l)
BogoMIPS: 44.80
Features: half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 
idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xc07
CPU revision: 5
-
with valgrind source
-
commit 022dfeee73726d92ecc0349ebe42d7b52132b8e5 (HEAD -> master, origin/master, 
origin/HEAD)
Author: Mark Wielaard 
Date:   Sat Jun 18 15:30:54 2022 +0200
-
and ignoring a build failure
-
Making install in tests
make[3]: Entering directory '.../valgrind/cachegrind/tests'
make[3]: *** No rule to make target 'install'.  Stop.
-
then I see:
-
$ ldd /bin/date
linux-vdso.so.1 (0xbeed6000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6e7a000)
/lib/ld-linux-armhf.so.3 (0xb6f9c000)
$ type valgrind
valgrind is hashed (/usr/local/bin/valgrind)
$ valgrind --version
valgrind-3.20.0.GIT
$ valgrind /bin/date
==32179== Memcheck, a memory error detector
==32179== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==32179== Using Valgrind-3.20.0.GIT and LibVEX; rerun with -h for copyright info
==32179== Command: /bin/date
==32179==
Tue Jun 28 18:50:27 UTC 2022
==32179==
==32179== HEAP SUMMARY:
==32179== in use at exit: 64 bytes in 1 blocks
==32179==   total heap usage: 9 allocs, 8 frees, 5,572 bytes allocated
==32179==
==32179== LEAK SUMMARY:
==32179==definitely lost: 64 bytes in 1 blocks
==32179==indirectly lost: 0 bytes in 0 blocks
==32179==  possibly lost: 0 bytes in 0 blocks
==32179==still reachable: 0 bytes in 0 blocks
==32179== suppressed: 0 bytes in 0 blocks
==32179== Rerun with --leak-check=full to see details of leaked memory
==32179==
==32179== For lists of detected and suppressed errors, rerun with: -s
==32179== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
$
-

So YES, current valgrind does support armhf (armv7l: 32-bit, hard floating 
point).



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] armhf: illegal hardware instruction

[John Reiser]

$ export RPI_MODEL=3
$ export DEBIAN_RELEASE=bullseye
$ wgethttps://raspi.debian.net/daily/raspi_${RPI_MODEL}_${DEBIAN_RELEASE}.img.xz


That gives arm64, not armhf (32-bit).


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] armhf: illegal hardware instruction

[John Reiser]

track down Debian issue https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928224
which is 3 years old:
-
Installed libc6 version: libc6-dgb:armhf 2.28-8

valgrind /bin/true

==12463== Memcheck, a memory error detector
==12463== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==12463== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:  index
valgrind:  in an object with soname matching:   ld-linux-armhf.so.3
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux-armhf.so.3
-

Using valgrind 3.19.0 on Debian/sid :
% dpkg --print-architecture
armhf
% cat /proc/cpuinfo | grep vfpv3 | head -1
Features: half thumb fastmult vfp edsp thumbee vfpv3 tls idiva
idivt vfpd32 lpae

% ./memcheck/memcheck-arm-linux
zsh: illegal hardware instruction  ./memcheck/memcheck-arm-linux

Just in case that help, here is the gdb output (*)

Let me know if you need more output.

(*)
% gdb ./memcheck/memcheck-arm-linux
GNU gdb (Debian 12.1-2) 12.1



(gdb) r
Starting program: /home/malat/valgrind-3.19.0/memcheck/memcheck-arm-linux

Program received signal SIGILL, Illegal instruction.
vgPlain_am_startup (sp_at_startup=3204445840) at
m_aspacemgr/aspacemgr-linux.c:1626
1626   init_nsegment();
(gdb) bt full
#0  vgPlain_am_startup (sp_at_startup=3204445840) at
m_aspacemgr/aspacemgr-linux.c:1626
 seg = {kind = 0, start = 0, end = 0, smode = SmLower, dev = 0,
ino = 0, offset = 5378467285696512, mode = 3204445844, fnIdx =
-1090521456, hasR = 0 '\000', hasW = 0 '\000', hasX = 38 '&',
   hasT = 88 'X', isCH = 164 '\244'}
 suggested_clstack_end = 
 __PRETTY_FUNCTION__ = "vgPlain_am_startup"



I tried to reproduce the reported behavior of valgrind-3.19.0 on my system :
- /proc/cpuinfo
model name  : ARMv7 Processor rev 4 (v7l)
BogoMIPS: 51.20
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt 
vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 4
-
$ uname -a
Linux f33arm32 5.9.14-200.fc33.armv7hl #1 SMP Fri Dec 11 15:02:36 UTC 2020 
armv7l armv7l armv7l GNU/Linux
$ ldd /bin/date
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6f6a000)
libc.so.6 => /lib/libc.so.6 (0xb6e14000)
/lib/ld-linux-armhf.so.3 (0xb6fbe000)

So the name of ld-linux contains 'armhf', although the Linux kernel is 'armv7l'.
The Features line of /proc/cpuinfo is not quite equivalent:
Mathieu's: half thumb fastmult vfp edsp thumbee vfpv3 tls   idiva idivt 
vfpd32 lpae
mine:  half thumb fastmult vfp edsp neonvfpv3 tls vfpv4 idiva idivt 
vfpd32 lpae evtstrm crc32

Re-building the software:
-
$ wget https://sourceware.org/pub/valgrind/valgrind-3.19.0.tar.bz2
$ tar xf valgrind-3.19.0.tar.bz2
$ cd valgrind-3.19.0
$ ./configure
$ make -j4
$ file ./memcheck/memcheck-arm-linux
./memcheck/memcheck-arm-linux: ELF 32-bit LSB executable, ARM, EABI5 version 1 
(SYSV), statically linked, 
BuildID[sha1]=2880b8ee178c482a9de58e83b161a0b38ca008ff, with debug_info, not 
stripped
$ ./memcheck/memcheck-arm-linux
valgrind: You cannot run './memcheck/memcheck-arm-linux' directly.
valgrind: You should use $prefix/bin/valgrind.
$ sudo make install
$ /usr/local/bin/valgrind --version
valgrind-3.19.0
$ /usr/local/bin/valgrind /bin/date
==14541== Memcheck, a memory error detector
==14541== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==14541== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==14541== Command: /bin/date
==14541==
Tue Jun 28 07:40:14 AM PDT 2022
==14541==
==14541== HEAP SUMMARY:
==14541== in use at exit: 0 bytes in 0 blocks
==14541==   total heap usage: 427 allocs, 427 frees, 30,017 bytes allocated
==14541==
==14541== All heap blocks were freed -- no leaks are possible
==14541==
==14541== For lists of detected and suppressed errors, rerun with: -s
==14541== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
$
-

So, valgrind-3.19.0 works for me.  I cannot reproduce the original bad 
behavior, nor the SIGILL,
on my hardware running 5.9.14-200.fc33.armv7hl.

If you believe that my Fedora33 environment is not close enough to your 
Debian/sid,
then please give the URL of a raw image for RaspberryPi Model 3 V1.2 that I can 
install
on a 32GB SDHC card.




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] armhf: illegal hardware instruction

[John Reiser]

On 6/28/22, Mathieu Malaterre wrote:

% strace ./memcheck/memcheck-arm-linux
execve("./memcheck/memcheck-arm-linux",
["./memcheck/memcheck-arm-linux"], 0xbe962730 /* 19 vars */) = 0
--- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPC, si_addr=0x58072020} ---
+++ killed by SIGILL +++
zsh: illegal hardware instruction  strace ./memcheck/memcheck-arm-linux


memcheck wants determine the actual hardware capabilities.
The description given by AT_PLATFORM, AT_HWCAP, AT_HWCAP2
has not always been complete and correct, so memcheck
tries the hardware instructions that matter, and memcheck
is prepared to handle SIGILL if it occurs.  Thus there
are likely to be a few deliberate SIGILL near the beginning.
If strace always halts upon SIGILL, without letting
memcheck's handler catch the SIGILL and recover from it,
then strace is too eager.  For instance, on x86_64
strace always aborts on 'int3' regardless of signal handlers.

What happens without using 'strace'?


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Cross compilation issue for Android

[John Reiser]

On 6/27/22, $rik@nth wrote:

Things got resolved after moving to older ndk where it supports gcc.


Please state exactly which older version worked for you.
This will help other valgrind developers now, and encourage
maintainers to enhance future support so that the underlying
problem gets fixed.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Cross compilation issue for Android

[John Reiser]

Upon moving to next. It landed into another issue. seems it is not easy to cross 
compile the valgrind to Android as they mentioned 
https://valgrind.org/docs/manual/dist.readme-android.html 


Should i need to contact valgrind developers list to support.

../coregrind/link_tool_exe_linux 0x5800 /local/mnt/workspace/Android_ndk/android-ndk-r23c/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android31-clang  -O3 --target=aarch64-linux-android31-clang 
--gcc-toolchain=/local/mnt/workspace/Android_ndk/android-ndk-r23c/toolchains/llvm/prebuilt/linux-x86_64/bin/ --sysroot=/local/mnt/workspace/Android_ndk/android-ndk-r23c/toolchains/llvm/prebuilt/linux-x86_64/sysroot   -o memcheck-arm-linux  -m32 -O2 -g -Wall -Wmissing-prototypes -Wshadow 
-Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-security -Wignored-qualifiers -Wenum-conversion -finline-functions -fno-stack-protector -fno-strict-aliasing -fno-builtin -Wno-cast-align -Wno-self-assign -Wno-tautological-compare 
  -marm -mcpu=cortex-a8 -O2 -static -nodefaultlibs -nostartfiles -u _start   -m32 -Wl,-z,noexecstack memcheck_arm_linux-mc_leakcheck.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

ld: error: undefined symbol: __aeabi_uidivmod
 >>> referenced by mc_leakcheck.c:837
 >>>               memcheck_arm_linux-mc_leakcheck.o:(heuristic_reachedness)
 >>> referenced by m_execontext.c:346
 >>>               
libcoregrind_arm_linux_a-m_execontext.o:(record_ExeContext_wrk2) in archive 
../coregrind/libcoregrind-arm-linux.a
 >>> referenced by m_execontext.c:346
 >>>               
libcoregrind_arm_linux_a-m_execontext.o:(record_ExeContext_wrk2) in archive 
../coregrind/libcoregrind-arm-linux.a
 >>> referenced 11 more times
 >[[snip]]


You should contact whoever supports aarch64-linux-android31-clang and complaln
that their linker step for static linking forgets to reference a static library
that contains __aeabi_uidivmod, __aeabi_d2ulz, __aeabi_ul2d, __aeabi_uldivmod,
__aeabi_uidiv, __aeabi_idiv, __aeabi_idivmod, and __aeabi_ldivmod .

I found them in:
-
$ nm -gop --defined-only $(find . -name '*.a' 2>/dev/null)  | grep 
__aeabi_uidivmod
./Android/Sdk/build-tools/32.0.0/renderscript/lib/intermediates/armeabi-v7a/libcompiler_rt.a:aeabi_uidivmod.o:
 T __aeabi_uidivmod
./Android/Sdk/build-tools/32.1.0-rc1/renderscript/lib/intermediates/armeabi-v7a/libcompiler_rt.a:aeabi_uidivmod.o:
 T __aeabi_uidivmod
./Android/Sdk/build-tools/30.0.3/renderscript/lib/intermediates/armeabi-v7a/libcompiler_rt.a:aeabi_uidivmod.o:
 T __aeabi_uidivmod
$
-
and similarly for the other undefined symbols.

Therefore a workaround is to append explicit names for the files that contain
those runtime symbols that you desire.

The hint on how to investigate this problem is in  
valgrind/coregrind/link_tool_exe_linux
which is a well-documented perl script that contains
-
# So: what we actually do:
#
#   pass the specified command to the linker as-is, except, ...

my $cmd = join(" ", @ARGV, "-static -Wl,-Ttext-segment=$ala");

#print "link_tool_exe_linux: $cmd\n";


# Execute the command:
my $r = system($cmd);
-
which shows that aarch64-linux-android31-clang is at fault when static linking.
(Forgetting the case of static linking is a common error in cross-building 
systems.)


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Question: bug in user code, valgrind or glibc?

[John Reiser]

This looks like https://bugs.kde.org/show_bug.cgi?id=434764
iconv_open causes ld.so v2.28+ to use optimised strncmp

Which was recently (but after 3.19.0) fixed by merging this commit:

commit 947388eb043ea1c44b37df94046e1eee790ad776
Author: Mike Crowe 
AuthorDate: Mon Sep 9 14:16:16 2019 +0100
Commit: Mark Wielaard 
CommitDate: Sat May 14 00:41:18 2022 +0200

 Intercept strncmp for glibc ld.so v2.28+
 


The C standard claims that all function names that begin with
'str' or 'mem' are reserved, and that language processors (compilers,
valgrind, ...)  may assume that such names designate the Standard functions.
If so, then valgrind's interception code is too picky about the context
for re-directing these functions; just use
 STRNCMP("*", strncmp)
etc. to re-direct them all.




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Question: bug in user code, valgrind or glibc?

[John Reiser]

This indicates that 'strncmp' should be re-directed from ld-linux-x86-64.so.2:


That was done already in valgrind-3.19.0.  The user problem was reported 
against:
-
==4295== Memcheck, a memory error detector
==4295== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==4295== Using Valgrind-3.18.1-42b08ed5bd-20211015 and LibVEX; rerun with -h 
for copyright info
-
which probably does not contain the fix:
$ git blame shared/vg_replace_strmem.c
947388eb04 (Mike Crowe  2019-09-09 14:16:16 +0100  713)  
STRNCMP(VG_Z_LD_LINUX_SO_2, strncmp)
947388eb04 (Mike Crowe  2019-09-09 14:16:16 +0100  714)  
STRNCMP(VG_Z_LD_LINUX_X86_64_SO_2, strncmp)


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Question: bug in user code, valgrind or glibc?

[John Reiser]

I sent a log of redirect information to both Paul and John since the log was 
too large was mailing list.

I wonder what would be the preferred public sharing site for such a purpose 
these days.


The preferred way is to create a bug report, attach the large file to the bug 
report,
then post the URL of the bug report in a message to the mailing list.

Begin at  https://valgrind.org/ .  In the left nav, click on "Bug Reports", and 
follow
the directions on the resulting page.



143:39.43 GECKO(115765) ==115769== Invalid read of size 8
143:39.64 GECKO(115765) ==115769==at 0x4021BF4: strncmp (strcmp.S:175)
143:39.64 GECKO(115765) ==115769==by 0x400655D: is_dst (dl-load.c:214) 


This indicates that 'strncmp' should be re-directed from ld-linux-x86-64.so.2:
=
diff --git a/shared/vg_replace_strmem.c b/shared/vg_replace_strmem.c
index 3b42b3a87..8272a3ae7 100644
--- a/shared/vg_replace_strmem.c
+++ b/shared/vg_replace_strmem.c
@@ -710,6 +710,7 @@ static inline void my_exit ( int x )
  STRNCMP(VG_Z_LIBC_SONAME, __GI_strncmp)
  STRNCMP(VG_Z_LIBC_SONAME, __strncmp_sse2)
  STRNCMP(VG_Z_LIBC_SONAME, __strncmp_sse42)
+ STRNCMP("ld-linux*.so*", strncmp)

 #elif defined(VGO_freebsd)
  STRNCMP(VG_Z_LIBC_SONAME, strncmp)
=
For instance, such a change is relevant to glibc-2.33-21.fc34.x86_64:
$ readelf --all /lib64/ld-linux-x86-64.so.2 | grep strncmp
  1706: 00022d30  6233 FUNCLOCAL  DEFAULT   13 strncmp
$


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Question: bug in user code, valgrind or glibc?

[John Reiser]

(Wait, I see  "279:13.65 GECKO(392456) ==392459==    by 0x488D2D3: 
dlopen@@GLIBC_2.2.5 (dlopen.c:87)"
Version 2.2.5 is not the same as the version reported for glibc. Hmm? )


The "@@GLIBC_2.2.5" is the linking symbol version assigned by glibc.
This effectively is an ABI version, and the ABI for dlopen
has not changed for many years, even though other parts of
glibc have changed; one recent release is glibc-2.33.

The real key to Chiaki's problem is:

279:13.65 GECKO(392456) ==392459== Invalid read of size 8
279:13.65 GECKO(392456) ==392459==at 0x4021BF4: strncmp (strcmp.S:175) 

which says that this 'strncmp' was not re-directed by valgrind.
Re-running valgrind with the additional command-line parameter
"--trace-redir=yes" will help provide more information.
Probably the run can be stopped after the first actual dlopen,
because that should be enough to trigger all the redirections
that matter here.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Question about Valgrind tool in Intel new platform

[John Reiser]

On 4/20/22 05:18, Yang Zhong wrote:


   The AMX is the NEW feature in Intel new platform and from host, we can
   find below cpu flags:

   amx_bf16, amx_tile, amx_int8

   The SPEC can be found in:
   
https://software.intel.com/content/dam/develop/external/us/en/documents/architecture-instruction-set-extensions-programming-reference.pdf

   The issue I mentioned should be related with AMX features missed in
   valgrind emulated CPU. If someone will implement this feature on valgrind,
   I can help verify. Thanks!


If you really want to help, then start today by collecting and/or writing 
actual code
that emulates the hardware that implements the feature.  Collect (or find, or 
write)
the code from Chapter 3, "INTEL® AMX INSTRUCTION SET REFERENCE, A-Z", of that 
.pdf.
Create actual subroutines and data declarations, and *test* it against your 
apps.
Put the code into a public repository such as GitHub.

The top-level function should be something like

   unsigned char const *emulate_amx(  // returns next instruction pointer
  unsigned char const *ip,  // pointer to first byte of instruction stream
  unsigned long *general_registers[16],  // hardware state
  unsigned long long *zmm_registers[16],  // zmm (ymm, xmm) registers
  struct Xsave *xsave_area,  // tile registers etc.
  ...
   }

which if successful returns a pointer to the next instruction, else an error 
code
which is the negative of a small positive integer.

Such code will go a long way towards getting AMX supported by valgrind,
because it will enable valgrind-developers to focus on implementing valgrind
instead of on finding, de-ciphering, and mentally interpreting documentation.



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Memory leak not detected

[John Reiser]

I think I found the problem. It seems valgrind doesn't detect memory leaks 
related to mmap. Why is this the case?


A memory leak is a block that is allocated by 
malloc/calloc/realloc/reallocarray,
not yet free()d, and with no in-process pointers to it.
mmap is not malloc, and the result of mmap() cannot be a memory leak.
Run "strace -e trace=mmap,mmap2,munmap,mremap ./my_app args..."
or use a debugger to put a breakpoint on appropriate calls.



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Possible bug in valgrind uninitialized variable detection (negative array index)

[John Reiser]

At 2021-11-10 01:18Z, Kyryl Melekhin wrote:

Ok, stop. I forgot, the executables likely won't work because my MuslC was
-march native optimized. And obviously static linking will include that code.


Whn I look at this file:
$ ls -l piketcc  # compiled by tcc
-rwxr-xr-x. 1 user group 80208 Nov 10 20:38Z  piketcc
$ sha256sum piketcc
6579786352c53de2fc8dc8322b866256870b911fc1b700202889b6fee9a45ff4  piketcc

disassembled by gdb, and next examined in a text editor, then I see
curious manipulation of the stack pointer %rsp:

Dump of assembler code for function re_pikevm:  [VLA = Variable-Length Array]
:g/%rsp,/p   ## direct reads of the stack pointer
   0x0040235f <+1>: mov%rsp,%rbp  # Frame pointer at entry
   0x004023e1 <+131>:   mov%rsp,-0x88(%rbp)  # remember the address 
of a VLA
   0x004023f2 <+148>:   mov%rsp,-0x80(%rbp)
   0x00402416 <+184>:   mov%rsp,-0x98(%rbp)
   0x0040243d <+223>:   mov%rsp,-0xa8(%rbp)
   0x00402489 <+299>:   mov%rsp,-0x7a1f8(%rbp)
   0x004024b3 <+341>:   mov%rsp,-0x7a208(%rbp)

:g/,%rsp/p   ## writes to the stack pointer
   0x00402362 <+4>: sub$0x7a240,%rsp  # allocate fixed portion 
of stack frame
   0x004023eb <+141>:   sub%rax,%rsp  # allocate a VLA: %rsp -= %rax
   0x004023ee <+144>:   and$0xfff0,%rsp  # 16-byte 
align a VLA
   0x0040240f <+177>:   sub%rax,%rsp
   0x00402412 <+180>:   and$0xfff0,%rsp
   0x00402436 <+216>:   sub%rax,%rsp
   0x00402439 <+219>:   and$0xfff0,%rsp
   0x00402482 <+292>:   sub%rax,%rsp
   0x00402485 <+295>:   and$0xfff0,%rsp
   0x004024ac <+334>:   sub%rax,%rsp
   0x004024af <+337>:   and$0xfff0,%rsp
   0x004024fa <+412>:   mov-0x88(%rbp),%rsp
   0x004026c4 <+870>:   mov-0x7a208(%rbp),%rsp
   0x004026ec <+910>:   mov-0x7a208(%rbp),%rsp
   0x004026f3 <+917>:   mov-0x7a208(%rbp),%rsp
   0x0040272c <+974>:   mov-0x7a208(%rbp),%rsp
   0x0040278d <+1071>:  mov-0x7a208(%rbp),%rsp
   0x004027de <+1152>:  mov-0x7a208(%rbp),%rsp
   0x00402e3e <+2784>:  mov-0x7a208(%rbp),%rsp
   0x00402e8c <+2862>:  mov-0x7a208(%rbp),%rsp
   0x00402f63 <+3077>:  mov-0x7a208(%rbp),%rsp
   0x00402fbc <+3166>:  mov-0x7a208(%rbp),%rsp
   0x0040309c <+3390>:  mov-0x7a208(%rbp),%rsp
   0x004030fd <+3487>:  mov-0x7a208(%rbp),%rsp
   0x0040314e <+3568>:  mov-0x7a208(%rbp),%rsp
   0x00403683 <+4901>:  mov-0x88(%rbp),%rsp
   0x00403813 <+5301>:  mov-0x88(%rbp),%rsp
   0x00403824 <+5318>:  mov-0x88(%rbp),%rsp


When run with command-line arguments "./piketcc abc abc", then examination
of all the "mov -0x7a208(%rbp),%rsp" instructions shows that the value
in register %rsp does not change.  I wonder if valgrind does something
strange here, such as marking some portion of the fixed frame as uninit
even though nothing changes.

The corresponding pikegcc never re-loads %rsp after allocating the VLAs:
$ ls -l pikegcc
-rwxr-xr-x. 1 user group 72960 Nov 10 20:37Z pikegcc
$ sha256sum pikegcc
952ce60eb5f66445f08d8ffc14b348febdefc99f4985cd4e725ae3d1682246c8  pikegcc

:g/%rsp,/p  # direct reads of stack pointer %rsp
   0x40328d :  mov%rsp,%rbp
   0x0040328d <+1>: mov%rsp,%rbp
   0x004032ca <+62>:mov%rsp,%rax
   0x00403395 <+265>:   mov%rsp,%rax
   0x00403406 <+378>:   mov%rsp,%rax
   0x00403489 <+509>:   mov%rsp,%rax
   0x00403523 <+663>:   mov%rsp,%rax
   0x004035a7 <+795>:   mov%rsp,%rax
:g/,%rsp/p  # writes to register %rsp
   0x403299 : sub$0x7a298,%rsp
   0x00403299 <+13>:sub$0x7a298,%rsp
   0x00403392 <+262>:   sub%rax,%rsp  # allocate VLA; %rax is 
pre-aligned to (0 mod 16)
   0x00403403 <+375>:   sub%rax,%rsp
   0x00403486 <+506>:   sub%rax,%rsp
   0x00403520 <+660>:   sub%rax,%rsp
   0x004035a4 <+792>:   sub%rax,%rsp
   0x00404956 <+5834>:  mov%rbx,%rsp
   0x0040496d <+5857>:  lea-0x28(%rbp),%rsp  # begin subroutine 
epilog

Investigation continues...








___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Possible bug in valgrind uninitialized variable detection (negative array index)

[John Reiser]

On 11/9/21 14:16, Kyryl Melekhin wrote:

Hello,

I am almost certain to have found a bug in valgrind.
The false positive error appears only when compiled with
tcc compiler. The platform is x86_64 linux, musl.

I can reproduce it in my regex engine and I have created
the following branch for you to check it out:
https://github.com/kyx0r/pikevm/tree/valgrind_bug

>[[snip]]

If the problem is compiler-dependent, and if pikevm is as small as advertised,
then the best thing for *you* to do is to produce two complete runnable
executable programs, which are "the same" except that one has the suspected
bug (thus is compiled with tcc for x86_64, and linked with musl to run
under Linux), and the other does not (the same source compiled with some other
compiler [specify and include its version], and linked with musl to run under
Linux.)

Provide a URL to each executable file.  Almost nobody will go to the trouble
of re-creating your unspecified software build environment (which version of
tcc and where to get it, which version of musl and where to get it, etc.)
just to investigate the alleged bug.

Your recipe [snipped above] does not matter.  If *you* cannot be bothered to
execute the recipe and provide URL to the results, then it is extremely
likely that no one else will bother, either.  Various hosting services
provide no-cost or low-cost download service, and even GitHub allows attachments
and other ways to provide access to non-humongous executable files.  Use one.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Very slow execution under Fedora 34

[John Reiser]

I am running valgrind on my PC with dual boot Windows 10 and Fedora 34.

Running the same test on Ubuntu 20.04 (under Windows 10 WSL2) valgrind runs in 
less than a second, but on Fedora 34 is very slow, several minutes slow.

On Fedora 34 it looks like the time spent is reading symbols.

This is the part that takes most of the time:

--23524-- Reading syms from /usr/lib64/libstdc++.so.6.0.29
--23524--   Considering 
/usr/lib/debug/.build-id/bd/d633ff5da0bba64d19ecf277a9eed7001da127.debug ..
--23524--   .. build-id is valid
--23524--   Considering 
/usr/lib/debug/.build-id/bd/../../../../../usr/lib/debug/usr/lib64/../../.dwz/gcc-11.2.1-1.fc34.x86_64
 ..
--23524--   .. build-id is valid

[[snip]]


What could be the problem? GGC 11 perhaps?


There have been some hints of trouble with the DWARF-5 symbol reader.
Thus a work-around might be to avoid DWARF-5 by using an older gcc.

If you can, please run "perf record" and then "perf report",
and copy+paste (or attach) info into a Bug Report (see https://valgrind.org).
Then post the bug link here with a teaser.



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Why valgrind can't see this error?

[John Reiser]

On 9/3/21 12:31 PM, Eric Chamberland wrote:

Hi,

I have a simple test and valgrind seems to not see the error:

cat fread.cc && clang++ -o fread fread.cc && valgrind ./fread
#include 
#include 
#include 

int main(int argc, char ** argv){
     int lA {1};
     FILE * f = fopen ( argv[0] , "rb" );
     fread(,2*sizeof(int),1,f);
     std::cout << "Hello: "<< lA << std::endl;
     return 0;
}


This report is interesting only because it is a bad example:
it does not specify what is the supposed error.
If you don't say what you believe it is, then how are valgrind developers to 
know?

Besides, the "memcheck error" is covered in the valgrind FAQ.
Look it up in paragraph "4.6.  Why doesn't Memcheck find ..."
The second and third errors are the logic errors of not checking
the return value of fopen and fread.
The fourth error is not documenting the expected invocation command line.
The fifth error is not checking argc.
The sixth error is not documenting the expected format of the input file.
Are you sure that you really are a programmer?


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Valgrind terminates at AVX instruction with "unrecognised instruction"

[John Reiser]

I'm using Valgrind 3-13-0 on Ubuntu 18.04.  The package repository has 3-13-0 
as its latest version, so if I want 3-17-0 I will need to install from source.  
But my question is about AVX instructions that have been supported since before 
3-13-0.


Copy+Paste the entire error message here, including the dump of the actual hex 
instruction bytes.
(You may hide the names of your files, if you wish.)


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] how to attach valgrind to more than one process at a time

[John Reiser]

if i want to attach the valgrind for more than one process at the same time 
what is the command/option to use.

There is no such command or option.  Each valgrind tool applies to only one 
process.
The closest you can come is to invoke each process using a (separate) valgrind 
tool.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] How to include the Valgrind stack traces in a stand-alone debug version?

[John Reiser]

For the example given, the backtrace command of gdb-8.3 already displays 80%
of the requested information for code compiled by g++-9.3.1 using -g.

The request:
> If compiled with -g, the debug output will display
> (1) C/C++ names down into the standard library
> (2) source code names and signatures
> (3) including template instantiations
> (4) file names
> (5) line numbers

(gdb) backtrace
#0  __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x77aac895 in __GI_abort () at abort.c:79
#2  0x00401144 in bar () at traceback-test.c:6
#3  0x00401154 in foo () at traceback-test.c:12
#4  0x00401134 in main () at traceback-test.c:17

valgrind-3.17.0:
==16820== Process terminating with default action of signal 6 (SIGABRT): 
dumping core
==16820==at 0x4BFCE35: raise (raise.c:51)
==16820==by 0x4BE7894: abort (abort.c:79)
==16820==by 0x401143: bar() (traceback-test.c:6)
==16820==by 0x401153: void foo(int) (traceback-test.c:12)
==16820==by 0x401133: main (traceback-test.c:17)

In this example, item (3) is the only essential difference.
valgrind:
 void foo(int) (traceback-test.c:12)
contains result type and argument type, while
gdb:
 in foo () at traceback-test.c:12
lacks "void" and "(int)".

For items (1), (2), (4), and (5) the gdb output contains the same information
as the valgrind output.  In addition, gdb gives more information for (1):
the complete internal path for standard library code
 ../sysdeps/unix/sysv/linux/raise.c:50
in contrast to valgrind's
 (raise.c:51)

So, any request for a better backtrace should be much more explicit than what 
was posted originally.


On 5/26/21, Martin Licht via Valgrind-users wrote:

Addressing the first point: what Valgrind's tracer does better than others is 
fetching more source code information and semantics. This can shown immediately 
with the following example:

```
#include 
#include 

inline void bar()
{
     abort();
}

template
inline void foo(T)
{
     bar();
}

int main()
{
     foo(5);
     return 0;
}
```

If compiled with -g, the debug output will display (1) C/C++ names down into 
the standard library (2) source code names and signatures (3) including 
template instantiations (4) file names (5) line numbers, among other things. I 
would be great to have a stack tracer like that.

The prettiest alternatives without Valgrind go along the lines of
https://eli.thegreenplace.net/2015/programmatic-access-to-the-call-stack-in-c/
using libunwind and cxxabi. This still is not as close to the source as 
Valgrind's output.



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] How to include the Valgrind stack traces in a stand-alone debug version?

[John Reiser]

On 5/24/21, Martin Licht via Valgrind-users wrote:


I think the Valgrind stack tracer is pretty great and I would like to use it as 
a substitute for `backtrace` in my C++ debug builds.


It would help to give an explicit list of why valgrind's backtrace() is "pretty 
great"
in contrast to GNU's.  The comment
 
https://blog.mozilla.org/nnethercote/2011/01/11/using-valgrind-to-get-stack-traces/#comment-438
identifies one item: GNU backtrace() shows only global (non-static) symbols.
What else?

Also, a detailed list would make a good request for enhancement
at https://www.gnu.org/software/libc/bugs.html ,
especially if accompanied by an actual test case
that shows how much better valgrind backtrace() is currently.

--



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] printing the values of arguments for strcpy(3), memmove(3), ...

[John Reiser]

The reason was at the end of debugging that we replaced in some central
place of the server a function call (due to vg messages about
overlapping args)

strncpy(dst, src, n);

by

memset(dst, 0, n);
memmove(dst, src, n);

which is not fully equivalent because strncpy(3) will stop at the first
\0 byte in src, while memmove(3) will copy n bytes, regardles if they
are valid bytes in src. As this was in some low level function, it
generated a mass of the above vg messages.

[[snip]]

Any thoughts about this?


You may have a much bigger problem than you realize.  Take paper
and pencil; write TEN TIMES (this is not a joke!):

 strncpy(dst, src, n) always over-writes exactly n bytes
 (namely dst[0..(n-1)]), regardless of strlen(src).

A large fraction of lexical calls to strncpy are incorrect;
the code just happens to work "by accident".

First, if there is any overlap between the intervals dst[0..(n-1)]
and src[0..(n-1)] then the result is undefined.  The implementation
of strncpy is allowed to read and write bytes in ANY order: lowest
index first, highest index first, single byte at a time, multiple
bytes at a time, interleaving Read and Write in any order (including
writing into the same byte multiple times, or writing an incorrect
value but correcting it later), etc.  Also, all str* functions are
allowed to fetch beyond src[1+ strlen(src)] as long as there can be
no SIGSEGV; and to store into dst[n] and beyond, as long as there is
no change there.  So any byte that is within the memory words or
cache lines that cover src[] or dst[] is fair game to be included
in a memory operation of strncpy.

Second, if (strlen(src) < n) then strncpy zeroes the remaining bytes
through dst[n-1].

Third, if (strlen(src) >= n) then dst is not NUL terminated.

Recommendation: search all the source code of all the projects
of your entire team/department/company for strncpy, and fix the bugs.

--


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] [Need Help] Valgrind on Cavium-Octeon-3

[John Reiser]

mihir amrelia wrote:

file /var/tmp/cavium/bin/valgrind
/var/tmp/cavium/bin/valgrind: ELF 64-bit MSB executable, MIPS, MIPS64 rel2 
version 1 (SYSV), dynamically linked, interpreter /lib64-f, for GNU/Linux 
2.6.32, not stripped

How to fix this?


Tom Hughes via Valgrind-users wrote:

No idea - that will be down to your cross build toolchain.



Diagnose by something like:
strace -f -o strace.out -e trace=execve -v -s 400 gcc hello.c
then search for "lib64-f" in strace.out.

For a native compile tool chain the relevant piece in strace.out is something 
like:
execve("/usr/bin/ld", ["/usr/bin/ld", ...  "-dynamic-linker", 
"/lib64/ld-linux-x86-64.so.2", ...
which would be changed by something like
gcc -Wl,-dynamic-linker,path_to_eventual_dynamic_linker ...



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] 3.16.1 RPi 3b+

[John Reiser]

On 2020-12-07 20:22 UTC, John A wrote:
 [[attachment smime.p7m]]

Send the body of the message in plain text,
perhaps crypto-signed with the signature in an attachment.
Nobody pays any attention to a .p7m body.



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Automated report for valgrind

[John Reiser]

I would like to ask if there is any automated reporting tool which processes the output of the 
valgrind tool and also scans the code in order to do a "blame" or "annotate" 
per developer.


The real error (the place that needs fixing) can be several levels up the call 
chain,
and in C++ is not always the most-recent non-STL code.  Identifying the root 
cause
can require an experienced human in many cases.



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] running valgrind on dpdk

[John Reiser]

On 2020-09-29  Prujan, Michael wrote:


I’m running valgrind-3.16.1 on application with DPDK.

I got the following errors:

ERROR: This system does not support "FSGSBASE".


That's correct: the virtual machine that valgrind exports to the app,
does not support FSGSBASE.  The valgrind source says:
./VEX/priv/guest_amd64_helpers.c:/* Don't advertise FSGSBASE 
support, bit 0 in EBX.  */

Perhaps you could develop the support for fsgsbase, and submit the 
implementation patch?


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Partial heap profiling with Massif

[John Reiser]

On 2020-09-17 LEPAREUR Loic wrote:


Several years ago, I developed a Massif patch to let the client code select 
which part of the code should be profiled with Massif.


Today this is much less interesting unless you compare and contrast with
https://github.com/KDE/heaptrack .  Do a web search for "heaptrack vs massif".
Consider particularly "A Faster Massif" in  https://milianw.de/tag/heaptrack ,
and  https://milianw.de/tag/massif-visualizer .


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] massif & counts per type

[John Reiser]

On 2020-09-11 at 10:50 UTC, folkert wrote:
   [snip]]

This morning I came up with an other solution: I made a LD_PRELOAD
wrapper which counts every malloc-call. Decided that allocated-type is
not really required in my case, but to know which malloc did it would
work as well.


For a random C++ program, then most calls to malloc are made by 'operator new'
or some closely-related flavor.  After that comes std::string::alloc<...>.
You *really* want 'heaptrack'.  Get it (and libunwind)!  Use it!
Do not waste your time trying to concoct anything else.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] compat_ioctl cmd does not match even if it shows same value

[John Reiser]

long mgr_compat_ioctl(struct file *pFile, unsigned int cmd, unsigned long arg)
{
 int err = -EFAULT;
 //unsigned int openLink = kIoctlOpenEthernetLink;
 unsigned int openLink = 3222829167;


"3222829167" is not a legal 32-bit value in source code.  You MUST use 
"3222829167u"
with a trailing 'u'.  Do not post or reply to this mailing list until you have 
changed
the source, re-compiled, re-linked, and re-run the test.



 printk("cmd 0x%x/%u, openLink 0x%x/%u\n", cmd, cmd, openLink, openLink);


//  [409204.415924/1] cmd 0xc018786f/3222829167, openLink 0xc018786f/3222829167

The documentation for ioctl(), as shown by running the command "man 2 ioctl",
says that the prototype is:

   int ioctl(int fd, unsigned long request, ...);

Notice that the second parameter has type "unsigned long", which is 64 bits.
In contrast, the definition of this function 'mgr_compat_ioctl' has a second
parameter type of "unsigned int", which is 32 bits.  Beware of this difference.
[Also note that the width of the return value differs: 'int' in the 
documentation,
'long' in the implementation; but this should not matter here.]

Try an experiment: change the implementation to:

   long mgr_compat_ioctl(struct file *pFile, unsigned long cmd, unsigned long 
arg)

where the second parameter has 'long' width instead of 'int'.  If necessary,
(for instance, in the "struct file_operations mgr_fops" table of function 
pointers)
then cast the type of the function pointer _compat_ioctl to hide the 
difference
in the type of the second parameter.  At the same time, change the printk format
conversions corresponding to 'cmd' to become "0x%lx/%lu" which has two 'l' 
modifiers.

The experiment might reveal that the second parameter to mgr_compat_ioctl is 
being passed
a 64-bit value whose upper 32 bits are not all zero.



 if (openLink == cmd) {
 printk("match\n");
 } else {
 printk("no match: cmd 0x%x/%u, openLink 0x%x/%u\n", cmd, cmd, 
openLink, openLink);
 }


Post the assembly-language code for the function mgr_compat_ioctl.  The safest 
way
is to use "(gdb) disassemble mgr_compat_ioctl" or "objdump --disaassemble",
but "gcc -S" usually is OK.  We need to see EXACTLY what instructions are 
generated.

--


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] compat_ioctl cmd does not match even if it shows same value

[John Reiser]

I have a 32 bit application (user space) which communicate with a kernel module 
through compat_ioctl(). My system is

# uname -a

Linux chassis1-board1-port5 3.10 #1 SMP Fri Apr 24 02:31:48 PDT 2020 mips64 
GNU/Linux


Which version of valgrind?

The source code of valgrind:
commit 24b247aec5397cad5f6cfcf885f118e90fea8735 (HEAD -> master, 
origin/master, origin/HEAD)
Date:   Sat Aug 15 16:54:14 2020 +0200
does not contain the string 'compat_ioctl' anywhere, so you must show us the 
prototype
and the environment (32-bit or 64-bit) for compat_ioctl.


Ioctl function is following:

long mgr_compat_ioctl(struct file *pFile, unsigned int cmd, unsigned long arg)

inside this function definition, I am getting correct cmd value e.g. 0xc018786f.


The fact that you write '0xc018786f' here, but '3222829167' in the code,
shows that you are not sufficiently paranoid.  First, if the bit pattern is 
important
then you should write hex.  If you insist on decimal, then you should write 
'3222829167u'
to remind yourself and the compiler that the value is unsigned; otherwise 
because
3222829167 exceeds INT_MAX then a compiler is allowed to interpret it as 
-1072138129
(or ANY VALUE WHATSOEVER!!!)
Then, it is very likely that your problem lies in a mismatch of width (64-bit 
vs 32-bit)
and/or signedness at one or more interfaces (subroutine call or system call).
You say "printk shows same value" but you did not say what format conversion
you specified to printk, therefore no one can determine what the actual value 
is.
This is likely to be important, because printk is implemented using "..." 
varargs,
and on most 64-bit machines that means that most scalar actual arguments are 
promoted
to 64-bit width upon the transition into the varargs mechanism, and it is 
UNSPECIFIED
whether the conversion from 32-bit to 64-bit is sign-extended or zero-extended.
That makes it extremely important that each varargs access uses the desired 
width
and signedness.

Due to the possibility of bugs, the only way to be sure of what is happening
is to look at the assembly-language code, and examine registers and values
while single-stepping actual execution.

--


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Original Path

[John Reiser]

On 7/20/20 23:14 UTC, Chithkala Dhulipati wrote:


I wanted to use valgrind for profiling my programs. What I am looking for is a 
list of functions called and a path to those functions. When I previously used 
gprof for this, there was no option that could produce the original path where 
the functions where found. Is there a way I can achieve this?


The terms "path to those functions" and "original path where the functions were 
found"
are not well-defined.  Please provide actual literal examples of what you seek,
as well as an explanation of how the existing valgrind tracebacks are not 
sufficient.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] MySQL related messages

[John Reiser]

After a few private emails and --num-callers=50, then the original poster 
reports:

   mysql_library_end() was missing. Error messages have gone now.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] MySQL related messages

[John Reiser]

On 6/7/20 16:11 UTC, James Read wrote:

Any idea what this means?:

==56082== 16,528 bytes in 1 blocks are possibly lost in loss record 409 of 409


Help yourself; that question is bad lazy.  There is a manual with extensive 
documentation.
A brief search of the web will reveal the answer.  The manual contains FAQ that 
answers this very question.



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] DHAT speed

[John Reiser]

On 5/27/20 Paul FLOYD wrote:


Well, no real surprises. This is with a testcase that runs standalone in about 
5 seconds and under DHAT in about 200 seconds (so a reasonable slowdown of 40x).

# Overhead  Command   Shared Object
Symbol
#   ...  ..  

#
29.11%  dhat-amd64-linu  dhat-amd64-linux[.] interval_tree_Cmp
21.13%  dhat-amd64-linu  perf-26905.map  [.] 0x0010057a25f8
13.32%  dhat-amd64-linu  dhat-amd64-linux[.] vgPlain_lookupFM
 9.56%  dhat-amd64-linu  dhat-amd64-linux[.] dh_handle_read
 8.83%  dhat-amd64-linu  dhat-amd64-linux[.] vgPlain_nextIterFM
 4.66%  dhat-amd64-linu  dhat-amd64-linux[.] check_for_peak
 1.85%  dhat-amd64-linu  dhat-amd64-linux[.] vgPlain_disp_cp_xindir
 1.32%  dhat-amd64-linu  [kernel.kallsyms]   [k] 0x8103ec0a
 1.00%  dhat-amd64-linu  dhat-amd64-linux[.] dh_handle_write


To me this suggests two things:

1) investigate the coding of the 4 or 5 highest-use subroutines 
(interval_tree_Cmp,
vgPlain_lookupFM, dh_handle_read, vgPlain_nextIterFM)

2) see whether DHAT might recognize and use higher-level abstractions
than MemoryRead and MemoryWrite of individual addresses.  Similar to memcheck
intercepting and analyzing strlen (etc.) as a complete concept instead of as its
individual Reads and Writes, perhaps DHAT could intercept (and/or recognize)
vector linear search, vector addition, vector partial sum, other BLAS routines, 
etc.,
and then analyze the algorithm as a whole.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] DHAT speed

[John Reiser]

 > So (4 * 5 * 10 * 3) is a slowdown of 600X, which turns 10 minutes into 100 
hours.

What I'm seeing is a DHAT-only slowdown that is much more than that.


Running 'perf' is likely to give data and strong hints about what is going on.
The overhead of 'perf' is only a few percent.

perf record valgrind --tool=DHAT <> ./my_app <>
perf report  > perf_output.txt

The "perf record ..." will stop shortly after the valgrind sub-process 
terminates.
You don't have to wait for DHAT to finish; just 'kill' it after a while.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] DHAT speed

[John Reiser]

The server has 48Gbytes of RAM and only about 6Gbytes is being used.

The executable is quite big

text data bss dec hex filename
57369168 417156 20903108 78689432 4b0b498 [snip]

The run under DHAT is using about 2Gbytes virtual and 1.5Gbytes resident 
according to htop. Running standalone those are about 750M and 350M 
respectively.


Some hardware cache+memory delays:
   L1 hit3 cycles  ( 32KB size)
   L2 hit   11 cycles  (256KB size)
   L3 hit   25 cycles  (4MB to 40MB size)
   miss180 cycles
The dynamic RAM chips commonly used for main memory have stayed the same speed
for over 25 years: 60 nanoseconds from CAS (Column Address Strobe) to DataOut.
If the CPU runs at 3GHz, then a cache miss costs at least 180 cycles.
A quick estimate of (largest and slowest) cache size is given by the "cache 
size"
line from /proc/cpuinfo:
-
$ sed 9q  < /proc/cpuinfo  # on a 8-year old consumer-grade machine
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 42
model name  : Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz
stepping: 7
microcode   : 0x2f
cpu MHz : 1599.982
cache size  : 6144 KB
-

Assume that your "big" server has 30MB of L3 cache.  For a resident set size of
350MB then that is a ratio of about 1:12.  For a resident set size of 1.5GB then
the ratio is about 1:50.  So right away, that's a hardware slowdown of 4X.

Valgrind runs every tool single-threaded.  So if your app averages 5 active 
threads,
then that is a slowdown of 5X.

Valgrind's JIT (Just-In-Time) instruction emulator has a slowdown.  Assume 10X 
(or measure nulgrind.)

Finally we get to "useful work": the slowdown of the tool DHAT.  Assume 3X.

So (4 * 5 * 10 * 3) is a slowdown of 600X, which turns 10 minutes into 100 
hours.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] DHAT speed

[John Reiser]

On 5/26/20, Paul FLOYD wrote:


I'm running DHAT on what I consider to be a relatively small example. 
Standalone the executable runs in a bit under 10 minutes. Based on the CPU time 
that we print after every 10% of progress, under DHAT the same executable is 
going to take about 422 hours - about two and a half weeks.

Does anyone have any ideas what could be causing it to be so slow? 


Please tell us about your environment.
(EVERY query should supply this information!)

Which version of DHAT?  Which hardware?  Which operating system and version?
Which compiler and version built DHAT?  Which compiler(s) built the program 
under test?

How big is the program?  On a Linux system, run "size ./my_app; ldd ./my_app"
for static size, and "ps alx | grep my_app" for total VIRTual and RESident size.
How much RAM is available for use?  How much demand paging is occurring?

There are standard performance tools that apply to EVERY executable program,
not just DHAT.  On a Linux system with a DHAT that was built with symbol
information retained ("-g" command-line option to gcc or clang, and
no symbol stripping during static binding by /usr/bin/ld or /usr/bin/strip),
what does 'perf' say?
perf record valgrind --tool=DHAT <> ./my_app <>
perf report  > perf_output.txt

A smart user would supply such information in the first post.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] How to disable leak check from inside a program

[John Reiser]

What would help a lot is to have a VALGRIND request, like
VALGRIND_DO_CLIENT_REQUEST_STMT, that we could use in our signal
handler to turn off leak checking.


In valgrind-3.16 (to be released in 3 days; RC2 available today) see
valgrind --help-dyn-options


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] HELP/Hint: valgrind error message

[John Reiser]

Below is the error coming when running valgrind , Do not know how to tackle it



valgrind --tool=memcheck  ./lte_tr069
==6660==
==6660== Warning: Can't execute setuid/setgid/setcap executable: ./lte_tr069
==6660== Possible workaround: remove --trace-children=yes, if in effect
==6660==
valgrind: ./lte_tr069: Permission denied


READ THE Warning MESSAGE.  It says *EXACTLY* what the problem is.
./lte_tr069 has one of the attributes setuid, or setgid, or setcap.
If you're clever enough to set such an attribute then you should
be clever enough to deal with the complaint from valgrind/memcheck.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Spurious errors during an abrupt program termination

[John Reiser]

On 5/14/20, Dalon Work wrote:


I have an application with two threads on linux which I was testing
under valgrind. We have a strange memory behavior that is leading to
an internal assert terminating the application, hence the
investigation. After running the application, I have many, many
errors, (invalid reads and writes), which all follow a similar
pattern:

Invalid read/write of size 4:
 at thread1_func()
 at thread1_func1()
 ...


The rule for dealing with output from memcheck is:
   Fix the first complaint.  Do not ignore it; FIX IT.
Many times the command-line option --track-origins=yes provides helpful clues.


Address 0x# is # bytes inside a block of size  free'd
 free()
 myAllocator::~myAllocator()
 __run_exit_handlers
 exit
 terminate_handler_sp
 thread2_func()
 thread2_func1()
 ...

The call stack from the free() stack is obviously from the second
thread (NOT the one that started the error, oddly enough), while the
invalid read is from the first thread.


Based on this evidence, the most likely scenario is thread2 decided to
(or was forced to) terminate, and started running exit handlers
for the whole process.  Meanwhile, thread1 continues running (thread1
has received no news that it should stop) and references blocks that
have been free()d by the termination handlers invoked by thread2.
So the termination handler should first rendezvous with all threads
before beginning to shutdown the process.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Calling arbitrary guest functions

[John Reiser]

I am trying to make a tool that intercepts the call to main, and then
call an arbitrary function within the guest with arbitrary function
arguments.


This can be done without valgrind by using LD_PRELOAD environment variable
and RTLD_NEXT (see "man dlsym"):

LD_PRELOAD=main_interceptor.so  ./my_app args...

where main_interceptor.so is a shared library that has a function main()
and that can call the original main() by using dlsym(RTLD_NEXT, "main").







___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] detecting uninitialized values in debug builds

[John Reiser]

On 3/2/20 22:02 UTC, Ben White wrote:
I’ve also been told that the g++ compiler will initialize all stack 
objects to zero when compiling for debug (the -g option).


Obviously you didn't try it.  g++ 9.2.1 does not do that.

$ cat foo.cpp
int g(int x, int y);

int f(int x)
{
int y;
return  g(x, y);  // uninit use of y
}

$ g++ -g -S foo.cpp
$ cat foo.s
.file   "foo.cpp"
.text
.Ltext0:
.globl  _Z1fi
.type   _Z1fi, @function
_Z1fi:
.LFB0:
.file 1 "foo.cpp"
.loc 1 4 1
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
subq$32, %rsp
movl%edi, -20(%rbp)
.loc 1 6 17
movl-4(%rbp), %edx   // -4(%rbp) is never initialized
movl-20(%rbp), %eax
movl%edx, %esi   // 2nd parameter to g
movl%eax, %edi
call_Z1gii
.loc 1 7 1
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size   _Z1fi, .-_Z1fi
  [[snip]]
.section.debug_str,"MS",@progbits,1
.LASF1:
.string "foo.cpp"
.LASF0:
.string "GNU C++14 9.2.1 20190827 (Red Hat 9.2.1-1) -mtune=generic 
-march=x86-64 -g"
.LASF3:
.string "_Z1fi"
.LASF2:
.string "/home/user"
.ident  "GCC: (GNU) 9.2.1 20190827 (Red Hat 9.2.1-1)"
.section.note.GNU-stack,"",@progbits
$


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] valgrind: Unrecognised instruction

[John Reiser]

vex amd64->IR: unhandled instruction bytes: 0xF3 0xF 0x1E 0xFA 0x41 0x56 0x41 
0x89


Follow the Bug Reports link at http://valgrind.org to file a bug report
at  http://bugs.kde.org/query.cgi?format=specific .

Please be sure to state the version of valgrind.  Run "valgrind --version".

The instruction 0xF3 0xF 0x1E 0xFA is 'endbr64'.


vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.n=0x0 ESC=0F
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=1
==23029== valgrind: Unrecognised instruction at address 0x4032e0.
==23029==    at 0x4032E0: __intel_new_feature_proc_init (in 
/home/arthur/Documentos/Prog.Paralela/intelseqkron)
==23029==    by 0x565282F: (below main) (libc-start.c:291)



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Valgrind Internal Error: Valgrind received a signal 11 (SIGSEGV) - exiting

[John Reiser]

3. How much physical RAM? How much swap space? (The string "out_of_memory" 
appears in the output.)

JK - [    0.00] Memory: 495376K/507904K available (5078K kernel code, 420K 
rwdata, 1704K rodata, 208K init, 328K bss, 12528K reserved, 0K highmem)

Not sure how to get swap space.


Run /usr/bin/top, which gives other useful statistics about resources, too.
On a 32-bit ARM RaspberryPi model 2 with 1GB RAM the output might begin like 
this
for an "idle" machine:
=
Tasks:  84 total,   1 running,  83 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.1 us,  0.1 sy,  0.0 ni, 99.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :924.1 total,582.1 free, 66.0 used,276.0 buff/cache
MiB Swap:  0.0 total,  0.0 free,  0.0 used.830.5 avail Mem
=




4. Was valgrind essentially the only process running?

JK – Definitely not.  The TR069 consists of a whole family of CCSP processes 
that communicate to each other via DBUS.  The TR069PA was however the only 
process running via valgrind

5. How many threads?

JK – 4 threads per CCSP process, including the one running valgrind.


So there are many CCSP processes, plus other processes, running on a box with
512 megaBytes of RAM and no swap space.  Remember that a process running 
valgrind
(memcheck) requires about 2 to 3 times the memory of a non-checked process.

You have exhausted the available RAM.  The "out of memory" string was a clue.

Reduce the number and size of simultaneous CCSP processes.  Reduce the number
and size non-CCSP processes.  Run valgrind (memcheck) only on the one CCSP
process that really interests you.  Do not use --trace-children=yes.  Instead,
make CcspTr069PaSsp into an executable "wrapper" shell script which identifies
the correct instance (perhaps by count of invocations), then runs valgrind
on a saved copy of the original CcspTr069PaSsp; else just runs the
saved copy without valgrind.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Valgrind Internal Error: Valgrind received a signal 11 (SIGSEGV) - exiting

[John Reiser]

I am receiving a valgrind Internal error upon startup of a multi-threaded 
application.  It appears to be related to the option track_origins as I was not 
seeing the issue without the track_origins option.  I am using the following 
valgrind options:  --trace-children=yesand --track-origins=yes.


Please tell us the following essential information:
0. You claim "a multi-threaded application" yet valgrind says "Command: /bin/touch 
...".  Explain.  [Is it implemented via busybox?]
1. Confirm that the machine architecture is 32-bit ARM.  (The string 
"memcheck-arm-linux" appears in the output.)
2. What is the make and model of the machine?  Is it a virtual machine, or real 
hardware?
3. How much physical RAM?  How much swap space?  (The string "out_of_memory" 
appears in the output.)
4. Was valgrind essentially the only process running?
5. How many threads?
6. Run without --trace-children=yes, then copy+paste here the HEAP SUMMARY and 
LEAK SUMMARY paragraphs.
7. What is the approximate allocation profile?  A zillion little blocks, or a 
few very large blocks, etc?
8. Which linux distribution and version?
9. Run "readelf --segments the_executable" and copy+paste here the output.
10. When the internal error happens (or shortly before), what does "ps -l" say 
about the process?


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Don't Instrument Wrapped Functions

[John Reiser]

On 1/25/20 5:28 PM, Ausitn Gadient wrote:

Hello!

Is there a clean way to prevent Valgrind from adding instrumentation to wrapped 
functions? For example, if I have a wrapper for the libc function “read()”, I 
do not want to instrument “read()’s” code.


Which tool(s) do you mean?

valgrind is an "umbrella" program which runs several tools
including memcheck (the default tool), helgrind, cachegrind,
drd, lackey, massif, and a few experimental tools such as
exp-bbv and others.  What you are asking depends on the tool.
In general, the answer is "No", but there may be exceptions
depending on the tool.

By its very nature, memcheck requires instrumenting
EVERY SINGLE INSTRUCTION, and this is IMPOSSIBLE to change.



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] valgrind: Heap block lo/hi size mismatch when trying to debug a C++ program running inside Docker container

[John Reiser]

On 11/13/19 at 04:18 UTC, Karthik Jayaraman wrote:

When trying to debug my C++ binary, I am running into the following issue.

valgrind: m_mallocfree.c:307 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' 
failed.

valgrind
: Heap block lo/hi size mismatch: lo = 1, hi = 4294967295.
This
  is probably caused by your program erroneously writing past the
end of a heap block and corrupting heap metadata
.  If
  you fix any
invalid writes reported by
Memcheck, this
  assertion failure will
probably go away
.  Please try that before reporting this as a bug.

   <>


Which version of valgrind?  (Run "valgrind --version".)
Which hardware, operating system, and version?
Which C++ compiler and version?

Did memcheck report any invalid writes?  Did you fix them?



But the interesting fact is, it works wonderfully well when same binary is 
running outside the container (on a VM). If my source binary has a memory link 
(as per Valgrind FAQs) I am puzzled as to why I am not encountering the issue 
when not running in a container.


If the operating system that runs inside the container does not layout
the address space of valgrind identically to the address space of valgrind
as laid out by the VM outside the container, then the results can differ.
(There might be a bug in memcheck, too.)

Re-run with "valgrind -v -v -v -d -d -d <>"
to get more information.  Copy+paste that info into an attachment
of a bug report; see the Bug Reports link on the page  http://valgrind.org .


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Building and Installing vlagrind 3.15.0 in an embedded Linux cross-compile environment

[John Reiser]

I am having some issues with the valgrind 3.15.0 build and install in a 
cross-compile environment where the resultant code is to run on a router which 
is embedded Linux.


You must create an absolute path name (starts with '/') that is the same
(as a character string) on the machine which does the cross-compiling
as on the target embedded environment.  Use that as --prefix= for ./configure .

On both machines that path will be a symlink ("ln -s").  On the cross-
compiling machine, set the symlink to be some directory that you can write;
such as:
mkdir $HOME/cross-valgrind-output
ln -s $HOME/cross-valgrind-output /common/absolute/pathname
and check via
ls -l /common/absolute/pathname  # on the cross-compiling machine
  /common/absolute/pathname -> $HOME/cross-valgrind-output

In the image being created for the target embedded environment,
set the symlink to be some directory such as:
ln -s /opt/valgrind /common/absolute/pathname
and check via
ls -l /common/absolute/pathname  # in the target embedded environment
  /common/absolute/pathname -> /opt/valgrind
As part of building the target embedded image, then copy the directory tree(s)
from $HOME/cross-valgrind-output/* to the image directory /opt/valgrind/ .


[Notice that this would be simpler if "--prefix=/opt/valgrind".
If you do not have permissions to "mkdir /opt/valgrind" on the cross-compiling
machine, then procure a second-hand x86_64 box, install your favorite
linux distribution on it, and use that box to do the cross-compiling.]


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] seemingly bogus error reports

[John Reiser]

==00:00:00:11.329 1533== Conditional jump or move depends on uninitialised 
value(s)
==00:00:00:11.329 1533==    at 0x7B0BCC2: ttci2n (in 
/home/interface/interface/oralib-12/lib/libclntsh.so.12.1)

[[snip]]

==00:00:00:11.329 1533==  Uninitialised value was created by a stack allocation
==00:00:00:11.329 1533==    at 0x407C67: HS_send2HS (HS_thr_out.c:231)



The problem with that report is that line 231 contains no explicit code:
static HS_IF_STATE HS_send2HS (HS_out_thread * myoutthr,

[[snip]]

{ ç line 231



I can’t find anything that’s allocated in that function that would be 
un-initialized later in the program,


As David Chapman replied earlier, then line 231 is the place where the compiler
constructed the stack frame.

Some local variable might be the destination of an assignment or copy from an
uninit variable.  In order to help find this, then re-run with the valgrind
command-line option
--track-origins=yes
which should give more information about the provenance of the uninit value.



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Running Valgrind on ndmp

[John Reiser]

1.      service ndmpd stop
2.       service ndmpd start
3.       valgrind -v --num-callers=50 --log-file=ndmp_valgrind_30_8.log 
--leak-check=full /usr/local/ndmp/ndmpd

echo $? Returns 1 after the 3rd command.


Does running ndmpd "by hand" work as the third step?
3. /usr/local/ndmp/ndmpd &   # start in background, note the PID
4. ps -ef   # does ndmpd show with the same PID as given by the shell?

If "service ndmpd start" does anything other than execute /usr/local/ndmp/ndmpd,
then it may be necessary to add a level of indirection through a shell script
that runs valgrind:

1. service ndmpd stop
2. mv /usr/local/ndmp/ndmpd /usr/local/ndmp/ndmpd.real
3. cat >/usr/local/ndmp/ndmpd 

Re: [Valgrind-users] Can't see the actual vars

[John Reiser]

==3232== Syscall param stat64(file_name) points to uninitialised byte(s)


file_name is the first (leftmost) parameter.


==3232==    at 0x49FD6B8: _xstat (xstat.c:48)
==3232==    by 0x41F23: stat (stat.c:51)
==3232==    by 0x1EC93: getList (util.c:1379)


> Looking at line 1379 from util.c:
> if (!stat(listfile, ))


==3232==    by 0x18E0F: _get_var (ngr.c:3868)
==3232==    by 0x19F33: get_var (ngr.c:4049)
==3232==    by 0xBB4F: main (daemon.c:346)
==3232==  Address 0x7d87ba8c is on thread 1's stack
==3232==  in frame #2, created by getList (util.c:1300)
==3232==  Uninitialised value was created by a stack allocation
==3232==    at 0x1E55C: getList (util.c:1300)



listfile does exist.


What is the declaration of listfile?  Is it an array, a pointer, ...?
It would be helpful to print its value:
fprintf(stderr, "\nlistfile='%s'\n", listfile);
just before the stat() call.


statbuf however, is simply defined as: struct stat statbuf;
It's not initialized by memset or something, is that what valgrind complains 
about?


No; the first line of the complaint indicates that the complaint
is about the file_name, the first parameter, which is read by stat().
The documentation (run the shell command "man 2 stat") explains that
the second argument is output-only.  The operating system kernel
writes to [nearly] all the statbuf, and reads none of it.

If the original presentation captures all the important information,
then it will be easy to construct a small stand-alone test case
that triggers the complaint in question.  Please try that.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] --track-origins option is not working

[John Reiser]

On 6/25/19 09:57 UTC, subhasish Karmakar wrote:

Hi,> Can someone help me to resolve this issue.


Did you read Julian Seward's response of Mon, 24 Jun 2019 21:10:48 +0200 ?

What does the shell command
file /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so
report?  If the output contains the word "stripped", then
that likely is the problem.  Rebuild so that it is not stripped.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Error report: Valgrind hangs after SIGKILL

[John Reiser]

I have detected the following issue while running Valgrind on a
multi-threaded application. Valbrind hangs if the application raises the
signal SIGKILLl to suicide.


Is the hang reproducible in a small test case, such as only two threads
that do "nothing" except possibly wait for synchronization and/or signals?


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Git access not possible

[John Reiser]

My computer is located in Germany, and I cannot clone the source with git 
(git://sourceware.org/git/valgrind.git).


If you post a copy+paste transcript of a terminal session
which shows the _exact_ command and error message, then
it is likely that you may get better suggestions.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] POSIX pthread counter (integer) overflow in valgrind drd_vc.c

[John Reiser]

|drd: drd_vc.c:96 (vgDrd_vc_increment): Assertion 'oldcount < vc->vc[i].count' 
failed.
My program was running a quite large volume of data (millions of records).


How many millions, and how long does the program run, both with an without drd?
It's quite possible to overflow the 'count', which is an unsigned 32-bit integer
(see drd/drd_vc.h.)  That's only 4300 times one million; I would not be 
surprised
by an overflow in one day of execution.

What version of drd?  (Run "valgrind --version".)
The drd addresses in the traceback are 0x3800; current drd uses 0x5800.
The other versions that you specified are somewhat old: gcc-4.8 (current is 
gcc-9.1)
and Linux 4.4.76 built 2017-07-14 (almost 2 years ago).


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] identifying possible leak

[John Reiser]

=16595== 1,008 bytes in 3 blocks are possibly lost in loss record 155 of 1,524
==16595==    at 0x483AB65: calloc (vg_replace_malloc.c:752)
==16595==    by 0x4012A32: allocate_dtv (in /usr/lib/ld-2.29.so 
)
==16595==    by 0x40133E1: _dl_allocate_tls (in /usr/lib/ld-2.29.so 
)


Anything allocated by a routine which is part of the dynamic linker (such as 
_dl_allocate_tls
in /usr/lib/ld-*.so) should be ignored.  The dynamic linker is well-known to 
leak,
and some of those leaks essentially cannot be eliminated.  In any case, you 
cannot do anything
about those leaks.  Besides, this leak is less than 340 bytes on average (1008 
/ 3),
and there are either 154 or (1524 - 154) leaks which are more important 
(larger).

[Next time, please state the version of valgrind that you ran.]


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] 答复: Some question about linker dlopen with valgrind

[John Reiser]

On 4/24/2019 0128 UTC, Wuweijia wrote:

Android Q

The libc  source  as below:


The purpose of a test case is to reproduce the problem.  What you wrote fails 
badly.
It does not compile, under ANY compiler: functions are used before they are 
declared.
It does not have the necessary #include statements.
It is not written in C language.  'reinterpret_cast' is C++.
It is not standard C++.  __has_builtin() (from Android #include) is only in the 
'clang' dialect.
It uses symbols that start with underscore ('_') without understanding what it 
is doing.
They're written with a leading underscore to warn you that you should not touch 
them.

You should have said:
   git clone https://android.googlesource.com/platform/bionic/
   git clone https://android.googlesource.com/platform/system/core

= test-libc.cpp
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


static void TestInitImpl() {
printf("%s enter\n", __func__);
//---This is most important  call,  If call  dlopen success, and then 
malloc trace is not available now; If Not success, the malloc trace is okay;
void * handle = dlopen("liblog.so",  RTLD_NOW );
printf("handle:%p\n", handle);
}

__attribute__((noinline))
static void __libc_preinit_impl() {
  // Register libc.so's copy of the TLS generation variable so the linker can
  // update it when it loads or unloads a shared object.
  TlsModules& tls_modules = __libc_shared_globals()->tls_modules;
  tls_modules.generation_libc_so = &__libc_tls_generation_copy;
  __libc_tls_generation_copy = tls_modules.generation;

  __libc_init_globals();
  __libc_init_common();

  // Hooks for various libraries to let them know that we're starting up.
 TestInitImpl();
}

__attribute__((constructor(1))) static void __libc_preinit() {
  // The linker has initialized its copy of the global stack_chk_guard, and 
filled in the main
  // thread's TLS slot with that value. Initialize the local global stack guard 
with its value.
  __stack_chk_guard = 
reinterpret_cast(__get_tls()[TLS_SLOT_STACK_GUARD]);

  __libc_preinit_impl();
}
=

export ADIR=$PWD  # after "git clone" above
# -I list: Android source is crap.
test-libc.so: test-libc.cpp
clang++ -shared -fPIC -g -nostdinc \
  -I$(ADIR)/bionic/libc/include \
  -I$(ADIR)/bionic/libc \
  -I$(ADIR)/bionic/libc/async_safe/include \
  -I$(ADIR)/core/liblog/include \
  -I/usr/lib/gcc/x86_64-redhat-linux/8/include \
  -I/usr/include \
  $< -o $@
=


>  void * handle = dlopen("liblog.so",  RTLD_NOW );  ---This is 
most important  call,  If call  dlopen success, and then malloc trace is not available now; 
If Not success, the malloc trace is okay;

So calling dlopen() while still in the initialization phase of the run-time 
linker,
causes trouble for valgrind.  Get the source, apply a debugger, and find out 
why.

Calling dlopen() from a DT_INIT, DT_INIT_ARRAY, or DT_PREINIT_ARRAY function
is a design error: the run-time linker makes NO guarantees about what happens.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Some question about linker dlopen with valgrind

[John Reiser]

   On the Android OS,  there is a question about the linker program 
with vaglrind memcheck.


Which version of Android?



   The 1^st  experiment,  the libc module *do*call the dlopen function 
to load some shared object, before the linker  call the pre_init functions (  
before transfer the cpu control to the main ), and then the valgrind *can  
not*trace malloc leak;

   The second experiment, the libc module *do not*call the dlopen 
function to load some shared object, before the linker  call the pre_init 
functions (  before transfer the cpu control to the main ), and then the 
valgrind *can*  trace malloc leak;

   I want to know why , and how to  make valgrind can trace memory 
leak, while  the libc module call the dlopen function to load some so, before 
the linker call the pre-init functions.


According to
   https://docs.oracle.com/cd/E19683-01/816-1386/6m7qcobks/index.html
the order of execution is:
  1. linker resolves and fetches all DT_NEEDED modules (shared libraries),
 and performs all relocations for the entire process image
  2. linker calls DT_PREINIT_ARRAY functions of the main program, in order
 (only a main program may have DT_PREINIT_ARRAY; a shared library MUST NOT)
  3. in dependency order (topological bottom-up) of all loaded modules (main 
program
 and shared libraries): linker calls DT_INIT and then DT_INIT_ARRAY (in 
order)
 for the module
  4. linker transfers control to the ElfXX_Ehdr.e_entry address of the main 
program

It is undefined what happens if a DT_PREINIT_ARRAY, DT_INIT_ARRAY, or DT_INIT 
function
calls dlopen, particularly if the newly-loaded module depends on any other 
modules,
whether or not those modules have been loaded already.  (The dependent module
might not be initialized yet.)


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Some question about linker dlopen with valgrind

[John Reiser]

   On the Android OS,  there is a question about the linker program 
with vaglrind memcheck;

   The 1^st  experiment,  the libc module *do*call the dlopen function 
to load some shared object, before the linker  call the pre_init functions (  
before transfer the cpu control to the main ), and then the valgrind *can  
not*trace malloc leak;

   The second experiment, the libc module *do not*call the dlopen 
function to load some shared object, before the linker  call the pre_init 
functions (  before transfer the cpu control to the main ), and then the 
valgrind *can*  trace malloc leak;

   I want to know why , and how to  make valgrind can trace memory 
leak, while  the libc module call the dlopen function to load some so, before 
the linker call the pre-init functions.

   If you want to add some args to trace, Please email me.

   Valgrind version 3.14.


Thank you for stating the version of Valgrind.

It is hard to follow and understand the descriptions of the first and second 
experiments.
Please construct two test cases of specific literal source code with recipes 
for compile
and linking, corresponding to the first and second experiments.  Those two cases
should be runnable under valgrind, and should illustrate the difference between 
them.





___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] 答复: [HELP] Android use LD to link the program but the valgrind can not report malloc leak;

[John Reiser]

On 4/8/19 4:54 PM, Wuweijia wrote:

localhost:/system/bin # ./valgrind -v --undef-value-errors=no  ./test
==30806== Memcheck, a memory error detector
==30806== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==30806== Using Valgrind-3.14.0-353a3587bb-20181007X and LibVEX; rerun with -h 
for copyright info



linker: Warning: "/system_Q_EA3/lib64/valgrind/vgpreload_core-arm64-linux.so" 
has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)
WARNING: linker: Warning: 
"/system_Q_EA3/lib64/valgrind/vgpreload_core-arm64-linux.so" has unsupported 
flags DT_FLAGS_1=0x421 (ignoring unsupported flags)
linker: Warning: 
"/system_Q_EA3/lib64/valgrind/vgpreload_memcheck-arm64-linux.so" has 
unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)
WARNING: linker: Warning: 
"/system_Q_EA3/lib64/valgrind/vgpreload_memcheck-arm64-linux.so" has 
unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)


Please visit https://bugs.kde.org/show_bug.cgi?id=406349
and enter the version of Android and/or /system_Q_EA3/bin/linker64
into an Additional Comment.  Also please attach the source code
of the test program ./test to the valgrind bug report.

The Android run-time linker /system_Q_EA3/bin/linker64
does not understand important flags in the DF_FLAGS_1
data item of the PT_DYNAMIC "segment" of
/lib64/valgrind/vgpreload_core-arm64-linux.so
and other valgrind shared libraries.
As a result, memcheck does not re-direct nor intercept calls
to malloc() or free().  This cripples memcheck.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] [HELP] Android use LD to link the program but the valgrind can not report malloc leak;

[John Reiser]

Elf file type is DYN (Shared object file)
Entry point 0x47000
There are 9 program headers, starting at offset 64



Program Headers:
   Type   Offset   VirtAddr   PhysAddr   FileSiz  
MemSiz   Flg Align
   PHDR   0x40 0x0040 0x0040 0x0001f8 
0x0001f8 R   0x8
   LOAD   0x00 0x 0x 0x0469bc 
0x0469bc R   0x1000
   LOAD   0x047000 0x00047000 0x00047000 0x10ee20 
0x10ee20   E 0x1000
   LOAD   0x156000 0x00156000 0x00156000 0x00a598 
0x221fa8 RW  0x1000
   DYNAMIC    0x15ee20 0x0015ee20 0x0015ee20 0x0001c0 
0x0001c0 RW  0x8
   GNU_RELRO  0x15a000 0x0015a000 0x0015a000 0x006598 
0x007000 R   0x1
   GNU_EH_FRAME   0x02a2a4 0x0002a2a4 0x0002a2a4 0x005ddc 
0x005ddc R   0x4
   GNU_STACK  0x00 0x 0x 0x00 
0x00 RW  0
   NOTE   0x000238 0x0238 0x0238 0x38 
0x38 R   0x4



Valgrind can not find memory leak with malloc;


Which version of valgrind?  (Run "valgrind --version".)

Please post the valgrind output just before and just after
the place where the report of memory leaks should appear.

Please re-run using "valgrind -v ..." and show the output
from the very beginning until the last REDIR message, such as:
   --15470-- REDIR: 0x4ebf390 (libc.so.6:malloc) redirected to 0x4c2edc9 
(malloc)
   --15470-- REDIR: 0x4ebf9e0 (libc.so.6:free) redirected to 0x4c2ffca (free)


I think maybe there is something different with GNU LD command; because there 
is two segment new；
Please focus on the text in blue;


The text that was originally posted to [valgrind-users] was all in black.  
There was no blue.

Please post the output from:
readelf --dynamic 
ldd 


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Valgrind on Android Suppressions

[John Reiser]

There's a bunch of errors reported [by valgrind] from the dynamic linker on 
Android, that I think can be suppressed.


For memory leaks, particularly if related to static initialization
and/or are bounded in small total size, then probably they can be added
to a list of errors to suppress by default on Android.
Such as: a file ./Android-x.y.supp at the top level of the valgrind source.
Enter a bug report (see http://valgrind.org/support/bug_reports.html)
and attach the suppressions as a file to the bug report.

For access errors, then start by submitting them to Android.
There's a good chance that they are real errors that Android should fix.
If Android declines, then file a _separate_ bug report
to add the complaints to the valgrind suppressions.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] location of stack allocation printed a at 0x8B43AF0: ??? ...

[John Reiser]

==24390==  Uninitialised value was created by a stack allocation
==24390==at 0x8B43AF0: ??? (in /home/sisis/guru/libcopz39.so)
==24390==



Can you check what file/line nr corresponds to 0x8B43AF0,
using another tool (gdb, or whatever) ?



Looks like this is near to 0x8B5DC3A: CatTmFilterExclude (CATTmFilter.c:215), 
may be in
the same source file.


0x8B43AF0 (identified by valgrind) is somewhat far from
0x8B5DC3A (identified by the poster)
=
  0x1a14a  d9fference

Use:
   (gdb) info shared
Example:
   $ gdb /bin/date
   (gdb) b main
   (gdb) run
   Breakpoint 1, main (argc=0x1, argv=0x7fffd4b8) at ../src/date.c:348
   (gdb) info shared
FromTo  Syms Read   Shared Object Library
0x77dd6f60  0x77df5080  Yes /lib64/ld-linux-x86-64.so.2
0x77a383a0  0x77b7f11f  Yes /lib64/libc.so.6
   (gdb) quit


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Getting Valgrind securely

[John Reiser]

 *And* I
have to clone the whole git repo when really I just want to install
the current release of the program

That is by design.  If *you* want to get the bits that way, then *you* must 
build valgrind.
Besides, the repo is not large, and building it is not long.
Someone whose email address ends in .ucsc.edu should have no resource problems.

If the goal is "install the current release" with the least hassle,
then you should consider installing the current release from a
Linux distribution such as Fedora or Debian.  The .rpm or .deb
is "signed by someone reputable".  It may even have some bugs fixed already.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] OT: Where is the location of Bzip2 download?

[John Reiser]

Where is the location of Bzip2 nowadays?


In practice: download the source to the .rpm package (Fedora, Red Hat, SuSE)
or the .deb package (Debian, etc.).  Within that is the original source
used by maintainers of the .rpm or .deb.  For instance on Fedora:

$ dnf download --source bzip2
bzip2-1.0.6-26.fc28.src.rpm548 kB/s | 785 kB 
00:01
$ rpm -ql -p bzip2-1.0.6-26.fc28.src.rpm
bzip2-1.0.4-bzip2recover.patch
bzip2-1.0.4-cflags.patch
bzip2-1.0.4-saneso.patch
bzip2-1.0.6.tar.gz   < the original source
bzip2-ldflags.patch
bzip2.pc
bzip2.spec
set-out-file-to-null.patch
$ rpm --install bzip2-1.0.6-26.fc28.src.rpm
$ ls -l rpmbuild/SOURCES/bzip2-1.0.6.tar.gz
-rw-rw-r--. 1 user group 782025 Sep 22  2010 rpmbuild/SOURCES/bzip2-1.0.6.tar.gz
$


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Does valgrind work with Boehm garbage collector?

[John Reiser]

    The execution recipe works for me on Fedora 28 using 
valgrind-3.14.0-7.fc28.x86_64.



Also, the default on Mac is to use addresses greater than (1ul<<32).


Because the program works when _not_ run under valgrind,
then the conclusion is that valgrind-3.14.0-7 has a bug
where it stores an address in 32 bits.

To find the bug in valgrind: invoke a debug version of valgrind-3.14
under lldb on Mac, and then invoke main.l.exe under that valgrind.
The SIGSEGV should happen inside valgrind itself, so use lldb
to find the bug.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Does valgrind work with Boehm garbage collector?

[John Reiser]

The execution recipe works for me on Fedora 28 using 
valgrind-3.14.0-7.fc28.x86_64.
I omitted dsymutil.  Why is it essential for you?


It is not essential.


Therefore omitting dsymutil will narrow the search for the problem(s).


$ rpm -q clang
clang-6.0.1-2.fc28.x86_64



Why there is no segmentation fault in your run?


What version of clang?  I showed that I used clang-6.0.1-2.fc28.x86_64.
Also, the default on Mac is to use addresses greater than (1ul<<32).
This catches some errors of storing an address in a 32-bit variable.
The default on Fedora is to start using addresses at 4MiB, which
saves 4 bytes of space in several important places, but in many
cases avoids noticing the problem of storing an address in 32 bits.


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Does valgrind work with Boehm garbage collector?

[John Reiser]

==23299== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==23299== Command: ./main.l.exe
==23299==
==23299== Conditional jump or move depends on uninitialised value(s)
==23299==    at 0x4E4D166: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2)
==23299==    by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2)
==23299==    by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2)
==23299==    by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2)
==23299==    by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2)
==23299==    by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2)
==23299==    by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2)
==23299==    by 0x403203: main (main.l:34)


After
   $ sudo dnf debuginfo-install /usr/lib64/libgc.so.1.3.2
then the messages look like:

==23530== Command: ./main.l.exe
==23530==
==23530== Conditional jump or move depends on uninitialised value(s)
==23530==at 0x4E4D166: GC_push_all_eager (mark.c:1583)
==23530==by 0x4E49D21: GC_with_callee_saves_pushed (mach_dep.c:322)
==23530==by 0x4E4E786: GC_push_regs_and_stack (mark_rts.c:772)
==23530==by 0x4E4E786: GC_push_roots (mark_rts.c:845)
==23530==by 0x4E4D896: GC_mark_some (mark.c:415)
==23530==by 0x4E42C44: GC_stopped_mark (alloc.c:702)
==23530==by 0x4E43348: GC_try_to_collect_inner (alloc.c:488)
==23530==by 0x4E5043B: GC_init (misc.c:1292)
==23530==by 0x403203: main (main.l:34)



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Does valgrind work with Boehm garbage collector?

[John Reiser]

On 2/17/19, Peng Yu wrote:

$ flex -o main.l.c main.l
$ clang -I. -DGC_DEBUG -Wall -pedantic -g -c -o main.l.o main.l.c #
rapidstring.h is in .
$ clang main.l.o -lgc -lfl -o main.l.exe
$ dsymutil main.l.exe


What is 'dsymutil', where did you get it, what version?
What is the hardware architecture?

The execution recipe works for me on Fedora 28 using 
valgrind-3.14.0-7.fc28.x86_64.
I omitted dsymutil.  Why is it essential for you?

$ ldd main.l.exe
linux-vdso.so.1 (0x7fffa7d9f000)
libgc.so.1 => /lib64/libgc.so.1 (0x7f255ef81000)
libc.so.6 => /lib64/libc.so.6 (0x7f255ebc2000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f255e9a3000)
libdl.so.2 => /lib64/libdl.so.2 (0x7f255e79f000)
libatomic_ops.so.1 => /lib64/libatomic_ops.so.1 (0x7f255e59c000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f255e384000)
/lib64/ld-linux-x86-64.so.2 (0x7f255f2de000)

$ rpm -qf /lib64/libgc.so.1
gc-7.6.4-3.fc28.x86_64
$ rpm -qf /usr/bin/flex
flex-2.6.1-7.fc28.x86_64
$ rpm -q clang
clang-6.0.1-2.fc28.x86_64

$ valgrind ./main.l.exe https://lists.sourceforge.net/lists/listinfo/valgrind-users