Emulator

Try the latest development version please.

3.0-234 --> https://github.com/dolphin-emu/dolphin/commit/1ad05f7440c15a2614a98101b59d3358c5e71141 --> Merge branch 'master' of https://code.google.com/p/dolphin-emu

Whoever you are nitsuja, I hate you right now.

I made this build in an effort to narrow down the problem. While not all of the code from back then is still around, some of it still is. I'm not a good coder, in fact, I'm negatively good at code, so there's no guarantee that I did it properly and it may not work at all. But, most of what was in the old build is ported into latest. Let me know this fixes your issue, thanks!

https://dl.dropboxusercontent.com/u/484730/Dolphin.exe

I tried it JMC but it crashes.

That build is basically the build they specified as the one that broke it reverted. I don't know what else I can do. I couldn't revert /everything/ from that build because some of the code no longer exists.

I am ok with you hating me Mr Roach...I mean MaJoRoesch. :P
I'll try the latest development version.
Is there anything else I can do to help?

-nitsuja (aka TheNinjaofEarth) xD

v4.0.2 is lagging really bad, even when using OpenGL and . We are talking 79% at best, durring opening video. Normally runs around 98%-100% with older versions (i.e. v3.5-2436). Any ideas?

-nitsuja (aka TheNinjaofEarth) xP

I narrowed down the problem to 4 files.

1. cg.dll
2. cgGL.dll
3. SDL.dll
4. Dolphin.exe
   When I replace these 4 files in v3.0-232 and exchange them with the same files from v3.0-234, dolphin starts crashing. Is there a program I can open these 4 files in, to see what change between with-in them from 1 version to the next?

-nitsuja (aka TheNinjaofEarth)

Well, the problem currently is that some of the code that was changed between those builds is no longer in existence, and trying to port them over didn't fix it.

btw: I don't think MaJoR literally hates anyone; just funny because there was no description for why the commit did what it did, and no comments explaining it.

I never thought he did. I was just using sarcasm. Plus I like saying "nitsuja" although I am courtesy to know what the word means...

When you say "trying to port them over" what all does that include?

Is there a way for me to reverse engineer v3.0-232 back to a build?

-TheNinjaofEarth
--aka EarthNinja (or just Earth...) xD

Once you can build Dolphin, you just need to find the build in question and undo the changes done.

So your saying I need to register somewhere to help build Dolphin and then use the source code to reverse engineer the build?

-Earth

You don't have to register anywhere, you just need to use git to clone the database, then try to figure out what the build that broke it was doing, and try to make it not fail.

ok cool. Thx for the advice, JMC.

-Earth

When you say database do you mean my copy of Dolphin?

I just noticed that when you go to Medabots Infinity game properties though dolphin, at the bottom it says emulation status: Use LLE plugin for proper ingame sound. "MMU speed hack is needed for balloon bombs or the game crashes." Was there any moding done to the MMU when the Dolphin v3.0-234 build was created? I would look myself but I still don't understand how. Can someone help me understand how to "clone the database" using git (instead of google) and where to start looking for this bug? Thx

-Earth

What happens when you use MMU or the MMU speedhack in versions after 3.0-234?

Let me check MaJo.

On a side note: I am currently testing on Dolphin v3.0-232. The game by default is using MMU speedhack, but when I change from what I call "auto" (Emu setting override the games internal settings) to "Enable" MMU it lags about 25%-30% not sure why the "MMU Speedhack" in enabled if "MMU" is "Disabled". Changing "MMU Speedhack" while MMU is "Disabled" has no effect on lag or the Balloon Bomb Bug...

-Earth

I tested v4.0 no revisions, without MMU enabled it doesn't lag but still freezes when a balloon bomb is shot. MMU Speedhack was enabled for all but 1 test on this version. No change in results.

-Earth

I have a friend who is willig to try teaching me how to reverse engineer the build but I need to know what computer language(s) Dolphin uses. Can anyone help me, so I can work deeper on the bug?

Was doing some testing of my own, and the bug seems to be from 3.0-871 and onward instead of 3.0-234

I tested:
v3.0-232 - working
v3.0-234 - working
v3.0-432 - working
v3.0-716 - working
v3.0-752 - working
v3.0-771 - working
v3.0-788 - working
v3.0-801 - working
v3.0-804 - working
v3.0-807 - working
v3.0-809 - working
v3.0-810 - working
v3.0-831 - working
v3.0-842 - working
v3.0-846 - working
v3.0-862 - working
v3.0-869 - working
v3.0-870 - working
v3.0-871 - not working
v3.0-873 - not working
v3.0-901 - not working
v3.0-924 - not working

