Lwjgl3: SIGSEGV upon running the example provided on official website on macOS Catalina.

Created on 4 Mar 2020 · 5Comments · Source: LWJGL/lwjgl3

Environment

LWJGL version: 3.2.3
LWJGL build #: 13
Java version: 11.0.5+10
Platform: macOS Catalina 10.15.3
Module: core|glfw|opengl

Description

After attempting to run the example provided on the official website here, I merely received a segmentation fault or something of that matter. Well, whatever it might be, it prevents the example from running at all. While the critical line seems to be found in the C code of LWJGL 3, the last subroutine to be invoked within Java is glfwCreateWindow(int, int, CharSequence, long, long). And yes, I ensured that a forward compatible core context with the version 3.2 is used when running the program. Below you may find the dump written by the JVM.

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fff322694a0, pid=3292, tid=775
#
# JRE version: OpenJDK Runtime Environment (11.0.5+10) (build 11.0.5+10-b520.38)
# Java VM: OpenJDK 64-Bit Server VM (11.0.5+10-b520.38, mixed mode, tiered, compressed oops, g1 gc, bsd-amd64)
# Problematic frame:
# C  [HIToolbox+0x274a0]  THIThemeTextInfoFinder::GetOptions() const+0x8
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

---------------  S U M M A R Y ------------

Command Line: -javaagent:/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.jar=51325:/Applications/IntelliJ IDEA.app/Contents/bin -Dfile.encoding=UTF-8 com.vortex.Client

Host: MacBookPro14,1 x86_64 2500 MHz, 4 cores, 8G, Darwin 19.3.0
Time: Wed Mar  4 11:12:44 2020 CET elapsed time: 0 seconds (0d 0h 0m 0s)

---------------  T H R E A D  ---------------

Current thread is native thread

Stack: [0x00007ffee006d000,0x00007ffee086d000],  sp=0x00007ffee0869900,  free space=8178k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [HIToolbox+0x274a0]  THIThemeTextInfoFinder::GetOptions() const+0x8
C  [HIToolbox+0x273ca]  TCoreTextEngine::VerifyLayout(THIThemeTextInfo*, float, float, LayoutIntent)+0x34
C  [HIToolbox+0x272d7]  TCoreTextEngine::GetThemeTextDimensions(double, THIThemeTextInfo*, double*, double*, double*)+0x2b
C  [HIToolbox+0x25dd7]  DataEngine::GetTextDimensions(void const*, double, HIThemeTextInfo*, double*, double*, double*)+0x10f
C  [HIToolbox+0x25c8e]  HIThemeGetTextDimensions+0xbc
C  [HIToolbox+0x255ed]  HIMenuBarView::MeasureMenuTitle(MenuData*, unsigned char, float*, int)+0x1af
C  [HIToolbox+0x2536e]  HIMenuBarView::MeasureAppMenus()+0xe6
C  [HIToolbox+0x24ef7]  HIMenuBarView::EnsureBarLayout()+0x1a3
C  [HIToolbox+0x24817]  HIMenuBarView::DrawOnce(CGRect, CGRect, bool, bool, CGContext*)+0x23b
C  [HIToolbox+0x244f6]  HIMenuBarView::DrawSelf(short, __HIShape const*, CGContext*)+0x23a
C  [HIToolbox+0x23f3e]  HIMenuBarView::DrawWithoutCustomization(short, __HIShape const*, CGContext*)+0x52
C  [HIToolbox+0x23ed6]  HIMenuBarView::DrawingDelegateHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*)+0x102
C  [HIToolbox+0x8711]  DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*)+0x58b
C  [HIToolbox+0x7ae0]  SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*)+0x152
C  [HIToolbox+0x7983]  SendEventToEventTargetWithOptions+0x2d
C  [HIToolbox+0x23a4b]  HIView::SendDraw(short, OpaqueGrafPtr*, __HIShape const*, CGContext*)+0x145
C  [HIToolbox+0x234be]  HIView::RecursiveDrawComposited(__HIShape const*, __HIShape const*, unsigned int, HIView*, CGContext*, unsigned char, double)+0x246
C  [HIToolbox+0x23709]  HIView::RecursiveDrawComposited(__HIShape const*, __HIShape const*, unsigned int, HIView*, CGContext*, unsigned char, double)+0x491
C  [HIToolbox+0x22ef9]  HIView::DrawComposited(short, OpaqueGrafPtr*, __HIShape const*, unsigned int, HIView*, CGContext*)+0x32f
C  [HIToolbox+0x22bbb]  HIView::Render(unsigned int, CGContext*)+0x33
C  [HIToolbox+0x3aa1b]  FlushWindowObject(WindowData*, void**, unsigned char)+0x2ed
C  [HIToolbox+0x3a466]  FlushAllBuffers(__CFRunLoopObserver*, unsigned long, void*)+0x132
C  [CoreFoundation+0x840ee]  __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__+0x17
C  [CoreFoundation+0x84014]  __CFRunLoopDoObservers+0x1c9
C  [CoreFoundation+0x83832]  __CFRunLoopRun+0x5ea
C  [CoreFoundation+0x82bd3]  CFRunLoopRunSpecific+0x1f3
C  [libjli.dylib+0x6465]  CreateExecutionEnvironment+0x190
C  [libjli.dylib+0x25e3]  JLI_Launch+0x51f
C  [java+0xe37]  main+0x177
C  [libdyld.dylib+0x1a7fd]  start+0x1

Bug

Source

Theikon

Most helpful comment

You are probably missing the -XstartOnFirstThread. Remember, it is a JVM argument, _not_ a program argument.

httpdigest on 4 Mar 2020

👍2

All 5 comments

You are probably missing the -XstartOnFirstThread. Remember, it is a JVM argument, _not_ a program argument.

httpdigest on 4 Mar 2020

👍2

You‘re absolutely right! I‘ll try that once I get the chance to. However, I‘m already confident that this is the solution.

Theikon on 4 Mar 2020

You are probably missing the -XstartOnFirstThread. Remember, it is a JVM argument, _not_ a program argument.

Since this is quite a common source of issues, it might be a good idea to mention this requirement on the site. (I opened https://github.com/LWJGL/lwjgl3-www/issues/81 to track this.) However, it is worth noting that there are some checks for this in EventLoop which might be broken as of some macOS update.

TheMrMilchmann on 4 Mar 2020

👍1

And that -XstartOnFirstThread option did the trick! It works fine now. I wholeheartedly agree with @TheMrMilchmann. This should be in the documentation and an exception should be thrown instead of crashing the JVM. Closing the issue since it's essentially resolved.

Theikon on 4 Mar 2020

Looks like the main thread check has been broken since https://github.com/glfw/glfw/commit/ea7eb2ddab823e21c846c68d112d90f91fcba318, the NSApp variable is now always initialized at glfwInit. I tried to use [NSApp isRunning] as a replacement for the offscreen case, but it somehow always returns false. I'll just make it as strict as the onscreen case and users can disable the check with Configuration.GLFW_CHECK_THREAD0 if they want to experiment.