runtime, cgo: programs using Cocoa/OpenGL/Metal APIs on macOS exhibit problems at tip not seen in 1.19.4 #57263

dmitshur · 2022-12-12T17:14:35Z

What version of Go are you using (`go version`)?

$ go version
go version go1.20rc1 darwin/arm64

Does this issue reproduce with the latest release?

Not with the latest stable release.

This appears to be a regression that happens only with Go 1.20 RC 1 and at tip (as of yesterday), but doesn't happen at all with Go 1.19.4 or any older stable Go release.

What operating system and processor architecture are you using (`go env`)?

go env Output

$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/Users/gopher/Library/Caches/go-build"
GOENV="/Users/gopher/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/gopher/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/gopher/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.20rc1"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/s_/5sjqzr0j6xggz_xtzmq_8r4m00jwcj/T/go-build1742320560=/tmp/go-build -gno-record-gcc-switches -fno-common"

Generally a close-to-default install of Go 1.20 RC 1 on an M1-based Mac running latest macOS (13.0.1/22A400) and Xcode (14.1/14B47b).

What did you do?

I tried running various Go programs that use Cocoa and either OpenGL or Metal APIs via cgo to open a window and render graphics. This problem affects all of them in the same way. The smallest way to reproduce I can share at this time are the simple example programs in the go-gl org:

$ cd $(mktemp -d)
$ git clone https://github.com/go-gl/example && cd example
$ go run ./gl21-cube
$ go run ./gl41core-cube

There's no problem running simple cgo programs that don't use the Cocoa/OpenGL/Metal APIs.

What did you expect to see?

Normal program execution, no warnings or errors, just like with Go 1.19.4 or older.

What did you see instead?

Almost always, there are warnings/log messages printed including:

2022-12-12 11:40:49.511 gl21-cube[64718:25499557] +[NSXPCSharedListener endpointForReply:withListenerName:replyErrorCode:]: an error occurred while attempting to obtain endpoint for listener 'ClientCallsAuxiliary': Connection invalid
2022-12-12 11:40:49.518 gl21-cube[64718:25499557] Error received in message reply handler: Connection invalid
2022-12-12 11:40:49.518 gl21-cube[64718:25499593] Connection Invalid error for service com.apple.hiservices-xpcservice.

(Those log messages may show up only after the Cocoa window is selected.)

Sometimes it also prints:

FALLBACK (log once): Fallback to SW vertex processing because buildPipelineState failed
FALLBACK (log once): Fallback to SW fragment processing because buildPipelineState failed
UNSUPPORTED (log once): UNEXPECTED/FATAL?: buildPipelineState failed to build fragment-fallback PSO, m_disable_code: 1001000
FALLBACK (log once): Fallback to SW vertex processing, m_disable_code: 1000
FALLBACK (log once): Fallback to SW fragment processing, m_disable_code: 1000000

Also observed:

2022/12/11 14:08:22 Compiler encountered XPC_ERROR_CONNECTION_INVALID (is the OS shutting down?)

(The OS was not shutting down. Restarting had no effect.)

It's not completely deterministic: sometimes the program will exit due to an error, or fail to render graphics properly if it keeps running. However, running the same program with Go 1.19.4 will work okay, and then re-running it with Go 1.20 RC 1 will also work (still with warnings, but graphics will render normally). From a quick look, it seems that modifying a shader source will cause it to start to fail again, so it's possible running it with Go 1.19.4 causes those to be built successfully, cached and reused.

This might very well be a problem with the Go program accessing those macOS APIs in an unsafe way, or a problem in macOS itself, but it only started happening at tip and doesn't happen when reverting to an older stable Go version.

CC @golang/runtime.

The text was updated successfully, but these errors were encountered:

rsc · 2022-12-13T21:17:09Z

Can you bisect to when it happened?

gtownsend · 2022-12-13T22:33:28Z

If this helps...:

I started seeing the first error from an existing binary (of a Go app) when I upgraded my Mac to "Ventura" (OS 13.0). It was nonfatal, and the app still worked, so I didn't pay a lot of attention. Rebuilding the app with Go 1.20.RC1 had no effect.

Today I upgraded to MacOS 13.1 and with both the old and new app binaries the initial error is followed by
SIGABRT: abort
PC=0x18cff66ec m=7 sigcode=0
signal arrived during cgo execution

