Arc the Lad [Linux] regression on r815

[GoogleCodeExporter]

I found, that Arc the Lad crushed after the into scene from r815 (and it is
the revision with savesates change), just before "First battle Kharg"
screen should appear. 

Console note: terminate called after throwing an instance of
'R5900Exception::Trap'

But there is two things, that should be noted: I use savestate from r850
that I made before scene battle to get here, because r815 have different
bug, that lead to crush just earlier. Revision r814 run from very start
flawlessly. 

Original issue reported on code.google.com by Zeydl...@gmail.com on 28 Mar 2009 at 9:30

[GoogleCodeExporter]

Windows build works (of course :p ).

Original comment by ramapcsx2 on 29 Mar 2009 at 12:23

[GoogleCodeExporter]

Don't have Arc the Lad, so I can't really test it...

Original comment by arcum42@gmail.com on 29 Mar 2009 at 2:33

[GoogleCodeExporter]

Well... This is trap issue, but I don't understand why it does not happened on 
r814
-- because step between r814 and r815 should not touch memory and exceptions?

Original comment by Zeydl...@gmail.com on 29 Mar 2009 at 3:03

[GoogleCodeExporter]

It seems that this issue was with us from at least playground r689. Last 
unaffected
revision is playground r458. And all playground revisions from r458 to r688 was 
never
working :-(.

Original comment by Zeydl...@gmail.com on 3 Apr 2009 at 12:52

[GoogleCodeExporter]

One thing are spammed my mind -- linux memzero,h are highly different from 
windows
one. Probably, there should be merge? I could redone asembly part, but I don't 
know
what should be here.

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

[GoogleCodeExporter]

They should at least do about the same thing, even if in different files.

I've been meaning to rewrite that. I started to after finding a automatic 
windows
inline assembly code to gcc converter, but the generated code wasn't 
compilable, and
after fiddling with it for a while, I decided to come back to it later...

Original comment by arcum42@gmail.com on 4 Apr 2009 at 12:22

[GoogleCodeExporter]

Is there even a need for something fancy on the Linux/GCC side?  I only wrote 
the
memzero.h implementation because MSVC fails to do an intrinsic version of 
memset, and
it's non-intrinsic version clobbers XMM0 (which is potentially dangerous).  I'm 
not
sure if GCC has the same problem even, so it might work perfectly fine just 
falling
back on built-in memset() for everything.

For that matter, it's a really minor thing in terms of speed.  The XMM0 
clobbering
was my main concern, and then making it as compact as possible just became part 
of
the exercise. :)

So if GCC's memset doesn't clobber XMM0, then I'd recommend just falling back on
memset instead of trying to make some GCC'ified implementation -- especially if
you're having problems with it.

Original comment by Jake.Stine on 4 Apr 2009 at 2:24

[GoogleCodeExporter]

I don't know if the Linux version of memset clobbers any registers. The main 
reason
why I was concerned about getting the gcc version as close to the Windows 
version as
possible is to make sure that Linux crashes in the same places as Windows, 
essentially. 

And, of course, it's easier to mantain platform-specific code if it changes 
when the
two versions are pretty close.

And, of course, there's no guarantee that this problem has anything to do with
memzero.h...

Original comment by arcum42@gmail.com on 4 Apr 2009 at 3:27

[GoogleCodeExporter]

So first of all this is regression between r458 playground and r466 playground 
OR
memory.cpp from r545 (platground) issue. I was able to compile r466 (minus 
r460, r462
and r463 that is not related) with foloowing patch to memory.c (yes, at such 
ancient
times there was plain c files) and games became playable. But! I see all of 
memory
handling issues, I aware of (except Star Ocean 3 and Radiata Stories, that 
could not
be checked, as you understand -- they require proper gamefix):

Arc The Lad crushed on intro
MGS3:Substenance crushed on intro before first text appeared
Okami miss some intro stuff (Clover logo) and loop on intro.

