x/exp/shiny: SIGILL: illegal instruction on macOS Catalina with Xcode 11.1 running basic example #35177
Comments
|
The above full output is using the If I use the
|
|
I don’t think I’m able to reproduce this on my MacBook Pro, unfortunately. What is the exact version/build of macOS you’re testing with? What hardware is it? What video card or video cards? |
dmitshur
added
NeedsInvestigation
|
Model: Video Card: OS: The give away might be the feature set |
|
The 2017 MacBook should work fine. The macOS GPUFamily2 v1 feature set is the highest feature set that currently exists, see here for reference. For comparison, my 2015 MacBook Pro has these feature sets: @leighmcculloch Can you please share Xcode and clang versions? You can use @leighmcculloch Also, do you know or remember if this worked before you installed macOS Catalina on your MB? |
|
Unfortunately I only started experimenting with these things after upgrading to Catalina. |
|
I just got my hand on another mac that is seeing the same issue. These are its specs. It's different hardware, different OS version, but same year and same featureset. Running with opengl the same as above: Full OutputRunning with
|
|
I updated the MacBook 2017 to macOS |
|
Thanks a lot for providing all that information Leigh. I updated my Xcode from 10.3: To Xcode 11.1: And I can reproduce the For the record, I'm also on the latest macOS Catalina 10.15 (19A602). I still can't reproduce the issue with Metal, that seems to still work okay. I suspect it may be a separate issue somehow related to the difference in hardware and drivers. |
dmitshur
changed the title
|
Is it worth me opening an issue for the Metal issue given that the MacBook line has been discontinued? I can open a separate issue for it, but I don't want to if it's unlikely to get looked at. The bigger issue is the OpenGL driver not working with latest Xcode I think. |
It would be helpful.
We can put it in Backlog milestone so it's clear that it'll be fixed whenever someone gets around to it. |
|
I tried to create a smaller reproducer for this, but haven't been able to successfully do that yet. So far, the following program isn't enough to reproduce the issue. main.go// +build darwin,amd64,!ios
// Try to create a smaller reproducer for golang.org/issue/35177.
package main
/*
#cgo CFLAGS: -x objective-c -DGL_SILENCE_DEPRECATION
#cgo LDFLAGS: -framework Foundation -framework Metal
#include <OpenGL/gl3.h>
#include <stdlib.h>
void run();
void makeCurrentContext(uintptr_t ctx);
*/
import "C"
import (
"runtime"
"time"
)
func init() {
runtime.LockOSThread()
}
func main() {
C.run()
time.Sleep(time.Second)
}
//export preparedOpenGL
func preparedOpenGL(ctx uintptr) {
w := &windowImpl{
ctx: ctx,
}
go drawLoop(w)
}
type windowImpl struct {
// ctx is a C data structure for the GL context.
// - Cocoa: uintptr holding a NSOpenGLContext*.
// - X11: uintptr holding an EGLSurface.
// - Windows: ctxWin32
ctx interface{}
}
func drawLoop(w *windowImpl) {
runtime.LockOSThread()
C.makeCurrentContext(C.uintptr_t(w.ctx.(uintptr)))
}main.m// +build darwin,amd64,!ios
#include "_cgo_export.h"
#include <pthread.h>
#include <stdio.h>
#import <Cocoa/Cocoa.h>
#import <Foundation/Foundation.h>
#import <OpenGL/gl3.h>
//#import <Foundation/NSObjCRuntime.h>
//#import <Metal/Metal.h>
void run() {
NSOpenGLContext *ctx = NULL;
preparedOpenGL((GoUintptr)ctx);
}
void makeCurrentContext(uintptr_t context) {
NSOpenGLContext* ctx = (NSOpenGLContext*)context;
NSLog(@"%@", ctx);
}@ianlancetaylor I suspect it may be a problem in |
|
For a problem like this the first step is definitely to reproduce the problem. @leighmcculloch If you can reproduce the problem, see if you can reproduce it under the debugger, and show us the instruction that is executing when the |
|
To clarify, both @leighmcculloch and I can reproduce the I'll try that, thanks Ian. |
|
Yes, for something like this the size of the reproduction case is unlikely to matter, as long as we can reproduce it reliably. |
|
I'm able to get this: Is it helpful? |
|
Yes, helpful. Or at least, illuminating. But confusing nontheless. The instruction at the PC is not invalid. That's a perfectly fine instruction and should never SIGILL. But it is right after a syscall. Maybe that syscall is raising the SIGILL for some reason. (If the SIGILL was raised by the syscall, would it appear at the next instruction or on the syscall instruction itself? I'm not sure how that works.) |
|
I think this is what one would expect to see if the |
|
The I don't entirely trust delve to get this kind of detail right. Can you double-check with gdb or lldb? Thanks. |
|
Possibly related, a SIGILL on Catalina for Filemaker 18: https://community.filemaker.com/en/s/question/0D50H000072r8OmSAI/filemaker-18-advanced-crashes-in-os-catalina-beta-19a526h-when-leaving-layout-mode |
|
Thank you for the guidance. I've tried Instructions before the offending one: Full disassemblyNotably, it points to ud2 as the instruction that caused EXC_BAD_INSTRUCTION, which makes a lot more sense. I don't know if delve's output was wrong or just incomplete. If the "must be called from the main thread if the context has a view" text is relevant, that gives something for me to investigate in shiny's I wonder what led to ud2 instruction being the one to crash the program instead of something else that provides more information to the end user, and if that can be improved. (Is that to do with Apple or Go?) |
|
Thank for the extra information. That does make more sense. The I agree that this does look like a missing |
|
Why does _os_crash return? That sounds like the kind of function that shouldn't. |
|
That is how it is implemented. The program actually uses the #define os_crash(msg) \
({ \
_os_crash(msg); \
os_hardware_trap(); \
})
#define os_hardware_trap() __asm__ __volatile__ (""); __builtin_trap() |
It does indeed seem to be relevant. Changing this line from |
|
Thanks for the hint @gordonklaus, it was very helpful. The change you suggested sounded very promising. I tried it, and while it causes prevents the crash from happening, it also causes the program to deadlock. The application window never appears. Using However, I realize now that I'm not observing any adverse effects with I plan to fix this problem by reverting CL 154461 for now. If it needs to be re-added, it should be done in a thread-safe way. /cc @eaburns Are you able to reproduce the problem you observed that CL 154461 was aiming to resolve? Do you know if it is reproducible on macOS Catalina? |
|
Change https://golang.org/cl/212245 mentions this issue: |
dmitshur
added
NeedsFix
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
I ran the
x/exp/shiny/example/basicexample application.What did you expect to see?
The basic graphical application to display.
What did you see instead?
An invalid instruction panic.
Full Output
I originally experienced this issue attempting to run
gdlvand opened an issue at aarzilli/gdlv#45 but was redirected here by @dmitshur.The text was updated successfully, but these errors were encountered: