SW: Force Unleashed regression with debug build, r782

[GoogleCodeExporter]

Star Wars Force Unleashed is on semi-stable stage, but it's no good when
it's crush at debug/devel build. There was similar regression at 686-706,
but r706 is working

Normal build is unaffected, but debug one is crushed on start from 782,
last known unaffected revision in r781.

But the reason of failure is not so good: it's assertion:

assert(s_pCurBlock->GetFnptr() == (uptr)iopJITCompile
    || s_pCurBlock->GetFnptr() == (uptr)iopJITCompileInBlock);

That is false!. s_pCurBlock->GetFnptr() = b13de1c0

Original issue reported on code.google.com by Zeydl...@gmail.com on 31 Mar 2009 at 12:21

[GoogleCodeExporter]

Quick note: this is assertion on x86/aR3000A.cpp, that was here at r781 -- so 
it's
not something wrong with blocks placement?

Original comment by Zeydl...@gmail.com on 31 Mar 2009 at 12:32

[GoogleCodeExporter]

Also Sonic Unleashed have this issue. Reason of crush lies in iR3000.cpp, at new
iopRecRecompile function, even more, in psxbranch3 code (I think in !psxbranch 
path).
But I does not understand what does this code do.

Why I think so? Because I change new iopRecRecompile fucntion to old one (with a
little mess with baseblocks functions) and it start to work.

Original comment by Zeydl...@gmail.com on 1 Apr 2009 at 8:44

[GoogleCodeExporter]

I pretty sure that baseblock:Link function is wrongly done. It does not seem to 
right
thing use fntpr instead of GetFnptr() because they have DIFFERENT values, I 
don't
know how it was supposed to be, but just right now r782 seems to do a lot of 
ugly stuff.

Original comment by Zeydl...@gmail.com on 1 Apr 2009 at 9:46

[GoogleCodeExporter]

Original comment by arcum42@gmail.com on 3 Apr 2009 at 1:49

• Changed title: SW: Force Unleashed regression with debug build, r782

[GoogleCodeExporter]

And here Windows build are affected too.

Original comment by Zeydl...@gmail.com on 3 Apr 2009 at 6:55

[GoogleCodeExporter]

Another game that have this issue -- Radiata Stories. Isn't list bigger enough?

Original comment by Zeydl...@gmail.com on 4 Apr 2009 at 6:24

[GoogleCodeExporter]

Assigned to sudonim for review.  He'll know better what's going on here, I 
suspect.

Original comment by Jake.Stine on 5 Apr 2009 at 1:36

[GoogleCodeExporter]

Ignoring your wilder assertions about the code, are you quite sure that you 
have the
right assert()? There is an assert later in the function which is known to 
trigger (I
added it as a sanity check for data we aren't yet using):

    assert(x86Ptr[_EmitterId_] - recPtr < 0x10000);

B13DE1C0 isn't an address in IOP recompiled memory (we map this starting at 
28000000)
so unless that is in fact the address of one of the IOP JIT compile functions, 
you
have memory corruption.  This may be the case, but it seems more likely to me 
that
you're mistaken about where the games are failing.

Original comment by sudonim1 on 5 Apr 2009 at 3:09

[GoogleCodeExporter]

This assertion triggered only from r785. And r782, 783 and 784 asserted in on I
mention at start. Well, I don't pretend on understanding this code, but 
reverting you
revision r782 back (it's impossible with latest revisions, so try something like
r850) solve the issue.

And about b13de1c0 -- I must note, that code in iR3000A.cpp psxRecRecompile 
function
putting such values into pFnptr (lines 1338-1345). Maybe it's desinged by that.

Original comment by Zeydl...@gmail.com on 5 Apr 2009 at 5:57

[GoogleCodeExporter]

My iR3000A.cpp doesn't even have as many as 1338 lines, so I have no idea what 
code
you are referring to.  Are you testing a version of pcsx2 with personal patches 
applied?

Original comment by sudonim1 on 5 Apr 2009 at 2:21

[GoogleCodeExporter]

Nah, it's was older version. I speak about iopRecRecompile() one. You know, 
there is
a list of crushed games on Windows and Linux.

Original comment by Zeydl...@gmail.com on 5 Apr 2009 at 2:48

[GoogleCodeExporter]

I just tested star wars force unleashed on windows and it failed with the 
assert I
expected - the 64k block one, not yours.  The same assert triggers once more 
then the
game boots and is playable.

Please recheck your facts for all the games mentioned, taking extra care, then 
report
back.

Original comment by sudonim1 on 6 Apr 2009 at 3:39

[GoogleCodeExporter]

As you wish:

At r782 (debug), Windows with GSDX, clear build:
Sonic Unleashed crushed at: 
assert(s_pCurBlock->GetFnptr() == (uptr)iopJITCompile
    || s_pCurBlock->GetFnptr() == (uptr)iopJITCompileInBlock);

Radiata Stories crushed at (with VU add hack):
assert(s_pCurBlock->GetFnptr() == (uptr)iopJITCompile
    || s_pCurBlock->GetFnptr() == (uptr)iopJITCompileInBlock);

SW:Force unleashed crushed at:
assert(s_pCurBlock->GetFnptr() == (uptr)iopJITCompile
    || s_pCurBlock->GetFnptr() == (uptr)iopJITCompileInBlock);

At r785, r863 and r915
Radiata Stories crushed at (with VU add hack):
    assert(x86Ptr[_EmitterId_] - recPtr < 0x10000);

SW:Force unleashed crushed at:
    assert(x86Ptr[_EmitterId_] - recPtr < 0x10000);

Sonic Uleashed: No crush.

Original comment by Zeydl...@gmail.com on 6 Apr 2009 at 5:22

[GoogleCodeExporter]

Addition: 
Dokapon Kingdom (under Linux):
r782:
assert(s_pCurBlock->GetFnptr() == (uptr)iopJITCompile
    || s_pCurBlock->GetFnptr() == (uptr)iopJITCompileInBlock);

r865, 898, 915
    assert(x86Ptr[_EmitterId_] - recPtr < 0x10000);

Original comment by Zeydl...@gmail.com on 6 Apr 2009 at 9:42

[GoogleCodeExporter]

...so this only affects revisions from over a fortnight ago? It's not worth 
tracking
down bugs in such an old revision that have gone away since.

Original comment by sudonim1 on 7 Apr 2009 at 12:13

[GoogleCodeExporter]

r915? SW:FU, RadiataStories and Dokapon Kingdom still crush.

Original comment by Zeydl...@gmail.com on 7 Apr 2009 at 3:01

[GoogleCodeExporter]

They assert, and only in debug (and devel?) builds, and on an assertion whose
condition is known to yet be enforced.  Extremely large recompiled blocks may be
problematic for future features and a decision whether to split them or allow 
for
them has to be made.  Meanwhile it is not affecting release functionality; if 
that
assert is bothering you while debugging the emulator, you can safely disable it.

Original comment by sudonim1 on 7 Apr 2009 at 3:12

[GoogleCodeExporter]

This is most likely outdated.

Original comment by ramapcsx2 on 26 Feb 2011 at 10:40

• Changed state: WontFix

[GoogleCodeExporter]

It's not outdated, the issue's still current though not critical.

Original comment by sudonim1 on 2 Mar 2011 at 4:53

• Changed state: Accepted

[GoogleCodeExporter]

Does this still happen?

Original comment by refraction on 5 Apr 2013 at 10:31