sucle:start crashes on high sierra
Closed this issue · 12 comments
Hi, this project looks like a lot of fun - thanks for putting it out there! Unfortunately it hasn't worked for me yet.
I'm running with glfw-3.2.1 installed via homebrew on OSX high sierra, SBCL 1.4.12 installed via roswell.
(ql:quickload :sucle) ;; works
(sucle:start) ;; hangs and emits the following in inferior-lisp buffer:
2018-12-02 18:25:29.384 sbcl[3798:3804716] *** Assertion failure in +[NSUndoManager _endTopLevelGroupings], /BuildRoot/Library/Caches/com.apple.xbs/Sources/Foundation/Foundation-1454.90/Foundation/Misc.subproj/NSUndoManager.m:361
2018-12-02 18:25:29.385 sbcl[3798:3804716] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: '+[NSUndoManager(NSInternal) _endTopLevelGroupings] is only safe to invoke on the main thread.'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff4cd9a2db __exceptionPreprocess + 171
1 libobjc.A.dylib 0x00007fff73f4fc76 objc_exception_throw + 48
2 CoreFoundation 0x00007fff4cda0072 +[NSException raise:format:arguments:] + 98
3 Foundation 0x00007fff4eec9340 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 193
4 Foundation 0x00007fff4ee57f44 +[NSUndoManager(NSPrivate) _endTopLevelGroupings] + 469
5 AppKit 0x00007fff4a2a496e -[NSApplication run] + 997
6 libglfw.3.dylib 0x00000000001ef03f initializeAppKit + 1393
7 libglfw.3.dylib 0x00000000001ee706 _glfwPlatformCreateWindow + 34
8 libglfw.3.dylib 0x00000000001ea592 glfwCreateWindow + 443
9 ??? 0x00000000228606e8 0x0 + 579208936
10 ??? 0x00000000228680b8 0x0 + 579240120
11 ??? 0x0000000022875040 0x0 + 579293248
12 ??? 0x00000000228aabbf 0x0 + 579513279
13 ??? 0x0000000021c7a1f6 0x0 + 566731254
14 ??? 0x0000000021b36753 0x0 + 565405523
)
libc++abi.dylib: terminating with uncaught exception of type NSException
fatal error encountered in SBCL pid 3798(tid 0xb000e000):
SIGABRT received.
Error opening /dev/tty: Device not configured
Welcome to LDB, a low-level debugger for the Lisp runtime environment.
ldb>
I updated the source code and installed it again.
Now I can start the game on mac OS High Sierra.
The problem is that the window's size is fixed and the displayed area is 1/4 of the original view.
I pulled the latest changes from master but they don't affect this error on my machine. I have the git checkout linked from quicklisp's local-projects directory, so I just restart lisp and (ql:quickload :sucle). Did you do something else when you installed it again?
@spacebat 's comment
TLDR: This commit should fix the error
Explanation:
(sucle:start) ;; hangs emits the following in inferior-lisp buffer:
It sounds like you are using emacs from the inferior-lisp buffer, possibly with SLIME. SLIME has a dedicated REPL thread, and on macOS only the main thread can call OpenGL and window stuff, which means (sucle:start) should work on the command line but not in SLIME. The commit above changes the thread from the REPL thread to the main thread.
@t-cool I can't reproduce this on macOS Yosemite, and don't have access to macOS high sierra
@terminal625 indeed that commit eliminates the error. Now the window appears - I think its the appropriate size, but it is black. The top command shows sbcl is busy on the CPU, but there is nothing but blackness in the window. The macbook pro that I'm using does not have Nvidia graphics, it has an Intel Iris Pro. I was not expecting a high frame rate but thought that it might work.
@spacebat did you click on the window and press "e" to capture the cursor? Then it should start rendering, on my mac it just looks like flickering before pressing "e". That is, unless your OpenGL driver does not support display lists. But even then, it should be a sky blue screen [because of gl:clear], not a black one
Side note: maybe there should be a splash screen just to let the user know if it is installed correctly
@terminal625 when I click on the window and press "e", it renders a single frame about a quarter of the size of the window, a second later the window disappears and the cursor switches to the spinning ball of death. The process remains and when switched to, the cursor is frozen, but no window is visible. Perhaps this program does not work with Iris Pro graphics.
it renders a single frame about a quarter of the size of the window
Can you see blocks and/or the color blue? Does it look like tcool's error?
I can't reproduce this myself but if at least a single correct frame is rendered that means the libraries are correctly installed. Is there a backtrace, or any error information?
Also, it would be great if you could try running it from the Terminal.app, that would rule out any emacs-specific problems and narrow it down to OpenGL or GLFW
tcool's comment
@t-cool Is the framerate okay, and does it not crash like in @spacebat 's case?
@terminal625 yes the frame looks like @t-cool's error. At the moment the window disappears, this appears in inferior-lisp buffer:
CORRUPTION WARNING in SBCL pid 5745(tid 0x7fffad66d380):
Memory fault at 0x20ccf1532 (pc=0xc82803f, sp=0x4fe070)
The integrity of this image is possibly compromised.
Continuing with fingers crossed.
CORRUPTION WARNING in SBCL pid 5745(tid 0x7fffad66d380):
Memory fault at 0x30 (pc=0x7fff657976f7, sp=0x4fd500)
The integrity of this image is possibly compromised.
Continuing with fingers crossed.
objc[5745]: NSOpenGLContext object 0x1928db0 overreleased while already deallocating; break on objc_overrelease_during_dealloc_error to debug
My system information says I have the framework OpenGL 16.7.4.0.0 however I don't know how to determine what GLSL version comes with that.
When running from the command line using SBCL I get:
CORRUPTION WARNING in SBCL pid 6282(tid 0x7fffad66d380):
Memory fault at 0x20b4f1532 (pc=0xb02803f, sp=0x11ff100)
The integrity of this image is possibly compromised.
Continuing with fingers crossed.
debugger invoked on a SB-SYS:MEMORY-FAULT-ERROR in thread
#<THREAD "main thread" RUNNING {1001958083}>:
Unhandled memory fault at #x20B4F1532.
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [STOP ] Stop the task.
1: [CONTINUE] Ignore runtime option --eval "(sucle:start)".
2: [ABORT ] Skip rest of --eval and --load options.
3: Skip to toplevel READ/EVAL/PRINT loop.
4: [EXIT ] Exit SBCL (calling #'EXIT, killing the process).
("bogus stack frame")
0]
And using CCL I get:
#<CALL-TASK :FUNC #<COMPILED-LEXICAL-CLOSURE (:INTERNAL APPLICATION::JUST-MAIN) #x302002A6499F> :STATUS :RUNNING #x302002A63D1D>
? Unhandled exception 10 at 0x2c02803f, context->regs at #x7ffeefbfdd00
Exception occurred while executing foreign code
at _ZN16IntelVertexArray11setElemDataEjjtj + 147
received signal 10; faulting address: 0x22c4f1532
? for help
[6212] Clozure CL kernel debugger:
TLDR: There needs to be a logging system
at _ZN16IntelVertexArray11setElemDataEjjtj + 147
Looks like the error has something to do with vertex arrays? But if a frame renders then display lists are also supported... Maybe something is still in the wrong thread? If the problem is in foreign code... the only way to know would be to try and debug on the machine... but many users do not have knowledge of the codebase to debug... what if there was an option to TRACE the entire program? Then a user who does not have knowledge of the codebase could dump the TRACE information... but TRACE -ing the entire program will result in tons of output... and that would be written to a file? But if the program crashes immediately the TRACE will be short...There needs to be an option to TRACE the entire program to a file, so users can send useful debug information. This might be useful as a library in its own right.