MrStahlfelge / gdx-controllerutils

Controller Utilities for libGDX
Apache License 2.0
59 stars 13 forks source link

App crashes on disconnect on MacOS, fixed with latest Jamepad #17

Closed kennycason closed 4 years ago

kennycason commented 4 years ago

Hi, thanks for all your work! I have recently started porting to your library (Jamepad impl) from lwjgl3 and things seem to be working with the exception that the app crashes if I remove the controller.

I get this error in my console:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fff3a727c18, pid=35485, tid=775
#
# JRE version: Java(TM) SE Runtime Environment (11.0.1+13) (build 11.0.1+13-LTS)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0.1+13-LTS, mixed mode, tiered, compressed oops, g1 gc, bsd-amd64)
# Problematic frame:
# C  [IOKit+0x39c18]  IOHIDDeviceGetValue+0xc
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /Users/kenny/workspace/ninjaturdle/hs_err_pid35485.log
Compiled method (nm)    9582 1408     n 0       com.studiohartman.jamepad.ControllerManager::nativeControllerConnectedOrDisconnected (native)
 total in heap  [0x000000012171ef10,0x000000012171f2b8] = 936
 relocation     [0x000000012171f088,0x000000012171f0b8] = 48
 main code      [0x000000012171f0c0,0x000000012171f2b0] = 496
 oops           [0x000000012171f2b0,0x000000012171f2b8] = 8
Compiled method (c1)    9582 1406       3       de.golfgl.gdx.controllers.jamepad.support.JamepadControllerMonitor::run (25 bytes)
 total in heap  [0x000000011a426b90,0x000000011a427498] = 2312
 relocation     [0x000000011a426d08,0x000000011a426d90] = 136
 main code      [0x000000011a426da0,0x000000011a4271c0] = 1056
 stub code      [0x000000011a4271c0,0x000000011a427298] = 216
 oops           [0x000000011a427298,0x000000011a4272a0] = 8
 metadata       [0x000000011a4272a0,0x000000011a4272d8] = 56
 scopes data    [0x000000011a4272d8,0x000000011a427350] = 120
 scopes pcs     [0x000000011a427350,0x000000011a427430] = 224
 dependencies   [0x000000011a427430,0x000000011a427440] = 16
 handler table  [0x000000011a427440,0x000000011a427470] = 48
 nul chk table  [0x000000011a427470,0x000000011a427498] = 40
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

I haven't done much further debugging but was curious if this was something you recognized.

LibGDX 1.9.9

kennycason commented 4 years ago

updated with a bit more info from stack:

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

Current thread (0x00007f9ca4810800):  JavaThread "main" [_thread_in_native, id=775, stack(0x00007ffee2311000,0x00007ffee2b11000)]