I guess the main thing I'm suggesting is that it might possibly be a change in MacOS rather than a change in the Go code that provoked the problem.

dmitshur · 2022-12-13T22:43:26Z

@rsc Sure, I'll run a bisect and see if I can spot what Go commit introduces this, thanks. (It should be easy as long as this stays reproducible for me.)

@gtownsend Thanks. In your case, does compiling the Go program with Go 1.19.4 make any difference? For me, when I tried it last, the problem would immediately go away whenever the program was built with 1.19.4.

I'll also see if today's macOS 13.1 release brings any new differences.

gtownsend · 2022-12-13T22:54:56Z

My app now works perfectly after reinstalling Go 1.19.4 and rebuilding.

…

On Dec 13, 2022, at 3:43 PM, Dmitri Shuralyov ***@***.***> wrote: @rsc <https://github.com/rsc> Sure, I'll run a bisect and see if I can spot what Go commit introduces this, thanks. (It should be easy as long as this stays reproducible for me.) @gtownsend <https://github.com/gtownsend> Thanks. In your case, does compiling the Go program with Go 1.19.4 make any difference? For me, when I tried it last, the problem would immediately go away whenever the program was built with 1.19.4. I'll also see if today's macOS 13.1 release brings any new differences. — Reply to this email directly, view it on GitHub <#57263 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVOAQBXKK6FDHJXGYKSUN3WND3ZXANCNFSM6AAAAAAS4GDURU>. You are receiving this because you were mentioned.

dmitshur · 2022-12-14T03:27:37Z

Observing the same behavior after updating from macOS 13.0.1 to 13.1.

@rsc Bisect found that this issue reproduces as of CL 451735 ("runtime: work around Apple libc bugs to make exec stop hanging"). Reverting just that commit at tip is sufficient to restore problem-free behavior.

dmitshur · 2022-12-14T12:52:34Z

After re-reading #56784 I realized this likely has to do with fork/new process being involved during shader compilation.

In case it ends up being helpful, here's a more self-contained repro that uses the Metal API:

package main

/*
#cgo CFLAGS: -x objective-c
#cgo LDFLAGS: -framework Metal -framework CoreGraphics -framework Foundation

#import <Metal/Metal.h>

void CompileMetalShader() {
	id<MTLDevice> device = MTLCreateSystemDefaultDevice();
	if (!device) {
		printf("no Metal device\n");
		return;
	}

	NSError * err;
	id<MTLLibrary> library = [device newLibraryWithSource:@"// Empty shader 123."
	                                              options:NULL
	                                                error:&err];
	if (err) {
		printf("newLibraryWithSource error: %s\n", err.localizedDescription.UTF8String);
		return;
	}

	printf("ok\n");
}
*/
import "C"

func main() {
	C.CompileMetalShader()

	// Output (with CL 451735, with shader source that hasn't been previously compiled):
	// newLibraryWithSource error: Compiler encountered XPC_ERROR_CONNECTION_INVALID (is the OS shutting down?)

	// Output (without CL 451735):
	// ok
}

Edit: Added -framework Foundation; it's needed for linking to succeed in some, albeit not all, macOS environments.

gtownsend · 2022-12-14T15:38:21Z

I can confirm that Dmitri's test exhibits the problem on my system with 1.20.rc1 and not with Go 1.19.4. (Mac M1 mini, MacOS 13.1, latest xcode command tools updated along with 13.1 upgrade.)

…

On Dec 14, 2022, at 5:52 AM, Dmitri Shuralyov ***@***.***> wrote: After re-reading #56784 <#56784> I realized this likely has to do with fork/new process being involved during shader compilation. In case it ends up being helpful, here's a more self-contained repro that uses the Metal API: package main /* #cgo CFLAGS: -x objective-c #cgo LDFLAGS: -framework Metal -framework CoreGraphics #import <Metal/Metal.h> void CompileMetalShader() { id<MTLDevice> device = MTLCreateSystemDefaultDevice(); if (!device) { printf("no Metal device\n"); return; } NSError * err; id<MTLLibrary> library = [device newLibraryWithSource:@"// Empty shader 123." options:NULL error:&err]; if (err) { printf("newLibraryWithSource error: %s\n", err.localizedDescription.UTF8String); return; } printf("ok\n"); } */ import "C" func main() { C.CompileMetalShader() // Output (with CL 451735, with shader source that hasn't been previously compiled): // newLibraryWithSource error: Compiler encountered XPC_ERROR_CONNECTION_INVALID (is the OS shutting down?) // Output (without CL 451735): // ok } — Reply to this email directly, view it on GitHub <#57263 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVOAQA7RXZM5VFVXPOMQZTWNG7J7ANCNFSM6AAAAAAS4GDURU>. You are receiving this because you were mentioned.

