objc: SendSuper recursively reenters inherited overrides

[hajimehoshi]

PureGo Version

Reproduced with v0.11.0. Source inspection of main at 656af01 shows the same runtime-class-based dispatch in both ID.SendSuper and SendSuper[T]; main was not executed.

Operating System

• Windows
• macOS
• Linux
• FreeBSD
• NetBSD
• Android
• iOS

macOS 26.5.1 (25F80), arm64.

Go Version (go version)

go version go1.27.0 darwin/arm64

What steps will reproduce the problem?

Register three classes: Base : NSObject, Override : Base, and Child : Override. Define a method on Base and override it on Override, calling self.SendSuper(cmd) from that override. Child inherits the override without adding any methods.

Calling the method on an Override instance works. Calling it on a Child instance recursively reenters Override's method.

Save the following as main.go in a module requiring github.com/ebitengine/purego v0.11.0, then run go run . on macOS. It uses Foundation only and opens no window. The recursion is capped at five calls to avoid a stack overflow. The third case checks explicit defining-class dispatch through objc_msgSendSuper2.

package main

import (
	"fmt"
	"structs"

	"github.com/ebitengine/purego"
	"github.com/ebitengine/purego/objc"
)

type objcSuper struct {
	_        structs.HostLayout
	receiver objc.ID
	class    objc.Class
}

func main() {
	lib, err := purego.Dlopen("/System/Library/Frameworks/Foundation.framework/Foundation", purego.RTLD_NOW|purego.RTLD_GLOBAL)
	if err != nil {
		panic(err)
	}
	var superSend func(*objcSuper, objc.SEL) objc.ID
	purego.RegisterLibFunc(&superSend, lib, "objc_msgSendSuper2")
	sel := objc.RegisterName("probe")
	var baseCalls, overrideCalls int
	var fixed bool
	base, err := objc.RegisterClass("Issue3740Base", objc.GetClass("NSObject"), nil, nil, []objc.MethodDef{
		{
			Cmd: sel,
			Fn:  func(self objc.ID, cmd objc.SEL) { baseCalls++ },
		},
	})
	if err != nil {
		panic(err)
	}
	var override objc.Class
	override, err = objc.RegisterClass("Issue3740Override", base, nil, nil, []objc.MethodDef{
		{
			Cmd: sel,
			Fn: func(self objc.ID, cmd objc.SEL) {
				overrideCalls++
				if overrideCalls >= 5 {
					return
				}
				if fixed {
					superSend(&objcSuper{
						receiver: self,
						class:    override,
					}, cmd)
				} else {
					self.SendSuper(cmd)
				}
			},
		},
	})
	if err != nil {
		panic(err)
	}
	child, err := objc.RegisterClass("Issue3740DynamicSubclass", override, nil, nil, nil)
	if err != nil {
		panic(err)
	}
	for _, tc := range []struct {
		name         string
		class        objc.Class
		fixed        bool
		wantBase     int
		wantOverride int
	}{
		{
			name:         "direct instance, existing SendSuper",
			class:        override,
			wantBase:     1,
			wantOverride: 1,
		},
		{
			name:         "subclass instance, existing SendSuper (guarded at 5)",
			class:        child,
			wantOverride: 5,
		},
		{
			name:         "subclass instance, lexical-class super dispatch",
			class:        child,
			fixed:        true,
			wantBase:     1,
			wantOverride: 1,
		},
	} {
		baseCalls, overrideCalls, fixed = 0, 0, tc.fixed
		obj := objc.ID(tc.class).Send(objc.RegisterName("new"))
		obj.Send(sel)
		obj.Send(objc.RegisterName("release"))
		fmt.Printf("%s: base=%d override=%d\n", tc.name, baseCalls, overrideCalls)
		if baseCalls != tc.wantBase || overrideCalls != tc.wantOverride {
			panic("unexpected dispatch counts")
		}
	}
}

What is the expected result?

A super call made from Override's method should reach Base's implementation once, including when the receiver is a Child instance. There should be an API that allows the caller to specify Override as the class defining the method, matching Objective-C super semantics.

What happens instead?

Observed output:

direct instance, existing SendSuper: base=1 override=1
subclass instance, existing SendSuper (guarded at 5): base=0 override=5
subclass instance, lexical-class super dispatch: base=1 override=1

