When running the runtime tests or the following code, libnewt crashes when trying to create a display. public static void main(String[] args) { Display display = NewtFactory.createDisplay("Five Display"); } Test logs and crash logs attached. System information: MacBookPro11,3 Intel Core i7 2.3 Ghz Intel Iris Pro 0x0d26 0x0008 NVIDIA GeForce GT 750M LED Cinema Display (non Thunderbolt) - with laptop closed. ProductName: Mac OS X ProductVersion: 10.9.4 BuildVersion: 13E28 java version "1.7.0_67" Java(TM) SE Runtime Environment (build 1.7.0_67-b01) Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
Created attachment 634 [details] test.log
Created attachment 635 [details] test_dbg.log.gz
Created attachment 636 [details] JRE Crash Log
Created attachment 637 [details] OS X Crash Log
Comment on attachment 635 [details] test_dbg.log.gz this file is double gzipped :)
So we reach the native method Java_jogamp_newt_driver_macosx_WindowDriver_initIDs0 and crash right there .. even though it doesn't do very much. Some JNI FindClass and getMEthod .. will throw an Exception if this fails. JOGL seems to be valid, 2.2.0 build. Q: Have you launched your tests from our build ? Q: Do you have some 'anti virus' stuff running ? You seem to use the native jar file, loaded automatically .. No issue here .. it seems: +++ JarUtil: EXTRACT[5]: [newt -> ] libnewt.jnilib -> /var/folders/p6/62twq4cd43379xz_328wbkfh0000gn/T/jogamp_0000/file_cache/jln5587047091668471466/jln1056818139617755950/libnewt.jnilib: 89076 bytes, addedAsNativeLib: true NativeLibrary.findLibrary(<newt>) (TempJarCache): /var/folders/p6/62twq4cd43379xz_328wbkfh0000gn/T/jogamp_0000/file_cache/jln5587047091668471466/jln1056818139617755950/libnewt.jnilib JNILibLoaderBase: loadLibraryInternal(newt), TempJarCache: /var/folders/p6/62twq4cd43379xz_328wbkfh0000gn/T/jogamp_0000/file_cache/jln5587047091668471466/jln1056818139617755950/libnewt.jnilib JNILibLoaderBase: System.load(/var/folders/p6/62twq4cd43379xz_328wbkfh0000gn/T/jogamp_0000/file_cache/jln5587047091668471466/jln1056818139617755950/libnewt.jnilib) - mode 2 +++ Dunno .. Can you also try running an applet via Safari or Firefox ? (no logs necessary .. just checking your launch setup)
(In reply to comment #6) > So we reach the native method > Java_jogamp_newt_driver_macosx_WindowDriver_initIDs0 > > and crash right there .. even though it doesn't do very much. > > Some JNI FindClass and getMEthod .. will throw an Exception if this fails. http://jogamp.org/git/?p=jogl.git;a=blob;f=src/newt/native/MacWindow.m;h=2bd11da3c5e4d1e5b1610f7dc2d6a8428dbb285f;hb=HEAD#l708
> Q: Have you launched your tests from our build ? Yes, this is from 2.2.0 download (currently from https://jogamp.org/deployment/jogamp-current/archive) > > Q: Do you have some 'anti virus' stuff running ? Nope.
jogamp03:~ jogamp$ xcrun --show-sdk-path /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk jogamp03:~ jogamp$ xcrun --show-sdk-version 10.9 jogamp03:~ jogamp$ xcrun --show-sdk-platform-path /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform jogamp03:~ jogamp$ xcrun --show-sdk-platform-version 1.1 Build node is 10.9.4 as well, Intel CPU 2.4 GHZ Core 2 Duo, Mac-Mini, employs an NV card. I also tested on a newer Macbook (Intel/NV GPU) .. no issues.
Created attachment 638 [details] ef7ecf76e28 Debug OS X Crash Log
Xcode 5.1.1 Build version 5B1008 Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.3.0 Thread model: posix
Created attachment 639 [details] NEWT patch .. 01
TISGetInputSourceProperty(keyboard, kTISPropertyUnicodeKeyLayoutData) returns NULL with keyboard layouts that have sublayout categories.
(In reply to comment #13) > TISGetInputSourceProperty(keyboard, kTISPropertyUnicodeKeyLayoutData) > returns NULL > with keyboard layouts that have sublayout categories. Yes, you can simulate it by going to System Preferences -> Keyboard -> Input Sources and adding Kotoeri - that will give you a system ui menu item in top right
c0c722b9f479412f27973ba0c4cd4a166dcb00be Handle NULL result of TISGetInputSourceProperty(keyboard, kTISPropertyUnicodeKeyLayoutData), avoiding crash
Closing this bug now for release 2.2.1 We may open a dependent new bug to deal with such keyboard layouts, since this configuration will remove NEWTs functionality of mapping key-codes to US-ASCII normalized ones (layout independent).
btw .. thank you 'magaio' for finding this bug, identifying it and allow us to swiftly fix at least the crash!