dmitshur · 2022-12-14T17:02:03Z

Tentatively adding release-blocker since this might be preventing some cgo programs from running on a first class port.

ericchiang · 2022-12-21T04:47:45Z

#57419 is another issue that appears to be caused by go.dev/cl/451735

Reproducer:

package main

// #cgo darwin LDFLAGS: -framework PCSC
// #include <PCSC/winscard.h>
// #include <PCSC/wintypes.h>
import "C"
import "fmt"

func main() {
	var ctx C.SCARDCONTEXT
	rc := int64(C.SCardEstablishContext(C.SCARD_SCOPE_SYSTEM, nil, nil, &ctx))
	if rc < 0 {
		// Fix overflow.
		rc += (1 << 32)
	}
	fmt.Printf("0x%08x\n", rc)
	if rc == C.SCARD_S_SUCCESS {
		C.SCardReleaseContext(ctx)
	}
}

Without cl/451735 or using Go 1.19 and earlier, this prints 0x00000000 (SCARD_S_SUCCESS). On Go 1.20rc1 it prints 0x8010001d (SCARD_E_NO_SERVICE)

gopherbot · 2022-12-22T15:10:52Z

Change https://go.dev/cl/459175 mentions this issue: runtime: revert Apple libc atfork workaround

gopherbot · 2022-12-22T15:11:15Z

Change https://go.dev/cl/459176 mentions this issue: runtime: call __fork instead of fork on darwin

Revert CL 451735 (1f4394a), which fixed #33565 and #56784 but also introduced #57263. I have a different fix to apply instead. Since the first fix was never backported, it will be easiest to backport the new fix if the new fix is done in a separate CL from the revert. Change-Id: I6c8ea3a46e542ee4702675bbc058e29ccd2723e0 Reviewed-on: https://go-review.googlesource.com/c/go/+/459175 Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Russ Cox <rsc@golang.org>

gopherbot · 2022-12-22T18:14:10Z

Change https://go.dev/cl/459178 mentions this issue: runtime: call __fork instead of fork on darwin

gopherbot · 2022-12-22T18:16:04Z

Change https://go.dev/cl/459178 mentions this issue: [release-branch.go1.19] runtime: call __fork instead of fork on darwin

gopherbot · 2022-12-22T18:19:23Z

Change https://go.dev/cl/459179 mentions this issue: [release-branch.go1.18] runtime: call __fork instead of fork on darwin

Issues #33565 and #56784 were caused by hangs in the child process after fork, while it ran atfork handlers that ran into slow paths that didn't work in the child. CL 451735 worked around those two issues by calling a couple functions at startup to try to warm up those child paths. That mostly worked, but it broke programs using cgo with certain macOS frameworks (#57263). CL 459175 reverted CL 451735. This CL introduces a different fix: bypass the atfork child handlers entirely. For a general fork call where the child and parent are both meant to keep executing the original program, atfork handlers can be necessary to fix any state that would otherwise be tied to the parent process. But Go only uses fork as preparation for exec, and it takes care to limit what it attempts to do in the child between the fork and exec. In particular it doesn't use any of the things that the macOS atfork handlers are trying to fix up (malloc, xpc, others). So we can use the low-level fork system call (__fork) instead of the atfork-wrapped one. The full list of functions that can be called in a child after fork in exec_libc2.go is: - ptrace - setsid - setpgid - getpid - ioctl - chroot - setgroups - setgid - setuid - chdir - dup2 - fcntl - close - execve - write - exit I disassembled all of these while attached to a hung exec.test binary and confirmed that nearly all of them are making direct kernel calls, not using anything that the atfork handler needs to fix up. The exceptions are ioctl, fcntl, and exit. The ioctl and fcntl implementations do some extra work around the kernel call but don't call any other functions, so they should still be OK. (If not, we could use __ioctl and __fcntl instead, but without a good reason, we should keep using the standard entry points.) The exit implementation calls atexit handlers. That is almost certainly inappropriate in a failed fork child, so this CL changes that call to __exit on darwin. To avoid making unnecessary changes at this point in the release cycle, this CL leaves OpenBSD calling plain exit, even though that is probably a bug in the OpenBSD port (filed #57446). Fixes #33565. Fixes #56784. Fixes #57263. Fixes #56837. Change-Id: I26812c26a72bdd7fcf72ec41899ba11cf6b9c4ab Reviewed-on: https://go-review.googlesource.com/c/go/+/459176 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-on: https://go-review.googlesource.com/c/go/+/459178