For a Child instance, ID.SendSuper supplies id.Class() == Child to objc_msgSendSuper2. That function starts lookup in Child's superclass, Override, and finds the same override again. Without the guard, the method keeps recursively reentering itself.

Anything else you feel useful to add?

This differs from #509: passing the current class to objc_msgSendSuper2 is correct, and the direct-instance control above succeeds. The problem is using the receiver's runtime class instead of the class defining the executing method. Substituting id.Class().SuperClass() would break ordinary direct-instance calls by advancing an extra level.

An explicit defining-class parameter or a separate class-anchored super-send API would allow correct dispatch for inherited methods and dynamically subclassed receivers. Both the method and generic helpers currently use id.Class(); the executable reproduction above exercises the method helper and the raw explicit-class fix.

Discovered while investigating hajimehoshi/ebiten#3740. The connection to that application's crash remains unconfirmed: neither the reporter's dynamic receiver class nor a reproduction of the resizing trigger has been established locally. The class hierarchy above independently reproduces the purego API limitation.

Filed by Codex (OpenAI), on behalf of @hajimehoshi.

[hajimehoshi]

The problem is, the current ID.SendSuper does NOT represent Objective-C's [super ...]. The PR #534 adds SendSuper1 for objc_msgSendSuper, and SendSuper2 for objc_msgSendSuper2.

If there are a cass chain Base <- Child1 <- Child2, and if [super ...] is invoked at Child1 where the instance self is Child2, these will be equivatent:

• self.SendSuper1(child1.SuperClass(), sel, args...)
• self.SendSuper2(child1, sel, args...)

[TotallyGamerJet]

The problem is, the current ID.SendSuper does NOT represent Objective-C's [super ...].

I read through this but confused why it doesn't work? In #509 we established that msgSendSuper2 calls the the super class. Which if I understand correctly is the child1 but then I'm lost why it doesn't continue up? Is it because self in child2 points to child1 instance? I think explaining what the OBJC super keyword does would be helpful in determining the best API

[hajimehoshi]

The problem happens when classes definitions are like these

@interface Base : NSObject
- (struct Result)result;
@end

@implementation Base
- (void)foo {
   NSLog(@"Base");
}
@end

@interface Child1 : Base
@end

@implementation Child1
- (void)foo {
  NSLog(@"Child1");
  [super foo];
}
@end

@interface Child2 : Child1
@end

@implementation Child2
@end

(The above code is in Objective-C, but assume the same logic is implemented in Go with PureGo)

When an instance is Child2, and foo is invoked, the current SendSuper doesn't work as expected as SendSuper's definition is id.SendSuper2(id.Class(), sel, args...) and this indicates to invoke Child1's foo (not Base's foo), since id is Child2. Then, this can cause infinite recursive.

[hajimehoshi]

I think explaining what the OBJC super keyword does would be helpful in determining the best API

Defining a helper function to represent super is fine, but I prefer APIs representing the underlying C functions directly first.

[TotallyGamerJet]

I understood that. What does [super foo]; in the ObjC code do differently?

Defining a helper function to represent super is fine, but I prefer APIs representing the underlying C functions directly first.

I'm trying to avoid adding new api if we can especially if we want to back port this so if the current ID.Super can be modified to fix the issue that's ideal

[hajimehoshi]

What does [super foo]; in the ObjC code do differently?

[super foo]; is equivarent to objc_msgSendSuper2(x, sel, args...) where x depends on where it is invoked: If the context is in Child2, x will be Child2, and if the context is in Child1, x will be Child1. The current ID.SendSuper is not context aware.

I'm trying to avoid adding new api if we can especially if we want to back port this so if the current ID.Super can be modified to fix the issue that's ideal

Unfortunately, as I explained, the current ID.SendSuper is not context aware so this would requre an argument representing which class is used at the invocation. So IIUC it is impossible to fix this correctly without changing the signature.

[hajimehoshi]

I think there is a workaround on Ebitengine side: binding objc_msgSendSuper by itself. So, the fix to add APIs doesn't have to be backported, though the bug would remain in the stable branch. I lean toward to not backporting as long as the fix is big like the PR, but what do you think?