[Android] Banjo-Tooie Groggy crash.

[retrobenny]

If you enter the area where Groggy is,my case the Inferno area,it crashes with "unfortunately" error.
Doing so from my savestate made it exit outright,so try hard saving and reaching the area manually.
Both the savestate and .eep save files to help,annoyingly had to compress them both in zip form.
inferno crash.zip
Banjo-Tooie (U) [!].eep.zip

[fzurita]

I got this core dump:

********** Crash dump: **********
Build fingerprint: 'NVIDIA/foster_e/foster:6.0/MRA58K/41937_695.6426:user/release-keys'
pid: 21004, tid: 21195, name: CoreThread  >>> org.mupen64plusae.v3.alpha <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x30
#00 pc 000304ec  libmupen64plus-video-gliden64-gles31.so: Routine PostProcessor::doGammaCorrection(FrameBuffer*) at ../jni/./mupen64plus-video-gliden64/src/PostProcessor.cpp:603
#01 pc 000120d8  libmupen64plus-video-gliden64-gles31.so: Routine FrameBufferList::renderBuffer(unsigned int) at ../jni/./mupen64plus-video-gliden64/src/FrameBuffer.cpp:843 (discriminator 4)
#02 pc 0003ab24  libmupen64plus-video-gliden64-gles31.so: Routine VI_UpdateScreen() at ../jni/./mupen64plus-video-gliden64/src/VI.cpp:156 (discriminator 1)
#03 pc 000b0d84  libmupen64plus-core.so: Routine vi_vertical_interrupt_event at ../jni/./mupen64plus-core/src/vi/vi_controller.c:99
#04 pc 0004543c  libmupen64plus-core.so: Routine gen_interupt at ../jni/./mupen64plus-core/src/r4300/interupt.c:536
#05 pc 000b12a4  libmupen64plus-core.so: Routine .E1 at ../linkage_arm.S:541

[fzurita]

Crashing in this statement:

    m_pResultBuffer->m_postProcessed = _pBuffer->m_postProcessed;

We check to make sure that _pBuffer is not null before using it, so that can't be the problem

[fzurita]

Ok, somehow the PostProcessor::get() method is causing the local static variable to be re-constructed (constructor is being called). I thought this was impossible as far as I knew. And because we don't call PostProcessor::init() after, m_pResultBuffer is a null pointer.

All I can think of is that it's a compiler bug....

[gonetz]

@fzurita I've got assert(checkFBO()) failed in FrameBufferList::attachDepthBuffer() in inferno area.
I think this is the problem we need to fix first. Most likely issue in PostProcessor will gone also.

What is interesting, windows build of mupen64plus works stable here. I've got the issue on Linux.

Update: FrameBufferList::attachDepthBuffer() asserted because gDPSetColorImage called with crazy values.This most likely means that RDRAM was corrupted.

Update2: Game crashes even with fb emulation disabled.

[fzurita]

Hmm, interesting. These kinds of problems are hard to track down. The way it showed up in Android is very strange.

[gonetz]

GLideN64 crashes at random places because commands got crazy parameters and internal structures got corrupted eventually. Looks like core issue. FB emulation is off. RDRAM should be untouched.

At the same time, glide64mk works with no issue at this place.

[fzurita]

Yeah, so even though my fix works in Android, there is no warranty that it will work in Linux. What commands are being called with invalid parameters? Maybe @Gillou68310 can take a look.

[gonetz]

Random. I got wrong call to load_tlut, then I got line command called from F3DEX2 ucode, something else. May be I need to build latest master of mupen64plus core to see that the problem still exists.

Update: built mupen64plus core lib from sources. No change.

[retrobenny]

So,did you try it restarting the game after saving and quitting then returning to the place manually?
I first encountered the crash with a single code enabled then tried again with no codes on,and also normal Glide64 works with the code (Unlimited Travel 800D53DB 009A by Authentic) on.

Gillou is the one who made Banjo-Tooie run properly with it no longer crashing randomly,he also fixed DK64 collision.

[gonetz]