Issues #33565 and #56784 were caused by hangs in the child process after fork, while it ran atfork handlers that ran into slow paths that didn't work in the child. CL 451735 worked around those two issues by calling a couple functions at startup to try to warm up those child paths. That mostly worked, but it broke programs using cgo with certain macOS frameworks (#57263). CL 459175 reverted CL 451735. This CL introduces a different fix: bypass the atfork child handlers entirely. For a general fork call where the child and parent are both meant to keep executing the original program, atfork handlers can be necessary to fix any state that would otherwise be tied to the parent process. But Go only uses fork as preparation for exec, and it takes care to limit what it attempts to do in the child between the fork and exec. In particular it doesn't use any of the things that the macOS atfork handlers are trying to fix up (malloc, xpc, others). So we can use the low-level fork system call (__fork) instead of the atfork-wrapped one. The full list of functions that can be called in a child after fork in exec_libc2.go is: - ptrace - setsid - setpgid - getpid - ioctl - chroot - setgroups - setgid - setuid - chdir - dup2 - fcntl - close - execve - write - exit I disassembled all of these while attached to a hung exec.test binary and confirmed that nearly all of them are making direct kernel calls, not using anything that the atfork handler needs to fix up. The exceptions are ioctl, fcntl, and exit. The ioctl and fcntl implementations do some extra work around the kernel call but don't call any other functions, so they should still be OK. (If not, we could use __ioctl and __fcntl instead, but without a good reason, we should keep using the standard entry points.) The exit implementation calls atexit handlers. That is almost certainly inappropriate in a failed fork child, so this CL changes that call to __exit on darwin. To avoid making unnecessary changes at this point in the release cycle, this CL leaves OpenBSD calling plain exit, even though that is probably a bug in the OpenBSD port (filed #57446). Fixes #33565. Fixes #56784. Fixes #57263. Fixes #56836. Change-Id: I26812c26a72bdd7fcf72ec41899ba11cf6b9c4ab Reviewed-on: https://go-review.googlesource.com/c/go/+/459176 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-on: https://go-review.googlesource.com/c/go/+/459179

gopherbot · 2023-01-04T14:36:44Z

Change https://go.dev/cl/460476 mentions this issue: runtime: Apple libc atfork workaround take 3

tmm1 · 2023-01-06T22:31:23Z

We're tracking some customer crashes on M1 macOS 13.1 which seems to be related to the __fork commit. However, I have not yet been able to replicate on our own hardware running the same OS. I am sending the customer a build with the __fork commit reverted to see if it resolves the issue.

PC=0x1a95867c8 m=0 sigcode=0
signal arrived during cgo execution

goroutine 1 [syscall, locked to thread]:
runtime.cgocall(0x101b0e538, 0x14000d0fc48)
	runtime/cgocall.go:158 +0x54 fp=0x14000d0fc10 sp=0x14000d0fbd0 pc=0x100ac31b4
github.com/fancybits/channels-server/menubar._Cfunc_StartApp()
	_cgo_gotypes.go:91 +0x34 fp=0x14000d0fc40 sp=0x14000d0fc10 pc=0x1016c9684
github.com/fancybits/channels-server/menubar.Start({0x14000d1cd80, 0x7, 0x8})
	github.com/fancybits/channels-server/menubar/menubar.go:34 +0xe0 fp=0x14000d0fc70 sp=0x14000d0fc40 pc=0x1016c9920
main.StartMenu()
	github.com/fancybits/channels-server/menu_darwin.go:74 +0x424 fp=0x14000d0fd10 sp=0x14000d0fc70 pc=0x101afeb74

We are using cgo to populate an icon in the macOS menu bar.