(tested 32-bit from https://dolphin-emu.org/download/list/master/)

Software rendering seems fine

I can confirm DigidragonZX's findings. 3.0-870 does not work while 3.0-871 does work. Commit: https://github.com/dolphin-emu/dolphin/commit/30718230b2e673f318ca892d1a70ab70532528bd

What did you change?

-Earth

Digi is right, I just tested v3.0-870 myself. Looks like I was wrong... Lol

-Earth

Nothing, it may have been that you had been using the http://www.dolphin-emulator.com/ version but that one seems to stop working after v3.0-807 so I'm not sure how you got to the conclusiont that it was between v3.0-232 and v3.0-234 but I didn't see any diffrence there.

Still doesn't fix the issue though, and it seems that the commit at v3.0-871 isn't anything big either so no idea how to fix it right now. I haven't worked with dolphin before but I can try some things but I don't think I'll be able to fix it myself.

Though I've got the disc lying around and a gamecube next to me so for me this isn't that big of a problem (though it would be easier to just play in on my pc :P)

v3.0-232 was x64 I failed to isolate the version on x86.

Earth

Also for some reason v3.0-870 x86 started freezing yesterday when I shoot a balloon bomb, where it did not do this before... What info can I give you guys to help me figure this out?

Earth

I was testing v3.0-232 x64 and shot a balloon bomb by mistake. When I did Dolphin froze. I purged the cache and tried again, it fixed it. Is it possible that the newer versions of have problem exists in how the cache is processed??

-Earth

Man I was tired when I wrote that last post. Lol. What I was trying to ask was, is it possible that a problem exists, with the way the later versions of Dolphin process cache for the game?

-Earth

So I was using "Microsoft Visual Studio" to debug this issue on Dolphin v4.0.2 and received this error "Unhandled exception at 0x000000000166C120 in Dolphin.exe: 0xC0000005: Access violation reading location 0x0000000000000000." Then when I press the "Break" button and I get an error message with in "Microsoft Visual Studio" saying "Dolphin.pdb" is required to find the source for the module "Dolphin.exe"

Is there a way for me to obtain a copy of "Dolphin.pdb"?

-Earth

Can you try this in the latest development builds? Maybe try enabling MMU or the MMU speedhack?

I tried with dolphin-master-4.0-3469-x64
and I still get the error at all the different settings:

with MMU and without
with MMU speedhack and without
and with both on or off at the same time

(I would be really happy if somehow you could upload the build to a server near or in china.... since I'm working here atm, understandable if you won't and downloading 2 hours on my work isn't that big of a problem.)

Can you go into the game properties, info tab, and get the disc MD5?

md5 = 36f8606d222e614dab20d2286184dc6d

(I think I didn't make a typo but its possible since I send this from my phone, 3g works better :p)

Okay, just wanted to verify that. Thank you, didn't know it'd be such a pain!

Didn't mater that much, I had to wait regardless. And I'm quite curious to see what the problem is, as a programmer and as someone who actualy want's to finaly finish the game after a long time.

So good luck and don't hesitate to ask something since I'll be glad to help out. Though I might react a bit late...

According to Shuffle2, the crash is caused by getpointer returning 0.

JMC47: the crash is because in TextureCache::TCacheEntryBase* TextureCache::Load, from_tmem==false, src_data=0,Gethash64 crashes
Memory::GetPointer returns 0
address=0x3ffffe0

http://pastie.org/pastes/9615924/text

Ok. So how do we fix it?

No idea yet, but we're closer.

Just after I posted my Jun 22 post, I found a form that lead me to believe that the error message might be the result of a get pointer returning to 0, but I didn't know if I was right and didn't want to post something in error. I looked through what I could, using MS visual studios 2013 debugging info of the game crashing, and I may still have the info from it. Will posting the info help at all?

The thread 0x189c has exited with code 0 (0x0).
Unhandled exception at 0x0000000000875670 in Dolphin.exe: 0xC0000005: Access violation reading location 0x0000000000000000.

I left the 1st line, of this post, out of my earlier post (because I did know what I was doing, lol). If you need more debugging info or anything else that I can help with, let me know.

Could you get a dump from a working and broken 32 bit version as well, since with only this I'm not sure where the problem lies

You need to figure out why it's trying to load a texture from 0x3ffffe0

(the crash is not relevant to the emulation bug, and i've already pointed out the cause)

I also get this issue in Final Fantasy: Crystal Chronicles PAL. I haven't worked out why it is trying to load a texture from a strange address, although I understand why GetPointer is returning NULL. It could be a bad dump, I haven't checked.

I will get you those dumps. Where do you want me to send them?

godisgovernment: It may not be related to the "emulation bug" your referring to but it is an issue with the emulator it's self.

Just to be clear are you talking about, a dump of textures, more then that, or something else(please specify)?

A crash dump, which is apparently gotten through Task Manager once Dolphin stops responding.

I have those dumps. How do you want me to get them to you?

Can this be retried since a whole bunch of GetPointers were removed at some point?

I just tested this on 4.0-4424. The game still crashes when shooting a balloon.

The commit mentioned earlier doesn't make sense to break this game.

I think it would be best to close this issue report and make a more thorough bisect.

Did this game ever not exhibit this issue 100% without crashing?

@JMC could you maybe see to a new issue report this one is misleading.

1. As I stated before. This issue does not exist on any version prior to v3.0-r232 that was tested. The issue IS with the emulator contrary to popular belief.

2. What is misleading about it?

This is an easy to reproduce crsah that doesn't happen on software renderer; there's no reason to close it.

This is exactly what i'm talking about. It's stated that it worked on any version prior to 3.0-232.

I just spent some time looking at that and it shouldn't cause issues.
Then everyone agreed that it was in fact 3.0-871

3.0-871 makes no bit of sense whatsoever. I think these issue report should not throw people of fixing this issue. Do you not agree?

No.. I don't agree, just so we are clear, we are dealing with x86 and x64. On x86 versions the issue starts with v3.0-r871. On x64 versions the issue starts with v3.0-r234.

Hey all, I recently tested this issue (having previously never resolved it after many attempts). My machine is 64-bit running Windows 7.
Finally saw the balloon drop with NO crash and horrible electronic noise. I used Dolphin 3.0 159 and enabled LLE on Interpreter (had to install these files https://www.youtube.com/watch?v=4dYlJN8vZCY on version 159, I had them in other versions but 159 did not come with them).. Thank you to everyone in this issue report, especially the guys trying to keep it open and get it solved.

The 2 files you mentioned were already being used when I posted this issue. It will work up to v3.0-r232 on x64 versions of Dolphin. Thank you for the trying. :)

To be honest, I'm not sure if we want to call this fixed as it still triggers a PanicAlert. And we still need to track why this crash does not happen on the real hardware. But there is a good chance that we can't fix this kind of issue without software rendering :/