I loaded from save (not savestate), entered the inferno and eventually got the same error.

[gonetz]

@fzurita I'm trying to build current master of mupen64plus-ae with Eclipse on Linux. I've got:

The container 'Android Dependencies' references non existing library 'mupen64plus-ae/libs/extras/android/support/v14/preference/bin/preference.jar' mupen64plus-ae Build path Build Path Problem

The project cannot be built until build path errors are resolved mupen64plus-ae Unknown Java Problem

error: Error retrieving parent for item: No resource found that matches the given name 'PreferenceFragmentList'. values.xml /mupen64plus-ae/libs/extras/android/support/v14/preference/res/values line 44 Android AAPT Problem

error: Error retrieving parent for item: No resource found that matches the given name 'PreferenceFragmentList'. values.xml /preference/res/values line 44 Android AAPT Problem

Any idea, how to fix it?

[Gillou68310]

I got a similar problem, I think this was caused by v14/preference and v7/preference sharing the same project name.
IIRC I fixed the issue by loading the v14/preference library alone then renaming the project to preference14 and finally loading all other libraries.

[fzurita]

Yep, what @Gillou68310 said

[gonetz]

Ok, I renamed the project to preference14. Now I got bunch of java errors
One is
The method addDrawerListener(new DrawerLayout.DrawerListener(){}) is undefined for the type GameDrawerLayout GameActivity.java /mupen64plus-ae/src/paulscode/android/mupen64plusae/game line 310 Java Problem

[fzurita]

That's my fault. Go back to this commit:

mupen64plus-ae/mupen64plus-ae@2474cf1

[fzurita]

Ok, I fixed the build issue. The latest master should work fine again in Eclipse.

[gonetz]

Arr!!! Just reverted to 2474cf1
Successfully built it btw.

[fzurita]

Whoops, sorry about that. Good that it builds now.

[gonetz]

Build issue fixed in new master, thanks!

[fzurita]

No problem!

[gonetz]

@Gillou68310 @fzurita could you test mupen64plus-ae with GLideN64 from commit 95b5f55?
It seems that new blending has performance issues.

[fzurita]

Yeah, sure, I'll give this a shot later tonight.

[gonetz]

Another question:
mupen64plus-ae\src\paulscode\android\mupen64plusae\GalleryActivity.java(802,49): error : diamond operator is not supported in -source 1.5
mupen64plus-ae\src\paulscode\android\mupen64plusae\GalleryActivity.java(802,49): error : (use -source 7 or higher to enable diamond operator)

Where that -source parameter set?

[fzurita]

It should already be set correctly in this file:

https://github.com/mupen64plus-ae/mupen64plus-ae/blob/master/.settings/org.eclipse.jdt.core.prefs

Have you tried restarting eclipse after going to the newest master?

[fzurita]

If that doesn't work, here is a way to set it manually:

http://stackoverflow.com/questions/8022233/changing-eclipses-java-compiler-to-jdk7

[gonetz]

It is not Eclipse. Eclipse also has that issue, but it can resolve it.
I'm trying to build the project with MSVS using NVidia plugin.

[gonetz]

NVidia CodeWorksforAndroid uses jdk1.7.0_71

[fzurita]

Hmmm, I believe that's a parameter you pass to the javac compiler. I'm not really sure how MSVS with the NVidia plugin does things under the hood. I don't use MSVS much.

Since you are using the right JDK version, there must be a way to change the compiler to use the newer java language version.

[gonetz]

Can't find where it can be set. Not so many java settings here. Eclipse seems to be the only option left.

[fzurita]

I did a little research and it seems like Microsoft Visual studio is using some sort of java/android plugin. Maybe under that plugin's settings.

[fzurita]

I merged your changes into this branch:

https://github.com/mupen64plus-ae/mupen64plus-ae/commits/new_blending

[fzurita]

Graphics look completely bugged in GLES 2.0, at least in my phone in Mario 64, I didn't try in the Shield TV.

In GLES 3.0 I found performance identical in my phone.

[gonetz]

I've fixed an issue with shaders. Please test with latest commits.