/*
#cgo CFLAGS: -x objective-c -mmacosx-version-min=10.10
#cgo LDFLAGS: -framework Cocoa -framework Security
#import 
void SetupApp();
void StartApp();
void StopApp();
void add_menu_item(int, const char *);
void add_separator_item();
*/
import "C"

void SetupApp(void) {
  [NSAutoreleasePool new];
  [NSApplication sharedApplication];
  [NSApp setActivationPolicy:NSApplicationActivationPolicyAccessory];
SessionAttributeBits attributes;

OSStatus err = SessionGetInfo(callerSecuritySession, NULL, &attributes);

if ((err == noErr) && (attributes & sessionHasGraphicAccess)) {

menuDelegate = [MenuHandler new];

appMenu = [[NSMenu new] autorelease];
NSData *data;
float scale = [[NSScreen mainScreen] backingScaleFactor];
if (scale > 1) {
  data = [NSData dataWithBytes:menubar_2x_png length:menubar_2x_png_len];
} else {
  data = [NSData dataWithBytes:menubar_png length:menubar_png_len];
}
NSImage *icon = [[NSImage alloc] initWithData:data];
if (scale > 1) {
  icon.size = NSMakeSize(icon.size.width / scale, icon.size.height / scale);
}
[icon setTemplate:YES];

statusItem = [[[NSStatusBar systemStatusBar] statusItemWithLength:NSSquareStatusItemLength] retain];
[statusItem setMenu:appMenu];
[statusItem setImage:icon];
[statusItem setHighlightMode:YES];
[statusItem setToolTip:@"Channels DVR"];

}
[NSWorkspace.sharedWorkspace.notificationCenter addObserver:menuDelegate

selector:@selector(didWake:)

name:NSWorkspaceDidWakeNotification

object:NULL];
[NSApp activateIgnoringOtherApps:NO];

}
void StartApp() {

[NSApp run];

}

rsc · 2023-01-08T18:49:45Z

Which version of Go are you using?
Reopening to make sure we resolve this one way or the other before Go 1.20.
Does your crashing program use os/exec?
And if so does it use os/exec before calling main.StartMenu?

tmm1 · 2023-01-08T21:29:59Z

We are tracking release-branch.go1.19 in a fork that we use here: https://github.com/fancybits/go/tree/fancybits-1.19

The customer confirmed that reverting the __fork change fixed his crashes.

I also got more details about his setup, which is different than what we were trying ourselves:

It’s an M1 Max mini. It’s I’m running as a dedicated non-admin user and it’s running logged out. I have it running as a service via launchd.

And if so does it use os/exec before calling main.StartMenu?

Yes, it does use os/exec before calling StartMenu

rsc · 2023-01-08T22:23:56Z

Thank you for the quick confirmation.

gopherbot · 2023-01-08T22:33:35Z

Change https://go.dev/cl/461115 mentions this issue: [release-branch.go1.19] runtime: revert "call __fork instead of fork on darwin"

gopherbot · 2023-01-08T22:34:57Z

Change https://go.dev/cl/461116 mentions this issue: [release-branch.go1.18] runtime: revert "call __fork instead of fork on darwin"

…on darwin" A recent comment on #57263 reports an unexplained crash in a cgo program that is fixed by reverting the __fork fix. We don't have any viable fix for the os/exec bug at this point, so give up on a fix for the January point releases. This reverts CL 459179 (commit 07b6ffb). Fixes #57689. Change-Id: I3b81de6bded399f47862325129e86a65c83d8e3b Reviewed-on: https://go-review.googlesource.com/c/go/+/461116 Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>

…on darwin" A recent comment on #57263 reports an unexplained crash in a cgo program that is fixed by reverting the __fork fix. We don't have any viable fix for the os/exec bug at this point, so give up on a fix for the January point releases. This reverts CL 459178 (commit 91bc4cd). Fixes #57690. Change-Id: Ieb38d9bc7f967e9a726429eab2ea515d5ca0847f Reviewed-on: https://go-review.googlesource.com/c/go/+/461115 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>

dmitshur added OS-Darwin NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Dec 12, 2022

dmitshur added this to the Go1.20 milestone Dec 12, 2022

gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Dec 12, 2022

TotallyGamerJet mentioned this issue Dec 14, 2022

internal/glfw: rare crash at setting an icon on macOS hajimehoshi/ebiten#2474

Open

