GopeedLab/gopeed · error

panic: %v

Error message

panic: %v

What it means

Vm.RunString executes a script string inside a VM created by the __gopeed_create_vm binding, under an event loop and a deferred recover. The 'panic: %v' fallback fires when the recovered value is neither an error nor anything else handled — here the switch only has an error case, so ANY non-error panic (including goja.Value) renders as 'panic: %v'. It means native code or the runtime panicked while running the script.

Source

Thrown at pkg/download/engine/inject/vm/module.go:34

		runtime.Set(name, value)
	})
}

func (vm *Vm) Get(name string) (value any) {
	vm.loop.Run(func(runtime *goja.Runtime) {
		value = runtime.Get(name)
	})
	return
}

func (vm *Vm) RunString(script string) (value any, err error) {
	defer func() {
		if r := recover(); r != nil {
			switch v := r.(type) {
			case error:
				err = v
			default:
				err = fmt.Errorf("panic: %v", r)
			}
		}
	}()

	vm.loop.Run(func(runtime *goja.Runtime) {
		value, err = runtime.RunString(script)
	})
	return
}

func Enable(runtime *goja.Runtime) error {
	return runtime.Set("__gopeed_create_vm", func(call goja.FunctionCall) goja.Value {
		return runtime.ToValue(&Vm{
			loop: eventloop.NewEventLoop(),
		})
	})
}

View on GitHub (pinned to 7b7327ffb3)

Solutions

  1. Check the script for calls into host bindings and validate their arguments before invoking
  2. Prefer checking err from RunString and logging both value and err to isolate whether the script itself is malformed
  3. Recreate the VM instead of reusing one whose loop may have been stopped
Defensive patterns

Strategy: try-catch

Try / catch

value, err := vm.RunString(script)
if err != nil {
    if strings.Contains(err.Error(), "panic:") {
        // native/runtime panic inside the VM: do not reuse this VM instance
        return fmt.Errorf("vm script panicked: %w", err)
    }
    return fmt.Errorf("vm script failed: %w", err)
}

Prevention

When it happens

Trigger: RunString on a script that invokes a host binding which panics with a string; running a script after the VM's event loop was stopped; goja internal panics on pathological input (e.g. stack overflow from infinite recursion appears as a runtime error, but custom panics land here).

Common situations: Extensions embedding sandboxed helper scripts via the vm module; scripts assuming globals that were never installed in the VM; reusing a Vm across loop shutdowns.

Related errors


AI-assisted analysis of GopeedLab/gopeed@7b7327ffb3 (2026-08-16). Data as JSON: /api/errors/c5c2840e9dfef68d. Report an issue: GitHub.