|
From: Tobias B. <tb...@we...> - 2023-04-22 06:29:10
|
Hi, a big “THANK YOU!” to all Valgrind developers. Unfortunately, these days I have to deal primarily with nonsensical Java code instead of nonsensical C++ code, so I rarely get to use my favorite tool memcheck anymore. XD From NEWS: > […] It is for example possible to do: > (gdb) memcheck who_point_at &some_struct sizeof(some_struct) > instead of: > (gdb) p &some_struct > $2 = (some_struct_type *) 0x1130a0 <some_struct> > (gdb) p sizeof(some_struct) > $3 = 40 > (gdb) monitor who_point_at 0x1130a0 40 That sounds awesome, thanks! Minor nitpicking: Building c8832cb2d on Ubuntu (MATE) 20.04.6 LTS with gcc 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1) produces these 3 warnings: vgdb.c: In function ‘do_multi_mode’: vgdb.c:1332:11: warning: ignoring return value of ‘asprintf’, declared with attribute warn_unused_result [-Wunused-result] 1332 | asprintf (&reply, | ^~~~~~~~~~~~~~~~~ […] 1347 | "QSetWorkingDir+", (UInt)PBUFSIZ - 1); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ vgdb.c: In function ‘fork_and_exec_valgrind’: vgdb.c:1228:13: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result] 1228 | write (pipefd[1], &err, sizeof (int)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ vgdb.c:1283:7: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result] 1283 | write (pipefd[1], &err, sizeof (int)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 8 bits of contribution in NEWS: - from different terminals. So for example to start you program + from different terminals. So for example to start your program Tobias On 22.04.23 03:47, Mark Wielaard wrote: > An RC2 tarball for 3.21.0 is now available at > https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC2.tar.bz2 > (md5sum = f33407fdffbfa78f5014781cc92297cf) > (sha1sum = c520ee0c28d9e20d28aa25d05ce2525c39a69135) > https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC2.tar.bz2.asc > > Please give it a try in configurations that are important for you and > report any problems you have, either on this mailing list, or > (preferably) via our bug tracker at > https://bugs.kde.org/enter_bug.cgi?product=valgrind > > Please check the NEWS entry below for new features that could use some > extra testing. Note that there has also been a dhat extension which > hasn't yet been added to NEWS. > > There is now a a client request for DHAT to mark memory to be > histogrammed: > https://bugs.kde.org/464103 > https://snapshots.sourceware.org/valgrind/trunk/latest/html/dh-manual.html#dh-access-counts > > If nothing critical emerges, a final release will happen on > Friday 28 April. > > * ==================== CORE CHANGES =================== > > * When GDB is used to debug a program running under valgrind using > the valgrind gdbserver, GDB will automatically load some > python code provided in valgrind defining GDB front end commands > corresponding to the valgrind monitor commands. > These GDB front end commands accept the same format as > the monitor commands directly sent to the Valgrind gdbserver. > These GDB front end commands provide a better integration > in the GDB command line interface, so as to use for example > GDB auto-completion, command specific help, searching for > a command or command help matching a regexp, ... > For relevant monitor commands, GDB will evaluate arguments > to make the use of monitor commands easier. > For example, instead of having to print the address of a variable > to pass it to a subsequent monitor command, the GDB front end > command will evaluate the address argument. It is for example > possible to do: > (gdb) memcheck who_point_at &some_struct sizeof(some_struct) > instead of: > (gdb) p &some_struct > $2 = (some_struct_type *) 0x1130a0 <some_struct> > (gdb) p sizeof(some_struct) > $3 = 40 > (gdb) monitor who_point_at 0x1130a0 40 > > * The vgdb utility now supports extended-remote protocol when > invoked with --multi. In this mode the GDB run command is > supported. Which means you don't need to run gdb and valgrind > from different terminals. So for example to start you program > in gdb and run it under valgrind you can do: > $ gdb prog > (gdb) set remote exec-file prog > (gdb) set sysroot / > (gdb) target extended-remote | vgdb --multi > (gdb) start > > * The behaviour of realloc with a size of zero can now > be changed for tools that intercept malloc. Those > tools are memcheck, helgrind, drd, massif and dhat. > Realloc implementations generally do one of two things > - free the memory like free() and return NULL > (GNU libc and ptmalloc). > - either free the memory and then allocate a > minumum siized block or just return the > original pointer. Return NULL if the > allocation of the minimum sized block fails > (jemalloc, musl, snmalloc, Solaris, macOS). > When Valgrind is configured and built it will > try to match the OS and libc behaviour. However > if you are using a non-default library to replace > malloc and family (e.g., musl on a glibc Linux or > tcmalloc on FreeBSD) then you can use a command line > option to change the behaviour of Valgrind: > --realloc-zero-bytes-frees=yes|no [yes on Linux glibc, no otherwise] > > * ================== PLATFORM CHANGES ================= > > * Make the address space limit on FreeBSD amd64 128Gbytes > (the same as Linux and Solaris, it was 32Gbytes) > > * ==================== TOOL CHANGES =================== > > * Memcheck: > - When doing a delta leak_search, it is now possible to only > output the new loss records compared to the previous leak search. > This is available in the memcheck monitor command 'leak_search' > by specifying the "new" keyword or in your program by using > the client request VALGRIND_DO_NEW_LEAK_CHECK. > Whenever a "delta" leak search is done (i.e. when specifying > "new" or "increased" or "changed" in the monitor command), > the new loss records have a "new" marker. > - Valgrind now contains python code that defines GDB memcheck > front end monitor commands. See CORE CHANGES. > - Performs checks for the use of realloc with a size of zero. > This is non-portable and a source of errors. If memcheck > detects such a usage it will generate an error > realloc() with size 0 > followed by the usual callstacks. > A switch has been added to allow this to be turned off: > --show-realloc-size-zero=yes|no [yes] > > * Helgrind: > - The option ---history-backtrace-size=<number> allows to configure > the number of entries to record in the stack traces of "old" > accesses. Previously, this number was hardcoded to 8. > - Valgrind now contains python code that defines GDB helgrind > front end monitor commands. See CORE CHANGES. > > * Cachegrind: > - `--cache-sim=no` is now the default. The cache simulation is old and > unlikely to match any real modern machine. This means only the `Ir` > event are gathered by default, but that is by far the most useful > event. > - `cg_annotate`, `cg_diff`, and `cg_merge` have been rewritten in > Python. As a result, they all have more flexible command line > argument handling, e.g. supporting `--show-percs` and > `--no-show-percs` forms as well as the existing `--show-percs=yes` > and `--show-percs=no`. > - `cg_annotate` has some functional changes. > - It's much faster, e.g. 3-4x on common cases. > - It now supports diffing (with `--diff`, `--mod-filename`, and > `--mod-funcname`) and merging (by passing multiple data files). > - It now provides more information at the file and function level. > There are now "File:function" and "Function:file" sections. These > are very useful for programs that use inlining a lot. > - Support for user-annotated files and the `-I`/`--include` option > has been removed, because it was of little use and blocked other > improvements. > - The `--auto` option is renamed `--annotate`, though the old > `--auto=yes`/`--auto=no` forms are still supported. > - `cg_diff` and `cg_merge` are now deprecated, because `cg_annotate` > now does a better job of diffing and merging. > - The Cachegrind output file format has changed very slightly, but in > ways nobody is likely to notice. > > * Callgrind: > - Valgrind now contains python code that defines GDB callgrind > front end monitor commands. See CORE CHANGES. > > * Massif: > - Valgrind now contains python code that defines GDB massif > front end monitor commands. See CORE CHANGES. > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |