Valgrind reports Invalid Read of Size 4 at software_interrupt_handle_signals

[bushidocodes]

Edit: Also need to document / script how to run Valgrind with the runtime.

Number of cores 16, sandboxing cores 15 (start: 1) and module reqs 0
==8856== Thread 6:
==8856== Invalid read of size 4
==8856==    at 0x56132A6: pthread_kill (pthread_kill.c:40)
==8856==    by 0x409F66: software_interrupt_handle_signals (software_interrupt.c:72)
==8856==    by 0x561689F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.27.so)
==8856==    by 0x56131F5: pthread_sigmask (pthread_sigmask.c:45)
==8856==    by 0x40A712: software_interrupt_unmask_signal (software_interrupt.h:86)
==8856==    by 0x40A712: worker_thread_main (worker_thread.c:188)
==8856==    by 0x560B6DA: start_thread (pthread_create.c:463)
==8856==    by 0x5944A3E: clone (clone.S:95)
==8856==  Address 0x2d0 is not stack'd, malloc'd or (recently) free'd
Number of cores 16, sandboxing cores 15 (start: 1) and module reqs 0
==8856== Thread 6:
==8856== Invalid read of size 4
==8856==    at 0x56132A6: pthread_kill (pthread_kill.c:40)
==8856==    by 0x409F66: software_interrupt_handle_signals (software_interrupt.c:72)
==8856==    by 0x561689F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.27.so)
==8856==    by 0x56131F5: pthread_sigmask (pthread_sigmask.c:45)
==8856==    by 0x40A712: software_interrupt_unmask_signal (software_interrupt.h:86)
==8856==    by 0x40A712: worker_thread_main (worker_thread.c:188)
==8856==    by 0x560B6DA: start_thread (pthread_create.c:463)
==8856==    by 0x5944A3E: clone (clone.S:95)
==8856==  Address 0x2d0 is not stack'd, malloc'd or (recently) free'd

Which is basically this code:

		/* A POSIX signal is delivered to one of the threads in our process.If sent by the kernel, "broadcast"
		 * by forwarding to all all threads */
		if (signal_info->si_code == SI_KERNEL) {
			for (int i = 0; i < runtime_total_worker_processors; i++) {
				if (pthread_self() != runtime_worker_threads[i]) {
					pthread_kill(runtime_worker_threads[i], SIGALRM);
				}
			}
		} else {
			/* If not sent by the kernel, this should be a signal forwarded from another thread */
			assert(signal_info->si_code == SI_TKILL);
		}

runtime_worker_threads is being indexed properly and seems to have sane pthread IDs
I have no clue about address 0x2d0

[bushidocodes]

Investigated this. The reported Invalid read of size 4 is a Valgrind false positive, and the real bug behind the original trace was already fixed. Details below.

The signal-path report is a false positive

Reproducing today with preemption on and multiple workers yields the same call stack, but the address verdict is different:

Thread 3: Invalid read of size 4
   at pthread_kill (pthread_kill.c:40)
   by propagate_sigalrm
   by software_interrupt_handle_signals
   ... by worker_thread_main
 Address 0x97d32d0 is in a rw- anonymous segment

The original 2019 report said Address 0x2d0 is not stack'd, malloc'd or free'd — 0x2d0 is the offset of the tid field inside the glibc thread descriptor added to a near-null base, i.e. pthread_kill was handed an uninitialised (zero) pthread_t. That was a genuine bug, and it has since been fixed: runtime_worker_threads[] is calloc'd, each slot is asserted non-zero before use (assert(runtime_worker_threads[i] != 0) in propagate_sigalrm), and the interval timer is armed only after all workers are created. Today the descriptor address is 0x97d3000 + 0x2d0 — a valid mapped TCB — and the assert never fires.

The read only looks invalid because the SIGALRM is delivered while the worker is running on a switched-in sandbox stack, which Valgrind can no longer track. It's one instance of a broader pattern: Memcheck cannot model three things SLEdge does, each of which generates bogus errors —

1. signal-based preemption delivered on a switched stack,
2. user-level context switching (swapcontext / arch_context — Valgrind prints client switching stacks?),
3. direct mmap of sandbox linear memory (set address range perms: large range ... (noaccess), then the JIT'd module legitimately accesses it).

I also checked the rest, to be sure nothing real was hiding

• Uninitialised-value reports in the scheduler / run-queue / sandbox-lifecycle code: ran --track-origins=yes. Every one traces to a single origin — the hand-rolled stack/rsp manipulation in arch_context_init — with zero heap-allocation origins. All benign.
• Leaks: a differential run (20 vs 120 requests) is byte-for-byte identical (definitely lost 2,408 B / 2 blocks in both), so there is no per-request leak. The few "lost" blocks are per-thread TLS and thread_local structures that aren't freed only because the runtime is stopped by a signal and never joins its threads.

Conclusion: no memory-safety bug in the signal, scheduler, run-queue, or sandbox-lifecycle paths.

Tooling (addresses the "document/script how to run Valgrind" ask)

Rather than leave the noise undocumented, #390 adds a suppression file scoped to exactly these false-positive classes, a run-valgrind.sh wrapper (clean control-plane mode + a preemptive mode), and docs/valgrind.md explaining the why. With it, SLEdge's own runtime code is silent under Valgrind; only unanchorable libc-level sandbox-memory / host-stdio noise remains.

Closing as resolved (false positive, fix already in tree) — see #390 for the tooling.