Stack: [0x00007ffee2311000,0x00007ffee2b11000],  sp=0x00007ffee2b0c8b0,  free space=8174k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [IOKit+0x39c18]  IOHIDDeviceGetValue+0xc
C  [libjamepad64.dylib+0x11bcb]  SDL_SYS_JoystickUpdate+0x7b
C  [libjamepad64.dylib+0x11133]  SDL_JoystickUpdate+0x33
C  [libjamepad64.dylib+0x6025c]  Java_com_studiohartman_jamepad_ControllerManager_nativeControllerConnectedOrDisconnected+0xc
J 1408  com.studiohartman.jamepad.ControllerManager.nativeControllerConnectedOrDisconnected()Z (0 bytes) @ 0x000000012171f179 [0x000000012171f0c0+0x00000000000000b9]
J 1407 c1 com.studiohartman.jamepad.ControllerManager.update()V (40 bytes) @ 0x000000011a42783c [0x000000011a427740+0x00000000000000fc]
J 1406 c1 de.golfgl.gdx.controllers.jamepad.support.JamepadControllerMonitor.run()V (25 bytes) @ 0x000000011a426e34 [0x000000011a426da0+0x0000000000000094]
j  com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.loop()V+236
j  com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.<init>(Lcom/badlogic/gdx/ApplicationListener;Lcom/badlogic/gdx/backends/lwjgl3/Lwjgl3ApplicationConfiguration;)V+257
j  com.kennycason.ninjaturdle.desktop.DesktopLauncher.main([Ljava/lang/String;)V+75
v  ~StubRoutines::call_stub
V  [libjvm.dylib+0x3a7512]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x21a
V  [libjvm.dylib+0x3eb0d7]  jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)+0x11c
V  [libjvm.dylib+0x3ee8b8]  jni_CallStaticVoidMethod+0x1d1
C  [java+0x47f9]  JavaMain+0xab4
C  [java+0x6d51]  __JVMInit_block_invoke+0x4b
C  [Foundation+0x4279d]  __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__+0x7
C  [Foundation+0x42695]  -[NSBlockOperation main]+0x62
C  [Foundation+0x42620]  __NSOPERATION_IS_INVOKING_MAIN__+0x11
C  [Foundation+0x41814]  -[NSOperation start]+0x2db
C  [Foundation+0x9c88b]  __NSThreadPerformPerform+0xfe
C  [CoreFoundation+0x84b21]  __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__+0x11
C  [CoreFoundation+0x84ac0]  __CFRunLoopDoSource0+0x67
C  [CoreFoundation+0x848d4]  __CFRunLoopDoSources0+0xd1
C  [CoreFoundation+0x83740]  __CFRunLoopRun+0x4f8
C  [CoreFoundation+0x82bd3]  CFRunLoopRunSpecific+0x1f3
C  [java+0x63a5]  CreateExecutionEnvironment+0x190
C  [java+0x2523]  JLI_Launch+0x51f
C  [java+0x14dd]  main+0x16d
C  [libdyld.dylib+0x1a7fd]  start+0x1

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 1408  com.studiohartman.jamepad.ControllerManager.nativeControllerConnectedOrDisconnected()Z (0 bytes) @ 0x000000012171f108 [0x000000012171f0c0+0x0000000000000048]
J 1407 c1 com.studiohartman.jamepad.ControllerManager.update()V (40 bytes) @ 0x000000011a42783c [0x000000011a427740+0x00000000000000fc]
J 1406 c1 de.golfgl.gdx.controllers.jamepad.support.JamepadControllerMonitor.run()V (25 bytes) @ 0x000000011a426e34 [0x000000011a426da0+0x0000000000000094]
j  com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.loop()V+236
j  com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.<init>(Lcom/badlogic/gdx/ApplicationListener;Lcom/badlogic/gdx/backends/lwjgl3/Lwjgl3ApplicationConfiguration;)V+257
j  com.kennycason.ninjaturdle.desktop.DesktopLauncher.main([Ljava/lang/String;)V+75
v  ~StubRoutines::call_stub

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000015
MrStahlfelge commented 4 years ago

Hi, which OS are you using? MacOS? And which Jamepad version did you pull in, or if you did not use any own version, which version of this lib do you use?

kennycason commented 4 years ago

@MrStahlfelge Hi, thanks for the response. I'm using MacOS (Catalina 10.15.2).

Dependency-wise:

<dependency>
    <groupId>de.golfgl.gdxcontrollerutils</groupId>
    <artifactId>gdx-controllers-jamepad</artifactId>
    <version>0.4.0</version>
</dependency>
<dependency>
    <groupId>de.golfgl.gdxcontrollerutils</groupId>
    <artifactId>gdx-controllers-advanced</artifactId>
    <version>0.4.0</version>
</dependency>

That pulled in com.github.WilliamAHartman:Jamepad:1.2

Additional, note, I implemented sdl2gdx and have the exact same issue.

MrStahlfelge commented 4 years ago

Yes, the problem is caused by Jamepad itself which is used by sdl2gdx, too.

The good news: I can safely say the problem only happens on MacOS, Windows works well. Linux does not crash, too, but has some other glitches (hotplugging does not work).

The bad news: I can't fix a problem in the native C code and compile the Jamepad natives. If you are able to do so and fork a fixed version, I would be happy to use it.

kennycason commented 4 years ago

@MrStahlfelge Thanks for looking into it. That is a relief to know given the majority of gamers aren't Mac. This one final bug has been stressing me out since my game release is coming up in 2 weeks. :) I'll post the error to sdl2gdx

kennycason commented 4 years ago

I was able to resolve it by updating jamepad:

            <dependency>
                <groupId>de.golfgl.gdxcontrollerutils</groupId>
                <artifactId>gdx-controllers-jamepad</artifactId>
                <version>0.4.0</version>
                <exclusions>
                    <exclusion>
                        <groupId>com.github.WilliamAHartman</groupId>
                        <artifactId>Jamepad</artifactId>
                    </exclusion>
                </exclusions>
            </dependency>
            <dependency>
                <groupId>com.github.WilliamAHartman</groupId>
                <artifactId>Jamepad</artifactId>
                <version>1.3.2</version>
            </dependency>

this also solved my packr issue I was having that we discussed in Discord. (It was failing to load db file in ControllerManager:L291)

MrStahlfelge commented 4 years ago

That's great news. I'll check if I can pull in that version by default.

MrStahlfelge commented 4 years ago

It is possible to use the latest version, however this libs needs some changes so a downgrade is not possible atfer this change. So I would like to test with Windows and Linux before I make this switch. If you, or someone else tested 1.3.2 on these operating systems, it would be great if you could state here if it workd without problems (and with hotplugging).

kennycason commented 4 years ago

@MrStahlfelge My Windows beta tester verified that all the controller mappings works as well as hotplugging (plugging in and unplugging). I haven't tried on Linux yet. In process of setting up a Linux box.

MrStahlfelge commented 4 years ago

I updated the lib to 1.3.2; it works well on Windows and not worse than 1.2 on Linux (unfortunately, hotplugging is still not working on Linux)

kennycason commented 4 years ago

Everything has remained working solid for me as well during all my personal testing as well as beta testing. User experience has been improved. :)

electronstudio commented 4 years ago

Yes, the problem is caused by Jamepad itself which is used by sdl2gdx, too.

sdl2gdx does not use Jamepad, they are both wrappers around SDL but they are separate projects. The only code they have in common is the build script. sdl2gdx is my re-write to fix some of the issues I had with Jamepad so I would encourage its use over Jamepad where possible.

I was going to try updating to the latest snapshot of SDL but it seems this is still an unresolved issue in SDL: https://bugzilla.libsdl.org/show_bug.cgi?id=4961 So there's probably nothing that an SDL-wrapper like sdl2gdx or jamepad can do about it.

Personally I think game developers can't be expected to continually keep up with Apple's latest breakage of the month. If I do a Mac release of my games now it will be unofficial and I won't vouch to support them. I'll still do what I can to make sdl2gdx work on Mac though.

(unfortunately, hotplugging is still not working on Linux)

This is fixed in SDL 2.0.11 but that is still unreleased. I could do a snapshot release possibly.

MrStahlfelge commented 4 years ago

Thanks for giving some insights here.

I agree that issues on MacOS are not important. However, I don't understand the issues on Linux. I know and use some SDL based games and have zero issues with them and hotplugging.

electronstudio commented 4 years ago

Could be I made a mistake when I compiled SDL 2.0.9 on Linux and didn't include hotplugging somehow. Could be it works on some Linux distros and not others. Could be the problem is specific to 2.0.9 and those games are using 2.0.8 or 2.0.10.

All I can say for sure is I have tested a pre-release of 2.0.11 and it works.