[fzurita]

Most issues are gone in Mario 64. I still see the issue during the Mario 64 intro where random flickering happens. That may be in the master branch as well though.

[fzurita]

Performance seems identical

[fzurita]

Native resolution factor doesn't seem to work well with GL ES 2.0

[fzurita]

I'll investigate this more later... I'm back to having issues and I don't think I changed anything. I have to get going to work.

[fzurita]

I think I'm finding out the issues with the GL ES 2.0 version of the plugin. Your experimental_blend branch didn't break anything. Here is what happens even in the master branch.

Everything works ok, as long as you don't reset the game. If you reset a game GLideN64 starts up with default settings. With default settings, BufferSwapMode of "On VI update call" is very broken, at least in Mario 64.

[fzurita]

Doing a reset or loading a save state sets the BufferSwapMode to 0 only in the GL ES 2.0 version of the plugin.

Edit: Hmm.... config.frameBufferEmulation.bufferSwapMode is actually staying with the correct value. But, the graphics are acting the same as if config.frameBufferEmulation.bufferSwapMode was set to 0. Anyways, I think something is broken in GL ES 2.0 related to frame buffers and it has been broken for a while.

[fzurita]

Majora's mask is very broken with the new blending using GL ES 3.0. Nothing renders in my screen after the N64 logo. And the logcat has a lot of spam of this:

04-30 01:46:05.711 2892-7288/org.mupen64plusae.v3.alpha E/Adreno-ES20: <rb_timestamp_wait_on_timestamp:341>: gsl_device_waittimestamp failed in rb_timestamp_wait_on_timestamp
04-30 01:46:05.711 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <gsl_ldd_control:416>: ioctl fd 31 code 0xc02c093d (IOCTL_KGSL_SUBMIT_COMMANDS) failed: errno 35 Resource deadlock would occur
04-30 01:46:05.711 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <log_gpu_snapshot:331>: panel.gpuSnapshotPath is not set.not generating user snapshot
04-30 01:46:05.711 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-EGL: <eglTimestampCreate:5600>: EGL_CONTEXT_LOST
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <gsl_ldd_control:416>: ioctl fd 31 code 0xc02c093d (IOCTL_KGSL_SUBMIT_COMMANDS) failed: errno 35 Resource deadlock would occur
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <log_gpu_snapshot:331>: panel.gpuSnapshotPath is not set.not generating user snapshot
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <gsl_ldd_control:416>: ioctl fd 31 code 0xc02c093d (IOCTL_KGSL_SUBMIT_COMMANDS) failed: errno 35 Resource deadlock would occur
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <log_gpu_snapshot:331>: panel.gpuSnapshotPath is not set.not generating user snapshot
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <gsl_ldd_control:416>: ioctl fd 31 code 0x400c0907 (IOCTL_KGSL_DEVICE_WAITTIMESTAMP_CTXTID) failed: errno 35 Resource deadlock would occur
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <log_gpu_snapshot:331>: panel.gpuSnapshotPath is not set.not generating user snapshot
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha E/Adreno-ES20: <rb_timestamp_wait_on_timestamp:341>: gsl_device_waittimestamp failed in rb_timestamp_wait_on_timestamp
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <gsl_ldd_control:416>: ioctl fd 31 code 0xc02c093d (IOCTL_KGSL_SUBMIT_COMMANDS) failed: errno 35 Resource deadlock would occur
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <log_gpu_snapshot:331>: panel.gpuSnapshotPath is not set.not generating user snapshot
04-30 01:46:05.717 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-EGL: <eglTimestampCreate:5600>: EGL_CONTEXT_LOST
04-30 01:46:05.720 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <gsl_ldd_control:416>: ioctl fd 31 code 0xc02c093d (IOCTL_KGSL_SUBMIT_COMMANDS) failed: errno 35 Resource deadlock would occur
04-30 01:46:05.720 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <log_gpu_snapshot:331>: panel.gpuSnapshotPath is not set.not generating user snapshot
04-30 01:46:05.720 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <gsl_ldd_control:416>: ioctl fd 31 code 0xc02c093d (IOCTL_KGSL_SUBMIT_COMMANDS) failed: errno 35 Resource deadlock would occur
04-30 01:46:05.720 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <log_gpu_snapshot:331>: panel.gpuSnapshotPath is not set.not generating user snapshot
04-30 01:46:05.720 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <gsl_ldd_control:416>: ioctl fd 31 code 0x400c0907 (IOCTL_KGSL_DEVICE_WAITTIMESTAMP_CTXTID) failed: errno 35 Resource deadlock would occur
04-30 01:46:05.720 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <log_gpu_snapshot:331>: panel.gpuSnapshotPath is not set.not generating user snapshot
04-30 01:46:05.720 2892-7288/org.mupen64plusae.v3.alpha E/Adreno-ES20: <rb_timestamp_wait_on_timestamp:341>: gsl_device_waittimestamp failed in rb_timestamp_wait_on_timestamp
04-30 01:46:05.720 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <gsl_ldd_control:416>: ioctl fd 31 code 0xc02c093d (IOCTL_KGSL_SUBMIT_COMMANDS) failed: errno 35 Resource deadlock would occur
04-30 01:46:05.720 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-GSL: <log_gpu_snapshot:331>: panel.gpuSnapshotPath is not set.not generating user snapshot
04-30 01:46:05.720 2892-7288/org.mupen64plusae.v3.alpha W/Adreno-EGL: <eglTimestampCreate:5600>: EGL_CONTEXT_LOST

