]> git.ipfire.org Git - thirdparty/valgrind.git/commitdiff
Bug 489040 massif trace change to show the location increasing the stack
authorPhilippe Waroquiers <philippe.waroquiers@skynet.be>
Sun, 30 Jun 2024 10:07:11 +0000 (12:07 +0200)
committerPhilippe Waroquiers <philippe.waroquiers@skynet.be>
Sun, 30 Jun 2024 14:06:50 +0000 (16:06 +0200)
Massif verbose output showing the code location that increases the stack.

NEWS
include/pub_tool_debuginfo.h
massif/docs/ms-manual.xml
massif/ms_main.c

diff --git a/NEWS b/NEWS
index 7100b216eed662fe87fd78dd50635d659ac902b9..9583c26e7e0bb9c49b8c4d13c4630f6c869ad39b 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -49,6 +49,7 @@ are not entered into bugzilla tend to get forgotten about or ignored.
 488026  Use of `sizeof` instead of `strlen
 488379  --track-fds=yes errors that cannot be suppressed with --xml-file=
 488441  Add tests for --track-fds=yes --xml=yes and fd suppression tests
+489040  massif trace change to show the location increasing the stack
 
 To see details of a given bug, visit
   https://bugs.kde.org/show_bug.cgi?id=XXXXXX
index 7631ff67a675ec35fd1c9cd3b3bbb213bd2977a1..bd0395695753aa8a4e20df160154d6f16df6f66c 100644 (file)
@@ -182,13 +182,13 @@ typedef  struct _InlIPCursor InlIPCursor;
    be done:
        InlIPCursor *iipc = VG_(new_IIPC)(ep, eip);
        do {
-          buf = VG_(describe_IP)(eip, iipc);
+          buf = VG_(describe_IP)(ep, eip, iipc);
           ... use buf ...
        } while (VG_(next_IIPC)(iipc));
        VG_(delete_IIPC)(iipc);
 
-   To only describe eip, without the inlined calls at eip, give a NULL iipc:
-       buf = VG_(describe_IP)(eip, NULL);   
+   To only describe eip, without the inlined calls at eip, give a NULL iipc, e.g.:
+       buf = VG_(describe_IP)(VG_(current_DiEpoch)(), eip, NULL);
 
    Note, that the returned string is allocated in a static buffer local to
    VG_(describe_IP). That buffer will be overwritten with every invocation.
index 3dff2599523a64b56b901ae8c989f369144a37bc..22941fa522b52d824bc736c508e400d747041ea2 100644 (file)
@@ -703,6 +703,13 @@ various places online.
       true, but doing otherwise accurately is difficult.  Furthermore,
       starting at zero better indicates the size of the part of the main
       stack that a user program actually has control over.</para>
+      <para>If you give at least 4 <option>-v</option> verbosity arguments,
+        then massif produces a trace for each stack increase and decrease.
+        The stack increase trace contains the IP address that increased the stack.
+        Note that to get fully precise IP address, you must specify the options
+        <option>-px-default=unwindregs-at-mem-access
+          --px-file-backed=unwindregs-at-mem-access</option>.
+      </para>
     </listitem>
   </varlistentry>
 
index f4df6eb16b3151e530b8be1fc9c4038b02b1bdc1..0aed0890d262e8cb24a335498c589314b4ff4d1a 100644 (file)
@@ -1644,7 +1644,13 @@ static void update_stack_stats(SSizeT stack_szB_delta)
 static INLINE void new_mem_stack_2(SizeT len, const HChar* what)
 {
    if (have_started_executing_code) {
-      VERB(3, "<<< new_mem_stack (%lu)\n", len);
+      if (UNLIKELY(VG_(clo_verbosity) > 3)) {
+         const ThreadId cur_tid = VG_(get_running_tid) ();
+         const Addr cur_IP = VG_(get_IP) (cur_tid);
+         VERB(3, "<<< new_mem_stack (%lu) tid %u IP %s\n",
+              len, cur_tid,
+              VG_(describe_IP)(VG_(current_DiEpoch)(), cur_IP, NULL));
+      }
       n_stack_allocs++;
       update_stack_stats(len);
       maybe_take_snapshot(Normal, what);