Of cource, I have a lot of compilated revisions between r466 and r686 (official 
Linux
build fix).

Right now I plan go to Windows and check playground builds, if they have memory
handling issues on this revisions. If no, that error, probably, bug in arcum42 
(or
Jake.Stine) code on r459, r461, 464, 465 or 466.

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

Attachments:

• a.txt

[GoogleCodeExporter]

Well, could somebody with knowledge of pcsx2 recompiller help me:

The crush occurred in this block, on cltd instruction, this is AT%T syntax, so 
order
are reverted:

0xb62463cd: mov    $0x1d5ea94,%eax
0xb62463d2: mov    0x83fd550,%ecx
0xb62463d8: add    $0x1c,%ecx
0xb62463db: mov    %ecx,%eax
0xb62463dd: shr    $0xc,%eax
0xb62463e0: mov    0x847f480(,%eax,4),%eax
0xb62463e7: add    %eax,%ecx
0xb62463e9: js     0xb62463ef
0xb62463eb: mov    (%ecx),%eax
0xb62463ed: jmp    0xb6246403
0xb62463ef: movzbl %al,%eax
0xb62463f2: sub    %eax,%ecx
0xb62463f4: mov    0x887fc80(,%eax,4),%eax
0xb62463fb: sub    $0x80000000,%ecx
0xb6246401: call   *%eax
0xb6246403: cltd   
0xb6246404: mov    %eax,0x83fd550
0xb6246409: mov    %edx,0x83fd554
0xb624640f: mov    $0x1d5ea98,%eax

I hope, that I understand correctly, and first operation marked cpuregs
($0x1d5ea94,%eax). Well, as I know, cltd should use another semantics, mov %eax,
value, mov %edx value, cltd? Or I wrong?

This block on r466playground + memory patch produce similar block with slight 
difference:
0xb62463cd: mov    $0x1d5ea94,%eax
0xb62463d2: mov    0x83fd550,%ecx
0xb62463d8: add    $0x1c,%ecx
0xb62463db: mov    %ecx,%eax
0xb62463dd: shr    $0xc,%eax
0xb62463e0: mov    0x847f480(,%eax,4),%eax
0xb62463e7: add    %eax,%ecx
0xb62463e9: js     0xb62463ef
0xb62463eb: mov    (%ecx),%eax
0xb62463ed: jmp    0xb6246403
0xb62463ef: movzbl %al,%eax
0xb62463f2: sub    %eax,%ecx
0xb62463f4: mov    0x887fc80(,%eax,4),%eax
0xb62463fb: sub    $0x80000000,%ecx
0xb6246401: call   *%eax
0xb6246403: cltd   
0xb6246404: mov    %eax,0x83fd550
0xb6246409: mov    %edx,0x83fd554
0xb624640f: mov    $0x1d5ea98,%eax

I add r915 blockdump for this place

Original comment by Zeydl...@gmail.com on 6 Apr 2009 at 10:48

Attachments:

• R5900dump001D5A8C.txt

[GoogleCodeExporter]

Sorry, old code was:
0x0d233f35: mov    $0x1d5ea94,%eax
0x0d233f3a: mov    0x83bb7b0,%ecx
0x0d233f40: add    $0x1c,%ecx
0x0d233f43: mov    $0x8b761c0,%edx
0x0d233f48: mov    %ecx,%eax
0x0d233f4a: shr    $0xc,%eax
0x0d233f4d: mov    0x8758620(,%eax,4),%eax
0x0d233f54: add    %eax,%ecx
0x0d233f56: js     0xd233f5e
0x0d233f58: mov    (%ecx),%eax
0x0d233f5a: mov    %eax,(%edx)
0x0d233f5c: jmp    0xd233f72
0x0d233f5e: movzbl %al,%eax
0x0d233f61: sub    %eax,%ecx
0x0d233f63: mov    0x8b58e20(,%eax,4),%eax
0x0d233f6a: sub    $0x80000000,%ecx
0x0d233f70: call   *%eax
0x0d233f72: mov    0x8b761c0,%eax
0x0d233f78: cltd   
0x0d233f79: mov    %eax,0x83bb7b0
0x0d233f7f: mov    %edx,0x83bb7b4
0x0d233f85: mov    $0x1d5ea98,%eax
and crush on cltd to.