10 tasks

dmitshur added the release-blocker label Dec 14, 2022

prattmic assigned rsc Dec 14, 2022

This was referenced Dec 20, 2022

os/exec: tests hang on macOS due to Apple libc fork bugs [1.19 backport] #56837

Closed

os/exec: tests hang on macOS due to Apple libc fork bugs [1.18 backport] #56836

Closed

cherrymui mentioned this issue Dec 21, 2022

runtime/cgo: cgo program fails on MacOS with Go 1.20rc1 #57419

Closed

gopherbot closed this as completed in c61d322 Dec 22, 2022

dmitshur added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Dec 22, 2022

ericchiang mentioned this issue Dec 27, 2022

Incompatibility with Go 1.20rc1 go-piv/piv-go#113

Closed

bcmills mentioned this issue Jan 4, 2023

os/exec: subprocesses on ios failing frequently with SIGTERM since CL 459176 #57577

Closed

rsc reopened this Jan 8, 2023

rsc mentioned this issue Jan 8, 2023

os/exec: revert macOS __fork fix before point release #57688

Closed

gopherbot closed this as completed in 76d39ae Jan 10, 2023

golang locked and limited conversation to collaborators Jan 10, 2024

gopherbot added the FrozenDueToAge label Jan 10, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

runtime, cgo: programs using Cocoa/OpenGL/Metal APIs on macOS exhibit problems at tip not seen in 1.19.4 #57263

runtime, cgo: programs using Cocoa/OpenGL/Metal APIs on macOS exhibit problems at tip not seen in 1.19.4 #57263

dmitshur commented Dec 12, 2022 •

edited

rsc commented Dec 13, 2022

gtownsend commented Dec 13, 2022

dmitshur commented Dec 13, 2022

gtownsend commented Dec 13, 2022 via email

dmitshur commented Dec 14, 2022

dmitshur commented Dec 14, 2022 •

edited

gtownsend commented Dec 14, 2022 via email

dmitshur commented Dec 14, 2022 •

edited

ericchiang commented Dec 21, 2022 •

edited

gopherbot commented Dec 22, 2022

gopherbot commented Dec 22, 2022

gopherbot commented Dec 22, 2022

gopherbot commented Dec 22, 2022

gopherbot commented Dec 22, 2022

gopherbot commented Jan 4, 2023

tmm1 commented Jan 6, 2023

rsc commented Jan 8, 2023

tmm1 commented Jan 8, 2023 •

edited

rsc commented Jan 8, 2023

gopherbot commented Jan 8, 2023

gopherbot commented Jan 8, 2023

runtime, cgo: programs using Cocoa/OpenGL/Metal APIs on macOS exhibit problems at tip not seen in 1.19.4 #57263

runtime, cgo: programs using Cocoa/OpenGL/Metal APIs on macOS exhibit problems at tip not seen in 1.19.4 #57263

Comments

dmitshur commented Dec 12, 2022 • edited

What version of Go are you using (go version)?

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

What did you do?

What did you expect to see?

What did you see instead?

rsc commented Dec 13, 2022

gtownsend commented Dec 13, 2022

dmitshur commented Dec 13, 2022

gtownsend commented Dec 13, 2022 via email

dmitshur commented Dec 14, 2022

dmitshur commented Dec 14, 2022 • edited

gtownsend commented Dec 14, 2022 via email

dmitshur commented Dec 14, 2022 • edited

ericchiang commented Dec 21, 2022 • edited

gopherbot commented Dec 22, 2022

gopherbot commented Dec 22, 2022

gopherbot commented Dec 22, 2022

gopherbot commented Dec 22, 2022

gopherbot commented Dec 22, 2022

gopherbot commented Jan 4, 2023

tmm1 commented Jan 6, 2023

rsc commented Jan 8, 2023

tmm1 commented Jan 8, 2023 • edited

rsc commented Jan 8, 2023

gopherbot commented Jan 8, 2023

gopherbot commented Jan 8, 2023

dmitshur commented Dec 12, 2022 •

edited

What version of Go are you using (`go version`)?

What operating system and processor architecture are you using (`go env`)?

dmitshur commented Dec 14, 2022 •

edited

dmitshur commented Dec 14, 2022 •

edited

ericchiang commented Dec 21, 2022 •

edited

tmm1 commented Jan 8, 2023 •

edited