This phone has adreno 330 GPU.

Majora's mask works fine in the NVidia Shield TV. It must be some Adreno driver bug.... nothing new there.

Majora's mask does have some issues with the shield TV. Check the title screen at the beginning. Multiple copies of the mask will be rendered. The shield TV issue is in the master branch as well, so not related to thew new blending.

[gonetz]

I just built mupen64plusae from new_blending branch and run it on my Note 3 with adreno 330 GPU. No issues with Majora's mask intro. Tested with GLES2 and GLES3, both work.

May be you need to clear shaders folder?

Update: GLideN64 may work incorrect if you run several games in a row. Something is not cleared right. It is better to restart application from time to time until I find what's wrong.

[retrobenny]

I just finished a brief marathon of Banjo-Tooie to reach the Groggy part,no cheats at all,and it crashes still.
This time Groggy is in the corner of the space themed section near a Jamjar silo,as it triggers a crash the instant I get close enough to that area,take note I used the Full GL variant in fzurita's build.
Will post a save file copy briefly.

[fzurita]

gonetz merged my pull request in a few days ago, but I haven't made a build with it fixed. I can go ahead and make you a build with the fix.

[retrobenny]

Found a less hacky method? Here is my save anyway.
BT Save.zip

[fzurita]

The method is still hacky, but it's being done through ANDROID #ifdefs. Here is a build of the latest master branch:

https://drive.google.com/file/d/0B57Ioy26LWegT01QQUh1UkVBM2s/view?usp=sharing

[retrobenny]

Dammit,it still crashed! I even pre-emptively reloaded app resources to make it cleaner. :(

Maybe we need a multi purpose option that acts as all better speedhacks and non-crashing workarounds,i'd still like to see a mostly hacked GLES2 variant for correct-looking graphics at ultimately fast speeds with no glitchy issues despite low accuracy because of how well the hacks would work.

[fzurita]

Hmm... the crashes in that game are due to memory corruption. Memory must be corrupting somewhere else. I believe gonetz thought that some bad commands were being sent from the core. Maybe the right answer is to check for those commands and do nothing instead when they happen.

[retrobenny]

Pure Interpreter also crashes in the same fashion. I wonder if it also crashes on PC on other emulators,maybe if they don't,their cores can be checked for particular differences.

[retrobenny]

Groggy no longer crashes as of recent cheatless/default FullGL profile test just now in .10 Mupen FZ Play Store version,another global Tooie crash was fixed before then thanks to @Gillou68310 along with a user and @fzurita testing.