golang/go · warning

no line information for PC=%#x

Error message

no line information for PC=%#x

What it means

The pprof tool could not find line-number information (source file and line number) for a given program counter (PC) address. The tool first tries symbol table line info, then DWARF debug info (`dwarfSourceLine`), and if both fail it returns this error. This means neither the symbol table nor DWARF sections contain mapping for the specific instruction address, which happens when the code was compiled without debug info, stripped, or the address is in a runtime/assembly section without line mapping.

Source

Thrown at src/cmd/pprof/pprof.go:287

	addr -= f.offset
	file, line, fn := f.pcln.PCToLine(addr)
	if fn != nil {
		frame := []driver.Frame{
			{
				Func: fn.Name,
				File: file,
				Line: line,
			},
		}
		return frame, nil
	}

	frames := f.dwarfSourceLine(addr)
	if frames != nil {
		return frames, nil
	}

	return nil, fmt.Errorf("no line information for PC=%#x", addr)
}

// dwarfSourceLine tries to get file/line information using DWARF.
// This is for C functions that appear in the profile.
// Returns nil if there is no information available.
func (f *file) dwarfSourceLine(addr uint64) []driver.Frame {
	if f.dwarf == nil && !f.triedDwarf {
		// Ignore any error--we don't care exactly why there
		// is no DWARF info.
		f.dwarf, _ = f.file.DWARF()
		f.triedDwarf = true
	}

	if f.dwarf != nil {
		r := f.dwarf.Reader()
		unit, err := r.SeekPC(addr)
		if err == nil {
			if frames := f.dwarfSourceLineEntry(r, unit, addr); frames != nil {

View on GitHub (pinned to b6b368adc5)

Solutions

1. Rebuild the target binary with debug info: remove `-ldflags='-s -w'` from the build command and use `go build` without stripping flags.
2. Ensure the binary being profiled is the same binary that generated the profile (address mismatch causes all lookups to fail).
3. If profiling on a different machine, ensure the same binary (with debug info) is available locally for pprof to read.
4. For runtime/assembly addresses, this is expected — some Go runtime functions genuinely lack line info; suppress with `-ignore` flags.
5. If DWARF is present but corrupted, rebuild from scratch: `go clean -cache && go build`.

Example fix

# Before: stripped binary, no debug info
go build -ldflags='-s -w' -o myapp
pprof myapp cpu.prof  # no line info

# After: build with full debug info
go build -o myapp
pprof myapp cpu.prof  # line info available

// Verify the binary has DWARF debug info before profiling
file, err := objfile.Open(binaryPath)
if err != nil {
    return fmt.Errorf("cannot open binary: %w", err)
}
dwarf, err := file.DWARF()
if err != nil || dwarf == nil {
    fmt.Println("Warning: binary lacks DWARF info; source lines will be unavailable")
    fmt.Println("Rebuild without -ldflags='-s -w'")
}

When it happens

Trigger: Fires in the `file.SourceLine` method at pprof.go:287 when both the primary line lookup and `f.dwarfSourceLine(addr)` return nil. The DWARF data is lazily loaded at line 280-284. This occurs during symbolization of profile samples when pprof tries to annotate a PC address with its source location.

Common situations: Profiling a binary built with `-ldflags='-s -w'` (stripped, no DWARF info). Profiling a binary compiled without optimization-inlining-safe debug info (Go's runtime assembly functions often lack line info). The PC address falls in dynamically generated code (JIT, reflect, cgo trampolines). Using a system Go installation where the .go source files or debug info are not accessible. Profiling C/C++ code via pprof where the binary was stripped.

Related errors

• multiple toplevel scopes
• no DWARF data in go object file
• no DWARF data in Plan 9 file
• dwarf: null reference in %d
• dwarf: unsupported attribute form %d / class %d

AI-assisted analysis of golang/go@b6b368adc5 (2026-08-12). Data as JSON: /api/errors/5141425e130c62b6. Report an issue: GitHub.