massif one.post.exp3 required?

[paulfloyd]

This file isn't in Makefile.am EXTRA_DIST which causes a post-regtest-checks warning.

The test does a single malloc of 1 byte. That results in an allocation using the VG_MIN_MALLOC_SZB granularity of 8 bytes for 32bit systems and 16 bytes for 64bit systems. The two expecteds exp and exp2 cover those two cases.

I don't think that this file is needed and that it can be deleted.

[LouisBrunner]

On arm64 that is the size of the malloc I get. I assumed that is just what malloc internals do on arm64 and that a new file was required.
If you think this is a separate problem then I am happy to delete it and have the test fail again, otherwise I can add it to EXTRA_DIST.

[paulfloyd]

If you remove exp3 does the test still pass?

[LouisBrunner]

No, which is why I created the file. It never passed in the past, I just looked at that specific test in details when I made the latest upstream merge.

[paulfloyd]

Hmm. I get

paulf@pauls-mac-mini valgrind-macos % rm massif/tests/one.post.exp3
paulf@pauls-mac-mini valgrind-macos % ./tests/vg_regtest massif/tests/one
[snip]

== 1 test, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==

[LouisBrunner]

Not for me:

$ ./tests/vg_regtest massif/tests/one                                                                                                                                                                        
one:             valgrind   [snip]
*** one failed (post) ***

== 1 test, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 1 post failure ==
massif/tests/one                         (post)

$ cat massif/tests/one.post.diff*                                                                                                                                                     
--- one.post.exp	2026-05-05 22:12:19
+++ one.post.out	2026-05-11 17:45:43
@@ -6,7 +6,7 @@


      B
-    8^                                                                       :
+   32^                                                                       :
      |                                                                       :
      |                                                                       :
      |                                                                       :
@@ -27,7 +27,7 @@
      |                                                                       :
      |                                                                       :
    0 +----------------------------------------------------------------------->B
-     0                                                                       8
+     0                                                                      32

 Number of snapshots: 2
  Detailed snapshots: []
@@ -36,4 +36,4 @@
   n        time(B)         total(B)   useful-heap(B) extra-heap(B)    stacks(B)
 --------------------------------------------------------------------------------
   0              0                0                0             0            0
-  1              8                8                1             7            0
+  1             32               32                1            31            0
--- one.post.exp2	2026-05-05 22:12:19
+++ one.post.out	2026-05-11 17:45:43
@@ -6,7 +6,7 @@


      B
-   16^                                                                       :
+   32^                                                                       :
      |                                                                       :
      |                                                                       :
      |                                                                       :
@@ -27,7 +27,7 @@
      |                                                                       :
      |                                                                       :
    0 +----------------------------------------------------------------------->B
-     0                                                                      16
+     0                                                                      32

 Number of snapshots: 2
  Detailed snapshots: []
@@ -36,4 +36,4 @@
   n        time(B)         total(B)   useful-heap(B) extra-heap(B)    stacks(B)
 --------------------------------------------------------------------------------
   0              0                0                0             0            0
-  1             16               16                1            15            0
+  1             32               32                1            31            0

[paulfloyd]

Scratching my head.

If I make this change

diff --git a/massif/tests/one.c b/massif/tests/one.c
index 5d6ce6213..3e8366a5f 100644
--- a/massif/tests/one.c
+++ b/massif/tests/one.c
@@ -1,10 +1,11 @@
 #include <stdlib.h>
+#include <stdio.h>
 
 // A test for a single allocation.  There are two .post.exp* files, for each
 // of VG_MIN_MALLOC_SZB==8 and VG_MIN_MALLOC_SZB==16.
 
 int main(void)
 {
-   malloc(1);
+   printf("%p\n", malloc(1));
    return 0;
 }

then run

./vg-in-place --trace-malloc=yes massif/tests/one

In the output I see

--4716-- malloc(1) = 0x300801EE0
--4716-- malloc_type_malloc(4096, 0xd4b1b204 (0, 0x0, 0, 0x0)) = 0x300801F30
0x300801ee0

It should be

# define VG_MIN_MALLOC_SZB       16

that determines the minimum size for malloc.

Do you get the same? I'm wondering if somehow clang is using a typed malloc on your system but just plain malloc on mine.

[LouisBrunner]

I get the same, yes:

--28664-- malloc(1) = 0x3008018E0
--28664-- malloc_type_malloc(4096, 0xd4b1b204 (0, 0x0, 0, 0x0)) = 0x300801FE0
0x3008018e0

Do you get the same? I'm wondering if somehow clang is using a typed malloc on your system but just plain malloc on mine.

I guess it could be possible....

[paulfloyd]

That just looks like malloc().

There should be a redir that uses the ALLOC_or_NULL macro. That uses info.tl_malloc which should be set up to be ms_malloc during the massif startup. That calls alloc_and_record_block like this

return alloc_and_record_block( tid, szB, VG_(clo_alignment), /is_zeroed/False );

where VG_(clo_alignment) should be 16, that calls

p = VG_(cli_malloc)( req_alignB, req_szB );

void* VG_(cli_malloc) ( SizeT align, SizeT nbytes )
{
   // 'align' should be valid (ie. big enough and a power of two) by now.
   // VG_(arena_memalign)() will abort if it's not.
   if (VG_MIN_MALLOC_SZB == align)
      return VG_(arena_malloc)   ( VG_AR_CLIENT, "replacemalloc.cm.1",
                                   nbytes );
   else
      return VG_(arena_memalign) ( VG_AR_CLIENT, "replacemalloc.cm.2",
                                   align, nbytes );
}

In the above (VG_MIN_MALLOC_SZB == align should be true.

After that things get a lot more complicated in VG_(arena_malloc) and VG_(arena_malloc_usable_size)

[paulfloyd]

I tried on an M1 and there also it allocates 16 bytes.