go-delve/delve · error

panic executing starlark script: %v

Error message

panic executing starlark script: %v

What it means

This is a catch-all panic recovery wrapper around starlark script execution in delve's starbind package. When a user script (or a bug in the binding layer) panics during script evaluation, the deferred recover converts the panic into an error and prints it with a full goroutine stack trace to the debugger console. It also increments the internal bug counter because a panic inside starlark bindings usually indicates a defect rather than a normal scripting mistake.

Source

Thrown at pkg/terminal/starbind/starlark.go:230

}

func (env *Env) printFunc() func(_ *starlark.Thread, msg string) {
	return func(_ *starlark.Thread, msg string) { fmt.Fprintln(env.out, msg) }
}

// Execute executes a script. Path is the name of the file to execute and
// source is the source code to execute.
// Source can be either a []byte, a string or a io.Reader. If source is nil
// Execute will execute the file specified by 'path'.
// After the file is executed if a function named mainFnName exists it will be called, passing args to it.
func (env *Env) Execute(path string, source any, mainFnName string, args []any) (_ starlark.Value, _err error) {
	defer func() {
		err := recover()
		if err == nil {
			return
		}
		logflags.Bug.Inc()
		_err = fmt.Errorf("panic executing starlark script: %v", err)
		fmt.Fprintf(env.out, "panic executing starlark script: %v\n", err)
		for i := 0; ; i++ {
			pc, file, line, ok := runtime.Caller(i)
			if !ok {
				break
			}
			fname := "<unknown>"
			fn := runtime.FuncForPC(pc)
			if fn != nil {
				fname = fn.Name()
			}
			fmt.Fprintf(env.out, "%s\n\tin %s:%d\n", fname, file, line)
		}
	}()

	thread := env.newThread()
	globals, err := execFileOptions(nil, thread, path, source, env.env)
	if err != nil {

View on GitHub (pinned to a23773e6c3)

Solutions

1. Read the printed stack trace to find the Go frame that panicked (usually a starbind builtin or starlark runtime frame).
2. Fix the starlark script if it passes invalid arguments to a builtin.
3. If the panic is inside delve's bindings, reproduce with the script and file a bug with the script and stack trace.
4. Update delve; known starlark binding panics are fixed between versions.

Example fix

// before (script causing panic)
bp = debug.GetBreakpoint()
print(bp.Args)  # nil deref in a binding
// after
bp = debug.GetBreakpoint()
if bp != None:
    print(bp)

// starlark: validate values before calling risky builtins
if bp == None:
    fail('breakpoint not found')
print(bp.Id)

// In Go host code wrapping Execute (delve already recovers):
err := env.Execute(script, args)
if err != nil && strings.HasPrefix(err.Error(), "panic executing starlark script") {
    log.Printf("script panicked: %v", err) // stack already printed to env.out
}

When it happens

Trigger: Any panic during starlark script execution via delve's scripting support, e.g. nil pointer dereference in a bound Go function, index-out-of-range inside a builtin the script calls, or calling a bound API with values that violate invariants.

Common situations: Users running complex .star scripts against the debugger (service call scripts, automation) hit this when a builtin panics; it also appears after delve version upgrades where a script relies on a binding whose signature changed.

Related errors

• %s is not a function
• wrong number of arguments for %s
• value not loaded
• not hashable
• cycle in load graph

AI-assisted analysis of go-delve/delve@a23773e6c3 (2026-08-31). Data as JSON: /api/errors/f42a3256173cd491. Report an issue: GitHub.