Original comment by Zeydl...@gmail.com on 6 Apr 2009 at 10:50

[GoogleCodeExporter]

And seems that I place incorrect blockdump 0x1d5ea94 != 001D5A90

Original comment by Zeydl...@gmail.com on 6 Apr 2009 at 10:53

[GoogleCodeExporter]

Original comment by Zeydl...@gmail.com on 6 Apr 2009 at 10:53

Attachments:

• R5900dump01D5EA78.txt

[GoogleCodeExporter]

Ok looks like I see a potential bug in the vtlb memop generation.  I'll look 
into it.

Original comment by Jake.Stine on 7 Apr 2009 at 3:30

• Changed state: Accepted

[GoogleCodeExporter]

I do some tests. Radiata Stories seems to crush on LW instruction (418540), Star
Ocean in LW to (if I count correctly on 001F8AEC). 

Crush on Arc The Lad has following trace:
#0  0xb7f30424 in __kernel_vsyscall ()
#1  0xb769a640 in raise () from /lib/i686/cmov/libc.so.6
#2  0xb769c018 in abort () from /lib/i686/cmov/libc.so.6
#3  0xb78c0988 in __gnu_cxx::__verbose_terminate_handler () from 
/usr/lib/libstdc++.so.6
#4  0xb78be865 in ?? () from /usr/lib/libstdc++.so.6
#5  0xb78be8a2 in std::terminate () from /usr/lib/libstdc++.so.6
#6  0xb78be9da in __cxa_throw () from /usr/lib/libstdc++.so.6
#7  0x080defc9 in vtlbUnmappedVRead32<0u> (addr=1103953119) at vtlb.cpp:261
#8  0xb62259f3 in ?? ()
#9  0x082159f6 in recExecute () at ix86-32/iR5900-32.cpp:756

Where 0xb62259f3 is memory point inside 0x1d5ea94 block, cltd instruction 
exactly.

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

Attachments:

• R5900dump00418530.RS.txt
• R5900dump001F8AE8.S03.txt

[GoogleCodeExporter]

Ok, this is a common error in stacktraces.  The actual instruction causing the 
crash
is "call *%eax", the stackframe is just pointing to the instruction following 
it.

I know because of this: vtlbUnmappedVRead32<0u>  <-- this entry in the stack is 
a
function int he vtlb which is called when the emulated PS2 state attempts to 
access
an illegal *PS2 memory address*  (this has nothing to do with our own memory on 
our
PCs).  As a response, Pcsx2 raises an exception, since it's a sign of flawed 
emulation.

The problem: This can mean anything.  The actual bug could be occurring dozens 
or
even hundreds of instructions prior to the crash.

Also, I checked the memory code and all is correct.  The differences from the Pg
versions and the new one are optimizations, which are generating code as 
intended. :)

Original comment by Jake.Stine on 7 Apr 2009 at 10:59

[GoogleCodeExporter]

Fixed by r1206! For the all demons of hell, how many issues was rooted from one 
place?

Original comment by Zeydl...@gmail.com on 17 May 2009 at 10:50

[GoogleCodeExporter]

To be fair, some of these issues may have been rooted in different places, but 
all
fixed by realigning the baseaddresses passed to memprotect...

Original comment by arcum42@gmail.com on 17 May 2009 at 11:50

[GoogleCodeExporter]

Fixed by forcing alignment on the baseptr in mprotect, r1206.

Original comment by Jake.Stine on 20 May 2009 at 3:04

• Changed state: Verified