Bug 503501

Created attachment 180752 [details]
Source, objects, binary, and Makefile for a testing executable, tarred and gzipped.

Attempting to run the attached executable asmsys with Valgrind, using massif and including stacks causes an assertation fail.
This is likely because the program pops argc off the stack before going on to call more functions.
Attached is the source files, objects, binary, and Makefile for a reproducible executable triggering this issue. Nasm and a linker is required, and this program will only run on an x86_64 processor.

Valgrind invocation:
$ valgrind --tool=massif --stacks=yes -v ./asmsys
==318976== Massif, a heap profiler
==318976== Copyright (C) 2003-2024, and GNU GPL'd, by Nicholas Nethercote et al.
==318976== Using Valgrind-3.25.0-0b55712730-20250425 and LibVEX; rerun with -h for copyright info
==318976== Command: ./asmsys
==318976== 
--318976-- Valgrind options:
--318976--    --tool=massif
--318976--    --stacks=yes
--318976--    -v
--318976-- Contents of /proc/version:
--318976--   Linux version 6.13.7 (gcc (GCC) 14.2.0, GNU ld (GNU Binutils) 2.43.1.20241016) #1 SMP PREEMPT Mon Mar 17 15:20:27 CDT 2025
--318976-- 
--318976-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-ssse3-avx-avx2-bmi-f16c-rdrand-rdseed-fma
--318976-- Page sizes: currently 4096, max supported 4096
--318976-- Valgrind library directory: /usr/local/libexec/valgrind
--318976-- Massif: alloc-fns:
--318976-- Massif:   malloc
--318976-- Massif:   __builtin_new
--318976-- Massif:   operator new(unsigned long)
--318976-- Massif:   __builtin_vec_new
--318976-- Massif:   operator new[](unsigned long)
--318976-- Massif:   calloc
--318976-- Massif:   aligned_alloc
--318976-- Massif:   realloc
--318976-- Massif:   memalign
--318976-- Massif:   posix_memalign
--318976-- Massif:   valloc
--318976-- Massif:   operator new(unsigned long, std::nothrow_t const&)
--318976-- Massif:   operator new[](unsigned long, std::nothrow_t const&)
--318976-- Massif:   operator new(unsigned long, std::align_val_t)
--318976-- Massif:   operator new[](unsigned long, std::align_val_t)
--318976-- Massif:   operator new(unsigned long, std::align_val_t, std::nothrow_t const&)
--318976-- Massif:   operator new[](unsigned long, std::align_val_t, std::nothrow_t const&)
--318976-- Massif: ignore-fns:
--318976-- Massif:   <empty>
--318976-- Reading syms from /test/asmsys
--318976--    object doesn't have a dynamic symbol table
--318976-- Reading syms from /usr/local/libexec/valgrind/massif-amd64-linux
--318976--    object doesn't have a dynamic symbol table
--318976-- Scheduler: using generic scheduler lock implementation.
==318976== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-318976-by-marisa-on-???
==318976== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-318976-by-marisa-on-???
==318976== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-318976-by-marisa-on-???
==318976== 
==318976== TO CONTROL THIS PROCESS USING vgdb (which you probably
==318976== don't want to do, unless you know exactly what you're doing,
==318976== or are doing some strange experiment):
==318976==   /usr/local/libexec/valgrind/../../bin/vgdb --pid=318976 ...command...
==318976== 
==318976== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==318976==   /path/to/gdb ./asmsys
==318976== and then give GDB the following command
==318976==   target remote | /usr/local/libexec/valgrind/../../bin/vgdb --pid=318976
==318976== --pid is optional if only one valgrind process is running
==318976== 

Massif: ms_main.c:1638 (update_stack_stats): Assertion 'stacks_szB >= -stack_szB_delta' failed.

host stacktrace:
==318976==    at 0x5800A2BA: show_sched_status_wrk (m_libcassert.c:426)
==318976==    by 0x5800A3D7: report_and_quit (m_libcassert.c:497)
==318976==    by 0x5800A567: vgPlain_assert_fail (m_libcassert.c:563)
==318976==    by 0x580024F8: update_stack_stats (ms_main.c:1638)
==318976==    by 0x580024F8: update_stack_stats (ms_main.c:1636)
==318976==    by 0x580033E8: die_mem_stack_2 (ms_main.c:1667)
==318976==    by 0x580033E8: die_mem_stack (ms_main.c:1680)
==318976==    by 0x580033E8: die_mem_stack (ms_main.c:1678)
==318976==    by 0x10029C1CD0: ???
==318976==    by 0x10029BEF1F: ???

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 318976)
==318976==    at 0x4010BE: ??? (in /test/asmsys)
client stack range: [0x1FFEFFE000 0x1FFF000FFF] client SP: 0x1FFEFFFCF0
valgrind stack range: [0x10028BF000 0x10029BEFFF] top usage: 10424 of 1048576


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.

Valgrind version:
Built from source, using release 3.25.0.
Client program isn't linked with libc, however the version Valgrind uses is libc6-dgb 2.36-9+deb12u10 from http://deb.debian.org/debian bookworm/main amd64 Packages

System info:
Linux 6.13.7 #1 SMP PREEMPT Mon Mar 17 15:20:27 CDT 2025 x86_64 GNU/Linux