debug info audit - many virtual memory addresses have strange source locations

[andrewrk]

Extracted from #20958.

This problem is very noticeable with the new fuzz web interface, however, it is probably an old existing issue.

In the following screenshot it looks like returning from the function never happened, which should be impossible, given that it did get to the struct initialization expression:

In this one, one of the switch prong edges is missing a point of interest (.state = .pipe;):

For a more concrete example, here's a zig source file:

const std = @import("std");

pub fn main() !void {
    std.debug.print("All your {s} are belong to us.\n", .{"codebase"});
    const stdout_file = std.io.getStdOut().writer();
    var bw = std.io.bufferedWriter(stdout_file);
    const stdout = bw.writer();
    try stdout.print("Run `zig build test` to run the tests.\n", .{});
    try bw.flush();
}

test "simple test" {
    var list = std.ArrayList(i32).init(std.testing.allocator);
    defer list.deinit(); // try commenting this out and see if zig detects the memory leak!
    try list.append(42);
    try std.testing.expectEqual(@as(i32, 42), list.pop());
}

test "if tower" {
    const input_bytes = std.testing.fuzzInput(.{});
    if (input_bytes.len < 10) return;
    std.time.sleep(std.time.ns_per_ms / 3); // otherwise it finds the bug too fast!
    if (input_bytes[0] == 'A') {
        if (input_bytes[1] == 'l') {
            if (input_bytes[2] == 'e') {
                if (input_bytes[3] == 'x') {
                    if (input_bytes[4] == 'a') {
                        if (input_bytes[5] == 'n') {
                            if (input_bytes[6] == 'd') {
                                if (input_bytes[7] == 'r') {
                                    if (input_bytes[8] == 'a') {
                                        @panic("found bug");
                                    }
                                }
                            }
                        }
                    }
                }
            }
        }
    }
}

Let's look at the dump-cov output:

$ rm -rf .zig-cache/
$ zig build test --fuzz
(Ctrl+C after it starts fuzzing)
$ ls -tral .zig-cache/o/*/test .zig-cache/v/*
-rwxr-xr-x 1 andy users 3059072 Aug  7 18:39 .zig-cache/o/a321a73de5df7d6deea464de8e07f242/test
-rwxr-xr-x 1 andy users 5210704 Aug  7 18:39 .zig-cache/o/1fe19c11a36d6b56a75dc31b9d4fddf6/test
-rw-r--r-- 1 andy users   88457 Aug  7 18:39 .zig-cache/v/7fdeac10eb529c6d
$ zig run ~/dev/zig/tools/dump-cov.zig -- .zig-cache/o/1fe19c11a36d6b56a75dc31b9d4fddf6/test .zig-cache/v/7fdeac10eb529c6d | grep main.zig
-104489c: /home/andy/tmp/abc/src/main.zig:15:20
-1044922: /home/andy/tmp/abc/src/main.zig:16:55
-1044961: /home/andy/tmp/abc/src/main.zig:16:5
-10449a0: /home/andy/tmp/abc/src/main.zig:14:22
-11318f4: /home/andy/tmp/abc/src/main.zig:23:20
-1131935: /home/andy/tmp/abc/src/main.zig:23:20
+113196e: /home/andy/tmp/abc/src/main.zig:24:24
-11319a2: /home/andy/tmp/abc/src/main.zig:24:24
+11319dc: /home/andy/tmp/abc/src/main.zig:25:28
-1131a10: /home/andy/tmp/abc/src/main.zig:25:28
-1131a4a: /home/andy/tmp/abc/src/main.zig:26:32
-1131a7e: /home/andy/tmp/abc/src/main.zig:26:32
-1131ab8: /home/andy/tmp/abc/src/main.zig:27:36
-1131aec: /home/andy/tmp/abc/src/main.zig:27:36
-1131b26: /home/andy/tmp/abc/src/main.zig:28:40
-1131b5a: /home/andy/tmp/abc/src/main.zig:28:40
-1131b94: /home/andy/tmp/abc/src/main.zig:29:44
-1131bc8: /home/andy/tmp/abc/src/main.zig:29:44
-1131c02: /home/andy/tmp/abc/src/main.zig:30:48
-1131c36: /home/andy/tmp/abc/src/main.zig:30:48
-1131c70: /home/andy/tmp/abc/src/main.zig:31:52
-1131c80: /home/andy/tmp/abc/src/main.zig:32:41
-1131cb2: /home/andy/tmp/abc/src/main.zig:31:52
-1131cce: /home/andy/tmp/abc/src/main.zig:31:52
+1131d00: /home/andy/tmp/abc/src/main.zig:32:41

In particular, some source locations go backwards as the PC marches forwards, and they should not do that. It should not go forward a line then backward a line. If you look at the UI it shows a green dot in a location that it should not:

Above, it shows a green dot next to @panic when it definitely has not hit that line yet. Those two dots correspond to the lines above ending in 32:41, which you can see are out of order. Probably that point of interest should be the end curly brace of the function.

Related:

• Debug breakpoint is hit when it shouldn't be #19443
• unreachable code paths need to be excluded from having coverage instrumentation #20992
• -OReleaseSafe breaks fuzzing entry points feature; incorrect already-sorted assumption #20990

[andrewrk]

After the fixes from #21075, the example is better:

however as you can see it could still be improved.