Emulator Issues #11372
closedAndroidTV / NVidia Shield: Using DolphinBar with 2 Wii Remotes crashes on startup
0%
Description
Game Name?
New Super Mario Bros. Wii
Game ID? (right click the game in the game list, properties, info tab)
SMNP01 (00010000534d4e50)
MD5 Hash? (right click the game in the game list, properties, info tab, MD5 Hash: Compute)
a64956f231e877282d004093ebb323f3
What's the problem? Describe what went wrong.
When using 2 real Wii remotes via the DolphinBar, Super Mario crashes on startup.
What steps will reproduce the problem?
- Make sure the DolphinBar is directly connected to the NVidia Shield (no USB hub!)
- Make sure the DolphinBar is turned on
- Make sure that DolphinBar LED4 is on ('Wii Emulator Mode')
- Make sure that DolphinBar LED0 is on (which indicates that it has found the Wii controllers)
- Make sure that the two real authentic Wii Remotes are turned on
- Then start Dolphin
- Configure Wii Remote 1 and 2 as 'Real Wii Remote'
- Configure Wii Remote 3 and 4 as 'Disabled'
- Enable 'Continuous scanning'
- Start 'Super Mario'
- Now both controllers will rumble shortly to indicate that the controllers were found by Dolphin
- Dolphin returns to main menu, without starting game and without crash dialog
These steps are a 100% reproducable way to reproduce the bug.
However, the following related effects were observed while narrowing down the situations in which it does occur:
- With 'Continuous scanning' disabled, the game starts. Then select 'Refresh Wii Remotes'. This will rumble and crash in 90% of the cases. In 10% of the cases, the game continues and can be played with 2 players.
- With one Remote enabled instead of two, it crashes sometimes.
- Sometimes the crash happens during the rumble: in that case, the rumble of the second controller continuous rumbling forever
- Sometimes it also crashes after some minutes into the game
- On Windows it could not be made 100% reproducable, but crashes were observed
Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.
Yes, 8715
Is the issue present in the latest stable version?
No stable Android version was tested. However, a version of 6 months ago did work at that point.
If the issue isn't present in the latest stable version, which is the first broken version? (You can find the first broken version by bisecting. Windows users can use the tool https://forums.dolphin-emu.org/Thread-green-notice-development-thread-unofficial-dolphin-bisection-tool-for-finding-broken-builds and anyone who is building Dolphin on their own can use git bisect.)
[First broken version number here (if applicable)]
If your issue is a graphical issue, please attach screenshots and record a three frame fifolog of the issue if possible. Screenshots showing what it is supposed to look like from either console or older builds of Dolphin will help too. For more information on how to use the fifoplayer, please check here: https://wiki.dolphin-emu.org/index.php?title=FifoPlayer
[Attach any fifologs if possible, write a description of fifologs and screenshots here to assist people unfamiliar with the game.]
What are your PC specifications? (CPU, GPU, Operating System, more)
NVidia Shield 2017 edition, Oreo
Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)
No logs were found in Android (maybe logging must be turned on?)
Files
Updated by billygoat about 6 years ago
I was unable to replicate this, with or without a usb hub. Can you upload a logcat of the crash?
Updated by eludias about 6 years ago
I will do this on wednesday if you tell me how to make a 'logcat'!
Updated by eludias about 6 years ago
- File dolphin.log dolphin.log added
Strange thing this time: when I finally got logging configured, it did not crash the first time,
but happily it crashed the second time I tried ;-)
Find attached all logging with maximum verbosity of the crash at startup:
The Maybe-relevant lines:
55:35:501 Core/IOS/USB/Bluetooth/BTEmu.cpp:1343 I[IOS_WIIMOTE]: Command: HCI_CMD_SNIFF_MODE
55:35:501 Core/IOS/USB/Bluetooth/BTEmu.cpp:735 I[IOS_WIIMOTE]: Event: Command Status (Opcode: 0x0803)
...
55:35:714 Core/PowerPC/JitArm64/Jit.cpp:98 E[JIT]: Exception handler - Unhandled fault
...
[ It took me a while to realize that the config-file of the Windows version is the same, and lives
under "My Documents\Dolphin Emulator\Config\Logger.ini". So the easiest is to use the Windows-Dolphin
to enable all logging, and copy Logger.ini to the Nvidia Shield via a NFS share via an Android
file manager (since editting on the Android is near-impossible without a keyboard). ]
Updated by billygoat about 6 years ago
This should give a good rundown on how to use logcat. https://android.stackexchange.com/a/33217
If you need adb, you can get the windows tool here https://dl.google.com/android/repository/platform-tools-latest-windows.zip
Updated by eludias about 6 years ago
- File shield_jit.txt shield_jit.txt added
- File shield_cachedinterpreter.txt shield_cachedinterpreter.txt added
- File shield_interpreter.txt shield_interpreter.txt added
I've captured 3 crashes with 'adb logcat', find them attached:
- one crash while in 'JIT' mode
- one crash while in 'Interpreter cached' mode
- one crash while in 'Interpreter' mode
All stacktraces wildly differ alas...
Is there a pre-compiled Valgrind'ed Android debug version or something which might help?
Updated by eludias about 6 years ago
Some more information:
FWIW, it seems very likely that the bug is triggered with the Nvidia Shield 2017 Oreo-update.
Before the update, it did work OK on an older Dolphin version. I verified that old Dolphin versions do indeed crash now on Oreo.
This corresponds with what multiple people report on the forum:
https://forums.dolphin-emu.org/Thread-dolphinbar-issue
Updated by billygoat about 6 years ago
Can you confirm that you have "Transfer files to a computer using USB" off? This can cause some strange things with usb devices. Should be able to find it in Settings -> Storage and Reset
Updated by eludias about 6 years ago
Thanks, the option "Transfer files to a computer USB" was indeed turned on.
I've turned it off.
Turning it off does not change behavior; it crashes immediately, or most of the times within several seconds.
Stacktraces differ a lot, although frequently either in Garbage Collection, or in libc_free, suggesting memory
corruption.
For example, 'adb logcat' results in:
09-09 20:04:27.403 5868 5920 I DolphinEmuNative: Wii Remote 1 connected
09-09 20:04:27.403 5868 5920 I DolphinEmuNative: Wii Remote 2 connected
09-09 20:04:27.406 5868 5886 D NetworkSecurityConfig: No Network Security Config specified, using platform default
09-09 20:04:27.433 5868 5868 D ViewRootImpl[EmulationActivity]: changeCanvasOpacity: opaque=true
09-09 20:04:27.988 5868 5914 W libc : invalid pthread_t (0) passed to libc
09-09 20:04:28.382 5868 5868 D ViewRootImpl[EmulationActivity]: changeCanvasOpacity: opaque=false
09-09 20:04:28.423 5868 5925 I DolphinEmuNative: JITARM64 DC | Vulkan | HLE | FPS: 0 - VPS: 0 - 0% | New Super Mario Bros. Wii (SMNP01)
09-09 20:04:28.435 5868 5893 W OpenGLRenderer: Incorrectly called buildLayer on View: AppCompatImageView, destroying layer...
09-09 20:04:29.355 5868 5925 F libc : Fatal signal 11 (SIGSEGV), code 1, fault addr 0x17f80000210001 in tid 5925 (Thread-15)
09-09 20:04:29.421 5936 5936 I crash_dump64: obtaining output fd from tombstoned
09-09 20:04:29.421 437 437 I /system/bin/tombstoned: received crash request for pid 5868
09-09 20:04:29.422 5936 5936 I crash_dump64: performing dump of process 5868 (target tid = 5925)
09-09 20:04:29.422 5936 5936 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
09-09 20:04:29.422 5936 5936 F DEBUG : Build fingerprint: 'NVIDIA/darcy/darcy:8.0.0/OPR6.170623.010/3019194_1174.8512:user/release-keys'
09-09 20:04:29.422 5936 5936 F DEBUG : Revision: '0'
09-09 20:04:29.422 5936 5936 F DEBUG : ABI: 'arm64'
09-09 20:04:29.422 5936 5936 F DEBUG : pid: 5868, tid: 5925, name: Thread-15 >>> org.dolphinemu.dolphinemu <<<
09-09 20:04:29.422 5936 5936 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x17f80000210001
09-09 20:04:29.422 5936 5936 F DEBUG : x0 0000000000000020 x1 000000235ea0f9e0 x2 000000235e800000 x3 0000000000000002
09-09 20:04:29.422 5936 5936 F DEBUG : x4 000000000000020f x5 0000000000000000 x6 000000233e94a000 x7 0000000000000000
09-09 20:04:29.422 5936 5936 F DEBUG : x8 0000000000000001 x9 7017f80000210000 x10 8fe807ffffdf0000 x11 0000000000000000
09-09 20:04:29.422 5936 5936 F DEBUG : x12 000000002b0f8b58 x13 000000000000b385 x14 000000237e43c0c0 x15 000000002b05186c
09-09 20:04:29.422 5936 5936 F DEBUG : x16 000000233fc9acc0 x17 000000233fc39718 x18 000000002b0f8b58 x19 000000236a2d4010
09-09 20:04:29.422 5936 5936 F DEBUG : x20 000000236a2d4000 x21 000000235ea0f9e0 x22 000000236a2d40a8 x23 000000235ea0f9f8
09-09 20:04:29.422 5936 5936 F DEBUG : x24 6db6db6db6db6db7 x25 0000000000000004 x26 000000000000000a x27 0000002361171ac2
09-09 20:04:29.422 5936 5936 F DEBUG : x28 0000000000000001 x29 000000235cd08df0 x30 000000235c5c987c
09-09 20:04:29.422 5936 5936 F DEBUG : sp 0000002361171a60 pc 000000235c5c9890 pstate 00000000a0000000
09-09 20:04:29.426 5936 5936 F DEBUG :
09-09 20:04:29.426 5936 5936 F DEBUG : backtrace:
09-09 20:04:29.426 5936 5936 F DEBUG : #00 pc 0000000000145890 /data/app/org.dolphinemu.dolphinemu-_zffoQc7B_pRpD6o0fAk0g==/lib/arm64/libmain.so
09-09 20:04:29.426 5936 5936 F DEBUG : #01 pc 0000000000147bac /data/app/org.dolphinemu.dolphinemu-_zffoQc7B_pRpD6o0fAk0g==/lib/arm64/libmain.so
09-09 20:04:29.426 5936 5936 F DEBUG : #02 pc 000000000018ad2c /data/app/org.dolphinemu.dolphinemu-_zffoQc7B_pRpD6o0fAk0g==/lib/arm64/libmain.so
09-09 20:04:29.426 5936 5936 F DEBUG : #03 pc 000000000014edf8 /data/app/org.dolphinemu.dolphinemu-_zffoQc7B_pRpD6o0fAk0g==/lib/arm64/libmain.so
09-09 20:04:29.426 5936 5936 F DEBUG : #04 pc 0000000000132b34 /data/app/org.dolphinemu.dolphinemu-_zffoQc7B_pRpD6o0fAk0g==/lib/arm64/libmain.so
09-09 20:04:29.426 5936 5936 F DEBUG : #05 pc 00000000000dda3c /data/app/org.dolphinemu.dolphinemu-_zffoQc7B_pRpD6o0fAk0g==/lib/arm64/libmain.so
09-09 20:04:29.426 5936 5936 F DEBUG : #06 pc 00000000000010e8 anonymous:0000002366c00000
Is there a way to enable debugging symbol to be able to resolve libmain.so ?
Updated by billygoat about 6 years ago
Can't for the life of me recreate the crash. Can you upload your Dolphin.ini and WiimoteNew.ini? Maybe some setting is different.
Updated by eludias about 6 years ago
- File Dolphin.ini Dolphin.ini added
- File WiimoteNew.ini WiimoteNew.ini added
In the meantime NVidia pushes a new version of the firmware: NVIDIA Shield TV Experience Upgrade 7.1 .
However, the behavior did not change in that version (but it did silently turn on "Transfer files to a computer using USB" again).
Also a DEBUG version (compiled with Android Studio) gave the same crashes (also without stacktraces).
.INI files attached.
Thanks for looking into this; any other way I can help it reproduce?
Updated by billygoat about 6 years ago
Yeah 7.1 also turned it on for me, which is silly since it disables the second USB port when its enabled.
There is something else we can do that finishes what was started in https://github.com/dolphin-emu/dolphin/pull/7301 where android returns 0 on a bad read so that the native code correctly catches it. I didn't put it in then just due to not testing enough and it didn't seem like it caused any issues outside crashing if the remote disconnected mid emulation. I'll put it in a PR later today and post the apk link and see if that works. Forget this, doesn't work. Misremembered things.
Important question, does this only happen with New Super Mario Bros?
Updated by billygoat about 6 years ago
Ok, so I went out and bought an official wiimote and it does crash. I've been using EEEkit wiimotes since they were a quarter of the price(and included nunchuks). So at least I can now recreate the crash locally. And it does crash for every game. Thanks for the info provided!
It looks like the crash has to do with wiimotionplus. I'll try to dig deeper into it when I have time so you may have to get different controllers if its not a quick fix. I can confirm the EEEkit controllers from amazon work, they were $30 for two including nunchuks.
Updated by eludias about 6 years ago
Great that you are able to reproduce the crash, and thanks for the EEEkit advise ;-) .
It indeed happens at all games.
I had to google what the wiimotionplus is: I have no such device, I only have 2 original Wiimotes (which might be different versions, though).
My hesitance on buying a clone is that I had one clone-controller before (unbranded, from China) when I was using the real-Wii. That worked fine. However, I convinced my family that with upgrading to the Shield they could continue playing Super Mario multiplayer, so we got a Shield and installed Dolphin on that, together with a DolphinBar.
Then a new problem arised: The clone-controller failed to connect to the DolphinBar, so to I took no changes from that point on and ordered a second-hand real Wiimote (from the US). That solved the issue and we could indeed play Super Mario again. Until the Oreo upgrade, that is :-)
Back to the wiimotionplus: both my controllers do NOT seem to have a wiimotionplus embedded, if I understand https://en.wikipedia.org/wiki/Wii_MotionPlus well enough. At least, it does not say 'Wii Motion Plus' on the outside of the controllers. Does that still make the bug wiimotionplus related?
Updated by billygoat about 6 years ago
Hey, so I actually just pushed a fix for this. Can you test it out?
https://dl.dolphin-emu.org/prs/pr-7416-dolphin-latest.apk
Updated by eludias about 6 years ago
Great, thanks a lot!
It now works!
I tried to boot it in several ways, and it always reliably started up with working controllers and no crashes.
Small things I noticed:
- First time after installation 'continuous scanning' was turned on, but after first time starting it was turned off(?). However, a manual 'refresh controllers' worked OK, and re-checking the option made it work stable.
- There is a new message saying 'Controller disconnected by emulator' (or something), but has no adverse effects.
- It seems even more stable than before Oreo: before that, I had to start a game sometimes two times to have the controllers detected. Not sure though...
Thanks again!
Updated by billygoat about 6 years ago
- Status changed from New to Fix pending
- Operating system Android added
- Operating system deleted (
N/A)
Updated by JosJuice about 6 years ago
- Has duplicate Emulator Issues #11264: Android and DolphinBar added
Updated by billygoat about 6 years ago
- Status changed from Fix pending to Accepted
Updated by ScottE about 6 years ago
This fixed (and the APK above) worked for me - NVIDIA Shield TV (Oreo), DolphinBar, WII Remote, Motion Plus remote addon thingy.
Looks like it's still not committed to the mainline though.
Updated by billygoat about 6 years ago
I closed it. Was a bit too hacky of a solution to be merged and I just don't know enough about wiimote/dolphin bar usb comm to fix it. I plan to go back and actually learn how it works but there are bigger things to tackle atm. For now if you want to use an up to date build you can sometimes avoid the crash by smashing buttons on the wiimote for about 5 seconds.
After thinking about this, a solution may be to have a more graceful way of handling read failures instead of just straight up crashing emulation, in case this isn't an easy fix.
Updated by billygoat almost 6 years ago
- Status changed from Accepted to Fix pending
- Assignee set to billygoat
Ok, figured out the actual problem on this. Fix is pending https://github.com/dolphin-emu/dolphin/pull/7751
Updated by Billiard26 over 5 years ago
- Status changed from Fix pending to Fixed